MCP Python SDK 2.2 protected resource metadata 5xx stops OAuth

With MCP Python SDK 2.2.0, a 5xx or 429 on the protected resource metadata request ends the OAuth flow instead of falling back to the legacy endpoints. For Sume, check that both metadata URLs return 200; in the server code the handlers answer with a 200 JSON body.

The release notes (2.2.0, 2026-09-07) say: "If protected resource metadata can't be fetched because of a 5xx/429, the flow now stops instead of falling back to the legacy endpoints." Sume URLs are from MCP OAuth and API keys, read 2026-10-01.

What changed for a client that hits a metadata error?

Before, a failed metadata fetch could drop through to legacy discovery. Now a transient server error is surfaced and the flow stops, so a flaky metadata route shows up as a failed connection rather than a quiet fallback. The same notes also list that authorization server metadata whose issuer is not the server's own origin is rejected for servers without protected resource metadata.

Which Sume URLs does the flow request?

Sume serves protected resource metadata at the root well-known path and at the /mcp-suffixed path. The docs publish the suffixed one, and authorization_servers is the MCP origin.

for path in \
  /.well-known/oauth-protected-resource \
  /.well-known/oauth-protected-resource/mcp; do
  curl -s -o /dev/null -w "%{http_code} $path\n" "https://mcp.sume.com$path"
done

What if I see a 5xx or 429 there?

Capture the status code and the Sume request id header, and retry once or twice from another network before blaming the SDK. A corporate proxy or egress limit can return its own 5xx or 429 for a well-known path. Under SDK 2.2.0 the flow will not recover by itself, so rerun the connect once the URL returns 200.

Does a metadata failure risk any spend?

No. Discovery only reads public metadata. Spend begins at paid tool calls, which need mcp:write (or an API key) and an idempotency_key. For the issuer rule in the same release, see MCP Python SDK authorization server issuer mismatch.