Allow browser-based MCP clients via CORS and cross-origin bypass

[RossTarrant]

Summary

Add CORS support and configurable cross-origin protection to allow browser-based MCP clients to connect to the HTTP server.

Why

We recently upgraded the MCP Go SDK from v1.3.1 to v1.5.0, which brought in cross-origin request protection added in v1.4.1. This uses net/http.CrossOriginProtection to reject cross-origin POST requests by default based on the Sec-Fetch-Site header.

Browser-based clients (e.g. MCP Inspector which was used to test this PR) send Sec-Fetch-Site: cross-site and get a 403. Additionally, the HTTP server had no CORS headers, so browsers blocked requests at the preflight stage before even reaching the CSRF check.

Fixes #2342

What changed

• Added CrossOriginProtection field to ServerConfig so consumers can configure the SDK's cross-origin behavior
• RunHTTPServer defaults to bypassing cross-origin protection for the local HTTP server
• Passes the configured CrossOriginProtection through to the SDK's StreamableHTTPOptions
• Added SetCorsHeaders middleware handling preflight OPTIONS and setting Access-Control-* headers
• Wired SetCorsHeaders into the MCP route group

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Prompts tested (tool changes only)

• N/A

Security / limits

• No security or limits impact

• Auth / permissions considered

• Data exposure, filtering, or token/size limits considered

• CORS uses Access-Control-Allow-Origin: * which is safe because auth is bearer-token-only (not cookie-based)

• Cross-origin protection bypass is opt-in via ServerConfig; SDK default (reject) is preserved for library consumers

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Docs

• Not needed
• Updated (README / docs / examples)

[Copilot]

Pull request overview

Adds CORS support and makes the MCP Go SDK’s cross-origin request protection configurable so browser-based MCP clients can reach the HTTP MCP endpoints (addressing the new default 403 behavior after the go-sdk upgrade).

Changes:

• Add ServerConfig.CrossOriginProtection and plumb it through to mcp.StreamableHTTPOptions.
• Default RunHTTPServer to bypass cross-origin protection when not explicitly configured.
• Add SetCorsHeaders middleware (including OPTIONS preflight handling) and tests for CORS + cross-origin protection behavior.

Show a summary per file

File	Description
pkg/http/server.go	Adds CrossOriginProtection config + defaults local server to bypass SDK cross-origin protection; wires CORS middleware into MCP route group.
pkg/http/handler.go	Passes CrossOriginProtection into the SDK handler and introduces CORS middleware implementation.
pkg/http/handler_test.go	Adds unit tests for CORS headers and for SDK cross-origin protection allow/deny behavior.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 3

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 2

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[SamMorrowDrums]

I was actually going to say define this inside the SetCorsHeaders (before returning the closure), so it's defined when you create the middleware and then used each time.

Also more importantly, we have a middleware package and this should move there.

[RossTarrant]

thanks for the feedback, this logic now sits in cors.go and defines the allowed headers inside SetCorsHeaders like you suggested

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[marknilsn]

I don’t think “Docs: not needed” is quite right here. This changes the practical exposure model of RunHTTPServer for browser clients, so I’d like a short docs/README note on the default posture and when operators may want stricter CrossOriginProtection behavior before merging.

[RossTarrant]

I don’t think “Docs: not needed” is quite right here. This changes the practical exposure model of RunHTTPServer for browser clients, so I’d like a short docs/README note on the default posture and when operators may want stricter CrossOriginProtection behavior before merging.

Thanks for the feedback - you're right this should be documented. I've added a section to docs/streamable-http.md that covers the changes being made