code_challenge_methods_supported is missing from the authorization server metadata
The MCP authorization spec requires clients to refuse an authorization server whose metadata does not advertise PKCE S256 — but OpenID Connect Discovery never defined the field, so an OIDC-only identity provider omits it, and a client that reads the spec strictly stops before the consent screen.
npx mcpcomp https://mcp.example.com/mcpThe client-compatibility.pkce-s256 check names the document it read and cites the requirement.
What the error means
RFC 8414 defines code_challenge_methods_supported; OIDC Discovery does not. If your authorization server only publishes /.well-known/openid-configuration, the field is typically absent. The MCP spec binds clients to refuse an authorization server that does not offer S256 — a requirement on clients, not servers, which is why MCPComp reports a server-side omission as an advisory rather than a graded violation. Some clients tolerate absence and only fail when the field is present without S256 — the reference TypeScript SDK does exactly that — which is why the same server works in one client and fails in another.
How to diagnose it
Check which document the client actually reads
Clients walk a discovery ladder: RFC 8414 at /.well-known/oauth-authorization-server (path-aware, then root), then OIDC at /.well-known/openid-configuration. WorkOS AuthKit, for instance, advertises PKCE in its RFC 8414 document and omits it from its OIDC document — the rung the client lands on decides the verdict. MCPComp resolves the ladder the way the SDK does and reports which document it used.
Advertise S256 explicitly
Add code_challenge_methods_supported: ["S256"] to the metadata your issuer serves, on every rung the client may reach. Do not list "plain" — MCPComp reports it as an advisory: S256 is mandatory, and a client that takes the first method it recognises, or a stripped response, downgrades to a challenge that protects nothing.
Frequently asked questions
My server works in Cursor but not in another client. Why?
Clients differ on whether an absent field is fatal. The reference TypeScript SDK only rejects metadata that lists methods without S256; stricter clients reject absence too. Publishing the field ends the disagreement.
Is this my MCP server's fault or the identity provider's?
The identity provider publishes the metadata, but the MCP server chose which issuer to list in its protected-resource metadata. The fix is on the IdP side; the symptom is reported against the MCP server.