Hi Composio team, This integration worked until last week; since then MCP tool listing fails while management API still accepts the same API key. Env: composio-core@0.5.39, @modelcontextprotocol/sdk@^1.12.1 (API key regenerated, env updated, service restarted) Works (same key): OAuth, MCP server create, GET /api/v3.1/mcp/ce4970af-f583-44b9-9bba-cff8de3c00ae + x-api-key: ak_QPVQJ***** → 200 Fails (same key): POST /v3/mcp/ce4970af-f583-44b9-9bba-cff8de3c00ae/mcp?user_id=org-u8wk-90a39e8b + x-api-key → 401 Invalid API key repro-mcp-manager-list-tools.ts → 401 (request_id: 5abcae4f-84fe-435f-bdc2-b8c5c7c455c1) curl initialize on same URL → 401 (request_id: 1a16d7ae-0aff-46f1-a41d-ccb957502805b, x-matched-path: /v3/mcp/[serverId]/[transport]) Immediately after, GET /api/v3.1/mcp/... with the same key → 200. Server: ce4970af-f583-44b9-9bba-cff8de3c00ae, toolkit todoist, managed_auth_via_composio: true Attached: repro-composio-credentials.ts — minimal MCP SDK repro: npx ts-node repro-composio-credentials.ts \ --mcp-url 'https://backend.composio.dev/v3/mcp/ce4970af-f583-44b9-9bba-cff8de3c00ae/mcp?user_id=org-u8wk-90a39e8b' \ --api-key 'ak_QPVQJ*****' Runs: (1) no auth header, (2) Authorization: Bearer . Our failing curl used x-api-key instead. request_ids: 5abcae4f-84fe-435f-bdc2-b8c5c7c455c1, 1a16d7ae-0aff-46f1-a41d-ccb957502805b, 1eefdab2-73b8-4bc0-8ad9-216bf9f3fede (no auth) Why does x-api-key work on management API but fail on MCP transport? Any auth change last week — JWT, different header, or project-scoped key required? Thanks. https://cdn.discordapp.com/attachments/1511580642972930088/1511580643174252664/repro-composio-credentials.ts?ex=6a21a16d&is=6a204fed&hm=8430a92f1f4cc5e0da8b2f320e81f1813a2571bc96d7fe8c61e7541383106dc1&

Hi there, Thanks for the detailed repro and request IDs, that helps a lot. Quick reassurance first:

x-api-key

is still the correct header for the MCP transport (there's no required switch to a Bearer token), and your URL is right, the

x-matched-path

shows the request is reaching the transport route correctly. So this is purely an auth check failing, not a transport or URL issue. The reason the same key can pass

GET /api/v3.1/mcp/{id}

but 401 on the transport is that the transport validates the project API key more strictly. The two most common causes: • The key isn't a default project API key (a scoped key can behave differently across routes). • The key doesn't belong to the exact project that owns server

ce4970af

. As a quick check, please retry with a default project API key generated in that server's project. If that still 401s, we can pin down the exact reason from the request IDs you sent, so just reply here and we'll pull the server-side rejection for

5abcae4f-84fe-435f-bdc2-b8c5c7c455c1

. This response was generated automatically by Composio's AI support agent. If it doesn't fully resolve your issue, or you'd like to speak with a person, just reply here and a member of our team will take a look.