Shopware MCP server: connect your store to AI agents

What MCP actually is (and isn't)

Anthropic introduced MCP in late 2024 to solve a boring but expensive problem: every team integrating an LLM with their internal systems was writing the same glue code in slightly different ways. MCP standardises that glue. A server exposes tools (functions the model can call), resources (read-only data the model can attach to its context), and prompts (parameterised starting points for tasks). A client, usually an AI chat app, discovers what the server offers and decides when to call it.

By 2026, Claude Desktop, ChatGPT, Cursor, Zed, and most production AI IDEs ship MCP support as a first-class feature. Shopware was one of the first major e-commerce platforms to publish an official server, and the community has added several specialised ones for theme work and plugin debugging.

A few things MCP is not:

• It is not a Shopware extension or plugin. The server runs outside Shopware and talks to it over the Admin API.
• It is not a hosted service you have to subscribe to. You run the server yourself, on your machine or in your infrastructure.
• It is not autonomous. The agent only does what the AI client decides to do, and the AI client only does what the user, or its own configured policy, allows.

The setup

Prerequisites

• A Shopware 6 store, self-hosted or PaaS. Admin API access is required.
• Node.js 22 or newer on the machine running the MCP server. The official server is published as an npm package.
• An MCP-compatible AI client. This guide uses Claude Desktop, but Cursor and ChatGPT Desktop work identically once the config file is in place.

Step 1: Create an Admin API integration in Shopware

In the Shopware Administration, go to Settings → System → Integrations and create a new integration. Give it a name you'll recognise later in audit logs, for example mcp-claude-desktop.

Copy the Access key ID and Secret access key. The secret is shown once. Store it in your password manager, not in the MCP config file.

Step 2: Note the package name and credentials

The official server is published as @shopware-ag/admin-mcp on npm. You don't install it manually. Your AI client launches it via npx with three environment variables set:

SHOPWARE_API_URL=https://shop.example.com
SHOPWARE_API_CLIENT_ID=SWIAxxxxxxxxxxxx
SHOPWARE_API_CLIENT_SECRET=yyyyyyyyyyyyyy

The server speaks MCP over stdio, so running it directly in a terminal isn't useful on its own. The next step wires it into a client that will spawn it and talk to it.

Step 3: Register the server with your AI client

Each client has its own config file but the shape is identical. For Claude Desktop on macOS, edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "shopware-admin-mcp": {
      "command": "npx",
      "args": ["-y", "@shopware-ag/admin-mcp"],
      "env": {
        "SHOPWARE_API_URL": "https://shop.example.com",
        "SHOPWARE_API_CLIENT_ID": "${SHOPWARE_API_CLIENT_ID}",
        "SHOPWARE_API_CLIENT_SECRET": "${SHOPWARE_API_CLIENT_SECRET}"
      }
    }
  }
}

The ${VAR} interpolation reads from the OS environment, which means the actual secret never sits in the config file. Set the variables in your shell profile or, better, in a secrets manager that exports them to the client process.

Restart the AI client. A new tool group named shopware should appear in the integrations panel. If it doesn't, check the client's log file. Wrong path to npx is the most common cause on Windows.

Step 4: Verify with a real prompt

Open a new chat and ask something small and read-only:

List the five most recently created products in the store,
with their stock level and active state.

The agent will request permission to call a Shopware tool, you approve once, and the answer comes back as a table grounded in your live data. Check the Shopware integration log under Settings → System → Integrations → Activity to confirm the call was made under the integration you created, not some forgotten admin account.

Security guardrails that matter

An MCP server is, functionally, a long-lived API client with the privileges of whoever issued it. Treat it the same way you'd treat an ERP integration. The list below is the short version of what I configure on every install.

Scope the ACL role to the workflow

If the agent only needs to read product and order data, give it only those read privileges. Create a separate integration with write access for the workflows that genuinely need it. Two integrations cost nothing. One overprivileged key costs everything once a prompt injection convinces the model to delete a category.

Run the server locally for now

The official server speaks stdio, which means it runs as a subprocess of the AI client on your machine. That's the safest configuration today. HTTP-transport MCP servers exist and have their place, but exposing one on the public internet introduces an attack surface that is not worth it for a single-user merchant workflow.

Watch out for prompt injection from product data

Product descriptions, customer messages, and CMS content are user-generated. An attacker can write instructions into a product description that an LLM might interpret as commands when it reads the data. Treat any content the model reads from the store as untrusted text, and avoid giving the agent write tools that don't require human confirmation when its context could include user-generated content.

Log everything, audit weekly

Shopware logs every Admin API call under the integration's name. Skim the log once a week. Look for tools the agent called that surprised you, payload sizes that don't make sense, and access patterns outside business hours. The point is not to read every line, it's to develop an intuition for what normal looks like.

Real merchant workflows

These are the patterns that recover their setup time within a month. They are unspectacular on purpose. The value comes from shrinking the gap between a question and an answer from 20 minutes to 20 seconds.

Scenario 1: Daily inventory triage

Scenario 2: Bulk SEO copy in two languages

Scenario 3: Order investigation

Scenario 4: Sales channel sanity check before a campaign

When to build your own MCP server

The official server covers product, category, order, sales channel, and media operations. That's enough for most merchants. You start to need a custom server when:

• You want the agent to call your own plugin's endpoints, not the core Admin API.
• You want to compose a high-level tool that wraps three or four Admin API calls into one operation, with validation in between.
• You want to expose read-only views into systems the Admin API doesn't reach: your ERP, your warehouse, your analytics.

The MCP SDK is available for TypeScript, Python, and Go. A minimal TypeScript server that adds one custom tool, get_top_customers, looks like this:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "shop-custom", version: "0.1.0" });

server.registerTool(
  "get_top_customers",
  {
    title: "Top customers by lifetime revenue",
    description: "Returns the top N customers by total order value over a date range.",
    inputSchema: z.object({
      limit: z.number().min(1).max(100).default(10),
      since: z.string().describe("ISO 8601 date, inclusive"),
    }),
  },
  async ({ limit, since }) => {
    const rows = await fetchTopCustomers(limit, since); // your Admin API call
    return { content: [{ type: "text", text: JSON.stringify(rows, null, 2) }] };
  }
);

async function main() {
  await server.connect(new StdioServerTransport());
}

main();

Two dozen lines and you have a tool the agent can call. Register the binary in the same mcpServers config and it appears alongside the official one. Most of the work, as always, is in the boring parts: pagination, error mapping, and writing input schemas the model can understand without trying every wrong combination first.

Where this still falls short

Anyone telling you MCP plus Shopware equals autonomous commerce in 2026 is selling something. The honest limits I run into on real projects:

• Token budgets matter. An "export all 12,000 orders from Q1" prompt is not free. The agent will paginate sensibly, but you pay for every page in tokens and time. Bulk exports still belong in a worker script.
• The model still hallucinates schema sometimes. Custom fields with non-obvious names confuse it. Good naming and good tool descriptions reduce this; they don't eliminate it.
• Write operations need confirmation. Always. Even with the best policy, never let an agent execute writes silently. The friction of "yes, do it" is a feature, not a flaw.
• Storefront API support is uneven. The official server covers the Admin API well. Storefront-side automation (cart, checkout) is best served by purpose-built code, not an LLM in the loop.