Pitfall Preferences redcorsair

Mcp Sdk Version Pinning Railway

mcprailwayoauthdeployment

What Happened

MCP SDK versions above 1.10.1 introduce transport security changes (DNS rebinding protection) that reject Railway hostnames even when protection is explicitly disabled. This causes 421 Misdirected Request errors on the /mcp endpoint when Claude.ai tries to connect.

Root Cause

MCP SDK 1.26.0 auto-enables DNS rebinding protection when OAuth auth is configured. The protection check rejects Railway’s internal hostname routing even when that hostname is explicitly allowed in the config. There is no way to disable it in SDK versions above 1.10.1 : the flag is ignored. Five commits in 28 minutes (commits d9214e5 through ce82402) to discover this:

  1. Started with mcp<2.0 : got DNS rebinding 421 errors
  2. Configured DNS rebinding protection with Railway hostname : still rejected
  3. Disabled DNS rebinding protection entirely : still rejected
  4. Pinned mcp==1.10.1 and disabled protection : finally worked

Secondary issue: Starlette’s Mount class issues a 307 redirect from /mcp to /mcp/, which Claude.ai does not follow for POST requests. Required ASGI middleware to rewrite the path in-place before it reaches the router.

How to Avoid

  1. Pin mcp==1.10.1 for Railway-deployed MCP servers with OAuth
  2. Add ASGI path rewrite middleware for trailing-slash routes (do not rely on 307 redirects for POST endpoints)
  3. Enable uvicorn proxy_headers and forwarded_allow_ips="*" : Railway terminates TLS at the edge, and without these, Starlette generates http:// redirect URLs that break OAuth
  4. If upgrading MCP SDK, test the full OAuth flow end-to-end with the actual Railway hostname, not just localhost

Evidence

Commits d9214e5 through ce82402 (2026-02-25, 15:31 to 15:59) : five fixes in 28 minutes, all addressing Railway + MCP SDK transport issues.