OAuth handler doesn't support redirect URLs with params

[artdent]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

The oauth redirect handler uses the following logic (https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/client/auth/oauth2.py#L356-L357) to attach parameters to the redirect URL supplied by the server:

        authorization_url = f"{auth_endpoint}?{urlencode(auth_params)}"
        await self.context.redirect_handler(authorization_url)

Unfortunately, this breaks if the auth_endpoint supplied by the server already has URL parameters. For example, at https://api.salesforce.com/.well-known/oauth-authorization-server/platform/mcp/v1/sandbox/platform/sobject-all you can see that the salesforce mcp server has an authorization endpoint of https://test.salesforce.com/services/oauth2/authorize?prompt=select_account.

The end result is that the client tries to visit a URL that loooks like https://test.salesforce.com/services/oauth2/authorize?prompt=select_account?response_type=code&..., which is incorrect.

Example Code

Python & MCP Python SDK

python3 3.13.2
mcp 1.27.2

[josh-ninjatrader]

A second production provider hits this, so here's another data point for #2776 plus a verification of #2779.

Reproduction against NinjaTrader

NinjaTrader's MCP server advertises an authorization_endpoint with a query component:

$ curl -s https://mcp-demo.tradovateapi.com/.well-known/oauth-protected-resource
{"resource":"https://mcp-demo.tradovateapi.com/mcp",
 "authorization_servers":["https://demo.tradovateapi.com"], ...}

$ curl -s https://demo.tradovateapi.com/.well-known/oauth-authorization-server
{"authorization_endpoint":"https://web.ninjatrader.com/oauth?env=demo", ...}

The env parameter selects the demo or the live backend. With mcp 1.26.0, the client opens this URL:

https://web.ninjatrader.com/oauth?env=demo?response_type=code&client_id=...

The consent page then parses the query as:

Parameter	Value
env	demo?response_type=code
client_id	15218
response_type	absent

Without response_type, the page stops treating the request as an authorization request. It renders a plain sign-in form with no consent panel, and sign-in lands on /welcome. No authorization code ever reaches the callback listener.

TypeScript SDK clients reach the same endpoint through new URL() and searchParams.set(), so they keep the env parameter and work. Only Python SDK clients break, which makes this easy to miss during provider testing.

Verification of #2779

Checking out #2779 and running _build_authorization_url against the live metadata gives:

Authorization endpoint	env	prompt	response_type
https://web.ninjatrader.com/oauth?env=demo	demo	n/a	code
https://web.ninjatrader.com/oauth?env=live	live	n/a	code
https://test.salesforce.com/services/oauth2/authorize?prompt=select_account	n/a	select_account	code
https://auth.example.com/authorize	n/a	n/a	code

uv run --frozen pytest tests/client/test_auth.py gives 137 passed and 1 xfailed on that branch.

The merge behavior looks right for both providers. Preserving duplicate keys and dropping None values covers more than the reported case does.

One blocker

The #2779 branch sits 50 commits behind main and no longer applies cleanly:

$ git apply --check pr2779.diff
error: patch failed: src/mcp/client/auth/oauth2.py:9
error: src/mcp/client/auth/oauth2.py: patch does not apply

A rebase might be all that stands between the branch and a review.

Happy to help test a rebased branch against the NinjaTrader endpoints if that's useful.

---

Disclosure. I used AI tooling to help investigate and to run the preceding checks. I reviewed the findings and reproduced them myself.

[braden-dev]

Railway's MCP server is a third production provider affected by this.

Reproduction against Railway

$ curl -s https://backboard.railway.com/.well-known/oauth-authorization-server | jq .authorization_endpoint
"https://backboard.railway.com/oauth/auth?resource=https%3A%2F%2Fbackboard.railway.com"

With mcp 2.0.0, the client opens:

https://backboard.railway.com/oauth/auth?resource=https%3A%2F%2Fbackboard.railway.com?response_type=code&client_id=...

Railway's authorization server rejects this outright with invalid_request (unlike the Salesforce/NinjaTrader cases where a page still renders), so the flow fails immediately rather than dead-ending at a consent screen.

Secondary symptom worth knowing about: callback port collisions

Because the failure is instant, client applications that retry the flow spin up a second localhost callback listener while the first attempt's listener is still bound, yielding:

OAuth callback port 27890 is already in use ([Errno 98] Address already in use)

In practice the user-visible errors alternate between invalid_request and Address already in use, which makes this look like a local networking/port problem and sends debugging in the wrong direction. Worth keeping in mind when triaging duplicate reports — "port already in use during MCP OAuth" reports may be this bug.

Fix verification

I can confirm the minimal form of the fix resolves it against Railway's live endpoint. Patching line 415 to join with & when the endpoint already carries a query string:

separator = "&" if "?" in auth_endpoint else "?"
authorization_url = f"{auth_endpoint}{separator}{urlencode(auth_params)}"

completes the full authorization-code + PKCE flow against Railway successfully (consent page renders, callback receives the code, tokens issued). #2779's urlparse-based merge is the more correct approach — it would handle this case as well, since Railway's resource param and the flow params have no key conflicts. +1 for rebasing that branch.

---

Disclosure: investigated and drafted with AI assistance; I reproduced the failure and verified the fix against Railway's live endpoints myself.