All Release Notes
Authentication updates for remote Commerce MCP server
23 June 2026
HTTP API
Enhancement
Security and privacyGeneral
To improve security, we released a new major version of the Commerce MCP server. This version introduces a strict authentication requirement for the /mcp endpoint when running in remote or Streamable HTTP transport mode.
When you adopt this version, all incoming requests must include a valid Authorization: Bearer {token} header. The server no longer falls back to startup credentials when a request omits this header.
This change is breaking if your existing remote clients relied on the no-header fallback. They will receive 401 Unauthorized until they send a token.

What changed

Previously, if an incoming network request lacked an Authorization header, the Model Context Protocol (MCP) server used its own pre-configured token to fulfill the request. This behavior allowed unauthenticated network callers to be served using the server's credentials.

When you deploy this version, the Commerce MCP server handles authentication as follows:

  • Strict validation: The server validates the Authorization header before making any calls to the commercetools API. Missing or malformed headers immediately return a 401 Unauthorized status code.
  • Direct token forwarding: The server forwards the caller's bearer token directly to the commercetools API using the auth_token flow. This behavior also resolves an issue where a server started with client_credentials silently ignored per-request header tokens.
  • Isolated configurations: The request handler no longer mutates the shared authConfig object. Instead, it builds an isolated configuration for each request.

Migration steps

When planning your upgrade to this version, ensure that any clients connecting to a remote server send an Authorization: Bearer {token} header with a valid commercetools access token for every request.

The server's startup credentials will no longer be used to fulfill network requests once this version is deployed.