[field123]

Closes #756. Part of #735. Builds on #757 (merged), whose x-mcp-name shopper needs.

Summary

Shopper ships a ./mcp export with 149 tools, one for every operation except createAnAccessToken, whose body is form-encoded.

 shopper build
   oas:build        # regenerates specs/shopper.yaml from the service bundles (unchanged)
+  oas:mcp          # redocly bundle shopper-standalone@v1: shopper.yaml + per-operation overrides
   oas:openapi-ts   # input: ../specs/bundled/shopper_standalone.yaml, + mcpTools($, { api: "shopper" })

• Descriptions:
  • 87 are byte-identical copies of the reviewed catalogs and cart-checkout-order descriptions, used where the shopper operation matches.
  • 3 cart ones are adapted where shopper's spec differs: getACart includes, getAnOrder includes, and bulkAddTaxItemsToCart has no component meta.
  • 59 are new: the shopper catalog reads, offerings, subscriptions, accounts, addresses, currencies, files and search.
• x-mcp-name: putV2AuthenticationRealmsRealmIdUserAuthenticationInfoUserAuthInfoId (added in Shopper SDK: add user authentication info update #743) would give a 79-character name, so it becomes shopper_update_user_authentication_info.
• types.gen.ts: the same deliberate change as files in feat(sdks): MCP tools for uploads, an x-mcp-name override, and files #757. getAllFiles page[limit] and page[offset] go from string to number via shopper_service_corrections.yaml (4 lines). sdk.gen.ts and zod.gen.ts are byte-identical.
• Tests: the shopper test helper builds its client with createShopperClient(config, { clientId, tokenProvider }).client, since that factory returns { client, auth }.

Tool list size

354,137 characters for 149 tools. That's the largest package by far, but no tool is over a quarter of it: the largest is shopper_manage_carts at 4.4%, then payment_setup at 3.5% and checkout_api at 3.3%. An MCP server will want to register a subset.

Risk choices

• anonymizeOrders → update, copied from cart-checkout-order: it irreversibly rewrites orders.
• validateCatalogRules → read, copied from catalogs.
• postMultiSearch → read: it only runs searches.
• configureByContextProduct → read. It's a read-only action that returns the configured bundle payload (confirmed in review).
• Left as create:
  • CreateSubscriptionState: it records a lifecycle change.
  • post-v2-account-members-tokens, createOneTimePasswordTokenRequest, post-v2-accounts and post-v2-account-address.
  • the catalog and cart creates, as in their own packages.

Credentials in responses (leave these out of an MCP server)

• post-v2-account-members-tokens: data[].token, an account management JWT.
• createOneTimePasswordTokenRequest: data.token, the one-time password, in the 201 response.
• paymentSetup, confirmPayment, captureATransaction, refundATransaction, cancelATransaction, getATransaction, getOrderTransactions and confirmOrder: data.client_parameters.secret and .token.
• createCartPaymentIntent, updateCartPaymentIntent and the cart reads: meta.payment_intent is free-form, so a Stripe client_secret may come back in it.

Spec problems found (not fixed here)

• getByContextRelease says it returns a list, but the schema is one release.
• getAnOrder and getCustomerOrders declare include twice. The override enum says items only, while the prose lists four.
• Several account parameters have copy-pasted descriptions, such as accountID "you want to retrieve" on an update.
• The SubscriptionStateAction enum includes pending, which its description leaves out.
• GetOffering, GetSubscription, GetInvoice and GetFeature have no description.

Evidence

• Shopper suite: 304 passing with no type errors. That covers the existing shopper tests and the new MCP tests, generation test and type tests.
• A second reviewer checked the 62 new or adapted descriptions against the bundled spec. Five claims were rewritten: a "the spec says" reference, the unsupported "saves nothing" and "warehouses or stores", and wording on catalog-rule selection and curated order.
• Live, read-only (approved store, implicit token): all 149 tools registered on a real McpServer, and these returned data through a real Client:
  • shopper_get_by_context_all_products (2), then get_by_context_product
  • shopper_get_all_currencies (3)
  • shopper_post_multi_search

Merge Danger

Door: two-way

Blast Radius: small

New ./mcp subpath and an optional peer. The main entry is untouched apart from the getAllFiles paging types. specs/shopper.yaml and its join step are unchanged; the new bundle reads it.

[changeset-bot]

🦋 Changeset detected

Latest commit: ef0114a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@epcc-sdk/sdks-shopper	Minor
@epcc-sdk/sdks-nextjs	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
composable-frontend-core	Ready	Preview	Oct 19, 2026 11:29am UTC
composable-frontend-simple	Error		Oct 19, 2026 11:29am UTC

4 Skipped Deployments

Project	Deployment	Actions	Updated
commerce-essentials	Ignored	Preview	Oct 19, 2026 11:29am UTC
composable-frontend-algolia	Ignored		Oct 19, 2026 11:29am UTC
composable-frontend-docs	Ignored	Preview	Oct 19, 2026 11:29am UTC
composable-frontend-subscriptions	Ignored	Preview	Oct 19, 2026 11:29am UTC

[field123]

Closing without merging. The shopper SDK is the storefront SDK, joined from 11 service specs; 87 of these 149 tools copy tools that catalogs and cart-checkout-order already ship, and most of the rest copy other service packages. The operations only shopper has, the 16 by-context catalog reads (getByContext* and configureByContextProduct), will get MCP tools in the catalogs package instead, as #756 now describes. The descriptions written here for them carry over.