Issue on OAUTH authorization

[arielsandor]

Client Information

• LLM Client: Toqan AI (work.toqan.ai)
• Client Config: No
• Using MCP Remote?: No
• MCP Server: [https://graphql.mcp.cloudflare.com, https://auditlogs.mcp.cloudflare.com, etc]

Describe the bug
Im trying to implement any Cloudflare MCP server on this AI agent, unsuccessfully. According to their documentation, they are using the RFC9728 Specs

https://modelcontextprotocol.io/specification/draft/basic/authorization#protected-resource-metadata-discovery-requirements

To Reproduce
Steps to reproduce the behavior:
Try to reach any of these URLs:
https://graphql.mcp.cloudflare.com/mcp/.well-known/oauth-protected-resource
https://graphql.mcp.cloudflare.com/mcp/.well-known/oauth-protected-resource/mcp
https://auditlogs.mcp.cloudflare.com/.well-known/oauth-protected-resource
https://auditlogs.mcp.cloudflare.com/mcp/.well-known/oauth-protected-resource

The same happens on any of the MCPs servers you provide

Expected behavior
On any of the request posted above, we should receive something like this:

{
  "resource": "https://your-mcp-server.com",
  "authorization_servers": [
    "https://auth.your-domain.com"
  ],
  "scopes_supported": [
    "mcp.tools.read",
    "mcp.tools.execute",
    "mcp.resources.read"
  ]
}

Is there any workaround for this?

Thanks

[wanmail]

You need to set a Cloudflare API key to read metadata.

[GraciousGazelles]

Adding a reproducible data point for https://bindings.mcp.cloudflare.com/mcp (observed 2026-02-12) that may help narrow this quickly.

Endpoint behavior:

• GET /mcp -> 401 with WWW-Authenticate: Bearer ... invalid_token ..., but no resource_metadata parameter.
• GET /.well-known/oauth-protected-resource -> 404
• GET /.well-known/oauth-protected-resource/mcp -> 404
• GET /.well-known/oauth-authorization-server -> 200 (valid OAuth metadata)
• GET /.well-known/oauth-authorization-server/mcp -> 404

Client impact:

• Strict MCP OAuth discovery clients fail auth discovery (No authorization support detected / resource_metadata_missing).
• mcp-remote still works because it falls back heuristically to root /.well-known/oauth-authorization-server when PRM is missing.

This seems aligned with the upstream OAuth provider gap tracked in cloudflare/workers-oauth-provider#70.

Potential acceptance criteria for resolution:

1. Include resource_metadata in WWW-Authenticate on protected MCP routes.
2. Serve RFC9728 protected resource metadata for MCP route(s).
3. Ensure authorization_servers values resolve to discoverable OAuth metadata for route-scoped MCP resources.

If helpful, I can provide a minimal curl script with expected/actual output matrix.

[GraciousGazelles]

Adding a tooling-neutral repro (HTTP only), so this is independent of any specific client implementation:

curl -i https://bindings.mcp.cloudflare.com/mcp
curl -i https://bindings.mcp.cloudflare.com/.well-known/oauth-protected-resource
curl -i https://bindings.mcp.cloudflare.com/.well-known/oauth-protected-resource/mcp
curl -i https://bindings.mcp.cloudflare.com/.well-known/oauth-authorization-server
curl -i https://bindings.mcp.cloudflare.com/.well-known/oauth-authorization-server/mcp

Observed today:

• /mcp -> 401 with WWW-Authenticate: Bearer ..., but no resource_metadata parameter.
• /.well-known/oauth-protected-resource -> 404
• /.well-known/oauth-protected-resource/mcp -> 404
• /.well-known/oauth-authorization-server -> 200
• /.well-known/oauth-authorization-server/mcp -> 404

So the issue is visible at protocol/endpoint level without relying on any specific MCP client behavior.