MCP HTTP servers need CORS for claude.ai connectors
Deploying a Model Context Protocol HTTP/SSE server and connecting browser-based MCP clients to it.
An MCP server exposed at /mcp accepted POST/GET/DELETE and worked perfectly from the claude mcp add --transport http CLI and from curl, but failed silently from claude.ai custom connectors. claude.ai runs in the browser, so before any real request the browser sends OPTIONS /mcp as a CORS preflight — the framework returned 405 method not allowed because no OPTIONS handler was declared, and the browser aborted the whole connection with no error visible to the user. Same applies to Claude Desktop on some platforms. Fix: add an OPTIONS handler returning 204 plus access-control-allow-origin, allow-methods (GET POST DELETE OPTIONS), and allow-headers including the MCP streamable-http transport headers (mcp-session-id, mcp-protocol-version, authorization, content-type, accept). Bearer auth remains the real security gate; CORS is the browser sandbox dance.
When wiring an HTTP MCP transport, test from a browser-based client (claude.ai custom connector) in addition to CLI clients — the CLI bypasses preflight and will succeed while browser clients silently fail with no log on either side.