DCR auto-detection fails on RFC-compliant MCP servers (Royal MCP / WordPress)

[royalplugins]

Summary

The "Add new MCP connector" dialog in Apify Console greys out the OAuth radio with the message "This server doesn't support dynamic client registration. Your own OAuth client is recommended." for a server that does implement DCR (RFC 7591) plus the full RFC 8414 + RFC 9728 discovery chain.

Reproducer below uses a public Royal MCP install at https://demo.royalplugins.com.

Expected

Apify Console reads WWW-Authenticate: Bearer resource_metadata="..." from the 401 → fetches /.well-known/oauth-protected-resource → resolves the auth-server URL → fetches /.well-known/oauth-authorization-server → sees registration_endpoint → offers the OAuth (DCR) radio in the dialog.

Observed

OAuth radio is greyed out with the "doesn't support DCR" message. API-key auth still works; "Your own OAuth client" also works if a client_id is registered manually.

Reproduction probes

# 1. RFC 9728 WWW-Authenticate on 401
curl -i -X POST 'https://demo.royalplugins.com/wp-json/royal-mcp/v1/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'
# → 401 + WWW-Authenticate: Bearer resource_metadata="https://demo.royalplugins.com/.well-known/oauth-protected-resource"

# 2. RFC 9728 protected resource metadata
curl 'https://demo.royalplugins.com/.well-known/oauth-protected-resource'
# → {"resource":"https://demo.royalplugins.com/wp-json/royal-mcp/v1",
#    "authorization_servers":["https://demo.royalplugins.com"],
#    "bearer_methods_supported":["header"],
#    "scopes_supported":["mcp:full"]}

# 3. RFC 8414 authorization server metadata
curl 'https://demo.royalplugins.com/.well-known/oauth-authorization-server'
# → {"issuer":"https://demo.royalplugins.com",
#    "authorization_endpoint":"https://demo.royalplugins.com/authorize",
#    "token_endpoint":"https://demo.royalplugins.com/token",
#    "registration_endpoint":"https://demo.royalplugins.com/register",
#    "response_types_supported":["code"],
#    "grant_types_supported":["authorization_code","refresh_token"],
#    "token_endpoint_auth_methods_supported":["none","client_secret_post"],
#    "code_challenge_methods_supported":["S256"],
#    "scopes_supported":["mcp:full"],...}

# 4. RFC 7591 Dynamic Client Registration
curl -X POST 'https://demo.royalplugins.com/register' \
  -H 'Content-Type: application/json' \
  -d '{"client_name":"apify-dcr-test","redirect_uris":["https://console.apify.com/oauth/callback"]}'
# → 201 + {"client_id":"rmcp_...",
#    "client_name":"apify-dcr-test",
#    "redirect_uris":["https://console.apify.com/oauth/callback"],
#    "grant_types":["authorization_code"],
#    "token_endpoint_auth_method":"none",
#    "response_types":["code"],
#    "client_id_issued_at":...}

All four steps respond with what the RFCs specify. From outside the server looks healthy.

Likely culprits

A few guesses for where the auto-detect might be going wrong:

• Probing <mcp-base-url>/.well-known/oauth-authorization-server directly instead of following the issuer URL from the protected-resource metadata
• Requiring a client_secret in the DCR response even for public clients (token_endpoint_auth_method: "none")
• Not parsing the resource_metadata parameter out of WWW-Authenticate

Happy to help diagnose. Royal MCP source is GPL-2.0 at https://github.com/royalplugins/royal-mcp — the auth + discovery code lives in includes/MCP/Server.php and includes/OAuth/.

Why this matters

Walkthrough of the Apify ↔ WordPress integration: https://royalplugins.com/blog/connect-apify-to-wordpress-with-royal-mcp/. Works via API key; auto-DCR would be the cleaner first-run UX.

Thanks for shipping MCP connectors — really exciting direction.