MCP Python SDK blocks cross-origin HTTP redirects in client connections

The MCP Python SDK now refuses to follow HTTP redirects that lead away from the origin of the server it was configured to talk to. The change shipped in version 2.2.0, published on September 7, and it redefines the endpoint URL as an explicit security boundary for agent client connections.

According to a dev.to post by Ben Greenberg reviewing the release notes, the rule covers the SDK's standard client connections along with the Streamable HTTP and SSE transports.

How the new redirect rule works

A client created through the standard Client constructor, streamable_http_client, or sse_client now follows a redirect only when the scheme, host, and port all stay the same. An upgrade from http to https on the same host is permitted. A redirect to any other origin fails, and the session stays usable afterwards. The dev.to post reports that a rejected redirect raises an MCPError, while an SSE connection instead fails with httpx2.HTTPStatusError.

The same restriction now applies to OAuth provider requests. According to the post, this closes a gap in which the MCP transport enforced an origin rule while the authentication flow followed a looser redirect policy of its own.

There is a practical side effect: same-origin path changes such as a redirect from /mcp to /mcp/ now work without configuring an httpx.AsyncClient with follow_redirects.

Why redirects crossed the line

A general-purpose HTTP client will happily follow a redirect from mcp.example.com/mcp to other.example.net/mcp. For an MCP client, that answer is no longer acceptable: other.example.net is not the server the user configured. If the client carries an authenticated session, OAuth state, or tool-discovery requests, following the redirect silently widens the set of endpoints that can receive them. The configured endpoint, in other words, determines where a session can be established and where authenticated requests can be sent, and a redirect should not be able to make that decision on the server's behalf.

What it means for deployments

Same-origin redirects remain valid for routing cleanup, such as adding a trailing slash or reshaping a path while preserving scheme, host, and port. Cross-origin moves are a different matter. The post's guidance for maintainers is to treat endpoint changes as part of security review, and to ask one question before shipping a redirect: does the final URL share the scheme, host, and port of the URL users configure? If not, publish the new endpoint so clients can switch to it deliberately, because a redirect is the wrong way to migrate when the move crosses an origin boundary.

A checklist for client maintainers

The post lays out a review checklist for anyone changing MCP connection handling: enforce the origin check in every supported transport rather than leaving one with a looser policy; apply the same rule to OAuth authorization, token, and metadata requests, which often use a separate HTTP client; keep session state usable after a redirect is rejected; never send credentials or session-bound headers, including on tool-discovery requests, to an origin that was not explicitly configured; and make error messages state clearly that a redirect was rejected for leaving the endpoint's origin. Recommended tests cover a same-origin path redirect, an http-to-https upgrade on the same host, a redirect to a different host, and OAuth requests tested separately from transport requests.

Why it matters

MCP servers expose tools and prompts that users and agents are asked to act on, so a client connection is a trust relationship, not just a network setting. By refusing cross-origin redirects, including inside OAuth flows, the SDK closes a realistic vector in which a compromised or reconfigured server could pull authenticated agent traffic onto an endpoint the operator never approved. The change also nudges the ecosystem toward predictable behavior at protocol boundaries, the kind of agreement the Agentic AI Foundation points to as the foundation for agents working across tools and frameworks. For developers, the practical takeaway is simple: if the server you need lives at another origin, configure that URL directly instead of letting a redirect decide.