Download the PHP package tmonier/sylius-b2b-mcp-plugin without Composer

Sylius B2B MCP Plugin

Français : README.fr.md

B2B tools for the official Sylius MCP server: your business customers connect Claude or ChatGPT to their own shop account to find past orders, reorder, quick order by SKU, request quotes and check their trade credit. They still place and pay their orders on your website.

sylius/mcp-server-plugin exposes a Sylius shop to AI assistants through the Model Context Protocol, as a guest: catalog search and a guest checkout. A purchasing manager who reorders every month needs their account instead: their orders, their prices, their company, their quotes, their credit.

This plugin adds that to the same MCP server (it is not a second server): OAuth 2.1 sign-in with the customer's shop account, and tools scoped to that customer and to the channel. The assistant prepares the cart; the customer reviews it and orders on the shop, where the order button, the legal information and the payment stay under your control.

It is a B2B tool for customers who add the connector themselves. It does not list your shop in the ChatGPT or Claude directories (that needs their review), and it does not sell "in" ChatGPT, Gemini or Claude: no order and no payment happen in the assistant.

Features

Tools whose plugin is not installed are simply not registered. Translations in English, French, German, Spanish, Italian, Dutch and Polish; MySQL, MariaDB and PostgreSQL.

Tools

No tool places an order, pays, or changes the account, the addresses or the payment methods.

Approval decisions from an assistant (opt-in)

decide_approval is off by default. With approvals.allow_decisions: true, the shop offers the b2b:approve permission; on the consent page it is a separate, never pre-ticked checkbox with a warning, and a client asking for no scope never gets it. The tool applies the rules of the shop page (approver of the order's company, no self-approval, approval limit, order still new, one decision under a lock) and records the approver as the decider.

The risk is prompt injection: text the assistant reads (a product name, an order, a quote message, a web page) could try to make it approve an order. Mitigations: the tool description tells the model to call it only on the user's explicit request after showing the order; the decision is limited by the approver's approval limit; every call is audited; and keep tool confirmations on in your assistant (Claude and ChatGPT ask before running a tool that is not read-only: decide_approval is annotated as destructive). Enable it only for approvers who understand this.

Turning allow_decisions off takes b2b:approve away from every connection for good (at the cache warmup of the deployment, else on the first MCP request or token refresh, and in tmonier:b2b-mcp:purge); the connections keep b2b:read and b2b:cart and their refresh keeps working. Turning it back on never restores the permission: each approver ticks it again on a new consent.

Screenshots

Requirements

Symfony 6.4 is not supported: symfony/mcp-bundle, which the official MCP plugin is built on, requires Symfony 7.3 or later. The official plugin is beta (0.x); see Limitations.

The shop must be reachable over HTTPS on a public host name: Claude and ChatGPT connect to it from their servers. Behind a reverse proxy, configure the trusted proxies so that the URLs of the OAuth metadata use https and the public host.

Installation

1. Require the package:

2. Register the bundles in config/bundles.php (the first two may already be there):

3. Import the configuration and the routes of both plugins:

   No change to security.yaml is needed (see How it works).

4. Run the migration (plugin tables only, core tables are not changed):

5. Set a dedicated encryption key (it protects authorization codes and refresh tokens; it defaults to the kernel secret):

6. Schedule the clean-up once a day: bin/console tmonier:b2b-mcp:purge (expired tokens, clients registered but never connected, old idempotency keys, audit entries older than the retention period).

The MCP endpoint is the HTTP path of symfony/mcp-bundle: https://your-shop.example.com/_mcp with sylius/mcp-server-plugin 0.2.

Connecting an assistant

The customer needs a shop account on the channel (host name) of the URL.

Claude (custom connector)

1. In Claude (web or desktop): Settings > Connectors > Add custom connector.
2. Name it after the shop, URL https://your-shop.example.com/_mcp, no client ID needed (Claude registers itself).
3. Connect: Claude opens the shop; the customer signs in and clicks Allow on the consent page. On Team and Enterprise plans, an owner may have to add the connector first.

Claude uses the callback https://claude.ai/api/mcp/auth_callback (and claude.com), allowed by default. Claude Code connects from a local callback (claude mcp add --transport http shop https://your-shop.example.com/_mcp): enable allow_loopback_redirect_uris for it.

ChatGPT (developer mode, Business and Enterprise)

1. Enable developer mode (Settings > Apps & Connectors > Advanced settings), or ask the workspace admin on Business and Enterprise plans.
2. Create a connector (app) with the URL https://your-shop.example.com/_mcp and OAuth authentication; ChatGPT registers itself.
3. Connect: ChatGPT opens the shop for the sign-in and the consent.

ChatGPT uses https://chatgpt.com/connector_platform_oauth_redirect or a per-app callback https://chatgpt.com/connector/oauth/{id}, both allowed by default.

The availability of custom connectors depends on the plan and the country of the user, and changes often: check the current documentation of Anthropic and OpenAI. Listing the shop in a public directory (ChatGPT apps, Claude connectors directory) requires their review and is outside the scope of this plugin.

Fixed client ID instead of dynamic registration

Some setups prefer to register the assistant once:

and enter the client ID (and secret) in the advanced settings of the connector. Dynamic registration can then be switched off (oauth.dynamic_client_registration: false).

Recommended in production when your customers can be given a client ID: disable dynamic registration and create one client per assistant with the command. With dynamic registration on (needed for the one-click "Add connector" flow), anyone can register a client and choose its name; the redirect URI allow-list keeps the codes on the assistants' own hosts, and the consent page names the assistant after that verified host (Claude, ChatGPT), shows the host prominently and flags self-registered clients ("registered itself on under the name ... not verified by the shop").

Restricting the accounts that may connect an assistant (extension point)

By default any enabled shop account may connect an assistant and call the endpoint. To add a rule of your application (registration not approved, account suspended, contract ended...), implement Tmonier\SyliusB2bMcpPlugin\Account\AccountUsabilityCheckerInterface; it is tagged tmonier_b2b_mcp.account_usability_checker by autoconfiguration (a tag priority orders several checkers):

• The checkers are asked at the OAuth consent (page and decision: a refused account gets a 403, no connection and no authorization code) and at every call of /_mcp, after the token is resolved: an access token issued before the refusal gets a 403 access_denied with Cache-Control: private, no-store, and the refusal is written to the audit log (tool account_usability, outcome refused, with your reason).
• The first refusal wins; later checkers are not asked. A checker that throws refuses (fail closed): the error is logged (channel mcp), the client only sees access_denied.
• The reason (a short machine-readable string) is never sent to the client. An unknown, expired or revoked token is still a 401 and no checker is called.
• The rate limit of the connection is applied before the checkers: a flood of refused calls is limited (429) and does not fill the audit log.
• The checkers run on every call: keep them cheap and independent of the request (the customer is the only input). The token endpoint is not checked: a refresh gives a token that the endpoint then refuses.

Configuration

Optional, with the defaults:

hidden_official_tools: [] keeps the whole guest checkout of the official server (the guest tools then work next to the B2B ones, with a separate guest cart).

How it works

• Extension, not a second server. The tools are registered on the server of symfony/mcp-bundle through its loader extension point (mcp.loader), the mechanism used by sylius/mcp-server-plugin itself. A decorator of the MCP registry leaves out the hidden official tools.
• Authentication. A request listener runs before the firewall on the MCP route (decided on the route matched by the router, so encoded spellings such as /%5Fmcp are covered): without a valid bearer token, the answer is a 401 with WWW-Authenticate: Bearer resource_metadata=".../.well-known/oauth-protected-resource/_mcp", which starts the OAuth flow in Claude and ChatGPT. A shop session cookie is never enough. After the firewall, the shop user becomes the security token of the request (so the Sylius and plugin voters apply) and nothing is stored in a session.
• Tokens. Access tokens are opaque random strings (80 hexadecimal characters); only their SHA-256 hash is stored, so a database leak gives no usable token and no key pair has to be managed. A token belongs to a connection (customer, assistant, channel): it only works on the host name of that channel, for an enabled shop user, while the connection is active. Refresh tokens rotate; presenting a spent refresh token or authorization code again revokes every token of the connection.
• Consent. /mcp-oauth/authorize checks the request (client, registered redirect URI still allowed, PKCE S256, resource naming this endpoint) and sends the browser to /{locale}/account/ai-assistants/authorize, behind the shop login. The page names the assistant after the host it returns to when it is a known one (otherwise the declared name, stripped of control and bidi characters), shows that host prominently, flags clients that registered themselves, and lists the permissions; it cannot be framed.
• Same rules as the shop. Carts are the customer's latest cart on the channel (the one the shop shows after login). Lines go through the quick order adder when that plugin is installed (as its reorder button does), otherwise through the core rules (enabled, sold in the channel, priced, in stock, quantity limit), then through the Sylius order processor. Quote requests go through the quote request factory and manager (rate limit by e-mail included). Company access goes through the voters of the company accounts plugin.
• Prompt injection hygiene. Tool results are JSON data with plain text (tags and control characters removed, lengths capped); each tool description says its result is shop data, never instructions. No tool can change account settings, addresses or payment methods, and nothing is ordered without the customer acting on the website.
• Idempotency. reorder, quick_order_add (confirm) and request_quote require an idempotency_key: a retry with the same key and arguments returns the stored result ("replayed": true), the same key with other arguments is refused.

Personal data

• Audit log (tmonier_b2b_mcp_tool_call): customer, e-mail, assistant name, IP address of the assistant's server, tool, arguments (free text written by the customer, such as the message of a quote request, comment of an approval decision, is replaced by its length), outcome. Kept audit_retention_days (90 by default, tmonier:b2b-mcp:purge). Purpose: security and support of the merchant's own service; document it in your privacy policy.
• Idempotency keys: the result of cart-changing calls, kept idempotency_ttl_hours (24).
• Connections and tokens: customer, assistant, channel, scopes, dates; tokens are stored hashed and purged a day after they expire.
• Deleting a customer deletes their connections, tokens, audit entries and idempotency keys (foreign keys ON DELETE CASCADE, so also when the row is deleted outside Doctrine).
• The assistant (Anthropic, OpenAI) receives the data returned by the tools as an independent controller under its own terms: tell your customers in your privacy policy.

Demo data

The test application loads the fixtures of the companion plugins: [email protected] / sylius (trade credit account with open items), the Acme Industries company ([email protected], buyer@..., approver@... / sylius, with orders) and quote requests.

Limitations

• sylius/mcp-server-plugin is beta. Its tagged 0.2 requires symfony/mcp-bundle 0.3 (January 2026); its main branch moved to mcp-bundle 0.13 with several servers (/mcp/shop), not tagged yet. This plugin targets the tagged 0.2; the registration of the tools will need an update when Sylius tags the next version.
• The official guest tools that stay (catalog) call the Shop API over HTTP as a guest, as before; they are not rate limited nor audited by this plugin.
• No payment and no order completion in the assistant (on purpose): in-assistant checkout is not available to EU merchants today, and B2B buyers order from the website.
• No MCP Apps (interactive UI in the assistant): results are text and structured data.
• The stdio transport (bin/console mcp:server) has no customer: the B2B tools refuse.
• One issuer per shop host; scopes are coarse (b2b:read, b2b:cart). Dynamic registration is open, protected by the redirect URI allow-list and the consent page (showing the host the assistant returns to).
• Prices in results are decimal strings in the order currency, with two decimals like the shop.
• The audit log bridge records the events whatever the sources setting of the audit log plugin (customer actions are not recorded there by default); its anonymization command covers them, the deletion of a customer does not (no foreign key in that plugin).
• Tested locally with MySQL 8.4; the MariaDB and PostgreSQL jobs of the CI matrix were not run locally.

Development

See SPEC.md for the research and design decisions.

B2B demo

This plugin is used in the Sylius B2B demo: a Sylius 2.3 shop with fictitious sample data where the B2B plugins work together. The source code, setup and fixtures of the demo are in that repository.

The demo is an example, not a production setup.

License

MIT, see LICENSE.