Authentication with key in header doesn't work

[hiteshssathawane]

MCP server URL

https://stitch.googleapis.com/mcp

Where does the issue occur?

Other

Transport used

streamable-http

Client registration type

Static

SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

When did you last reproduce this?

27 March 26 9:56 Am IST

Browser and OS

Mac OS

Describe the issue

{
"mcpServers": {
"stitch": {
"serverUrl": "https://stitch.googleapis.com/mcp",
"headers": {
"X-Goog-Api-Key": "****"
}
}
}
}

there is map for claude code below but the above one does not work in claude desktop, no facility to add headers

claude mcp add stitch
--transport http
--url "https://stitch.googleapis.com/mcp"
--header "X-Goog-Api-Key: ****"

Issue details

there is map for claude code below but the above one does not work in claude desktop, no facility to add headers

Expected behavior

Logs from your server

Some MCP servers could not be loaded
The following entries in claude_desktop_config.json are not valid MCP server configurations and were skipped: stitch

when clicked on connect
Couldn't reach the MCP server. You can check the server URL and verify the server is running. If this persists, share this reference with support: "ofid_fb463e2741519938"

Additional context

No response

[crondinini-ant]

Thanks for the report and for including the reference ID — that made it easy to trace.

There are two separate things going on here. The first is that claude_desktop_config.json currently doesn't accept a headers field for remote (HTTP/SSE) MCP servers, so the config you pasted gets rejected at parse time before any network call happens. That's the "entries in claude_desktop_config.json are not valid MCP server configurations" message. Claude Code's claude mcp add --header flag does support this, but the Desktop config schema for remote servers hasn't caught up yet. That's a gap on our side and it's a reasonable feature request.

The second thing is what happened when you clicked Connect in the UI and got ofid_fb463e2741519938. Looking at our logs for that flow: the Connect button for a custom connector always tries OAuth, and the Stitch server advertises accounts.google.com as its authorization server. We successfully fetched Google's OAuth metadata, but Google's OAuth server doesn't expose a dynamic client registration endpoint (RFC 7591), and we don't have a pre-registered OAuth client for stitch.googleapis.com. With no way to obtain a client ID, we can't build an authorization URL, so the flow stops there and you get the generic "couldn't reach" error. The error message is misleading — we did reach the server, we just couldn't complete OAuth setup against Google's auth server.

So even though the Stitch API is designed around API keys in the X-Goog-Api-Key header, the Desktop remote-connector path only knows how to do OAuth today, and Google's OAuth infrastructure requires pre-registration that we haven't done for Stitch. That's why this particular server hits a wall where others might not — Google has never supported dynamic registration, so any Google-backed MCP server that isn't in our pre-registered list will fail the same way.

For right now, the workaround is to run a small local stdio MCP server that proxies requests to the remote Stitch URL and injects your X-Goog-Api-Key header on each outbound call. You'd add it to claude_desktop_config.json as a command-style server rather than a serverUrl one — Desktop's stdio transport doesn't go through our backend, so the header stays local and reaches Stitch directly. There are a few community tools that implement this proxy pattern.

Issue #112 reports the same underlying gap (no way to set a Bearer token or custom headers for remote connectors), so linking these together.

[crondinini-ant]

Closing this for now since this is not a bug, just something we don't support.