• Resolved snowmonkey78

    (@snowmonkey78)


    Claude.ai connector: “Couldn’t connect to the server” on Royal MCP 1.5.6 – client never starts OAuth

    Site: snowmonkey.cz, WP + Divi 4.27.6, Apache, no Cloudflare. Royal MCP 1.5.6, OAuth state reset before testing.
    Claude.ai custom connector (URL /wp-json/royal-mcp/v1/mcp) shows “Couldn’t connect to the server. Check that the URL points to a valid MCP server.”
    Protocol Insights: client “Anthropic/ClaudeAI”, protocol 2026-07-28, methods server/discover and initialize only. The server answers 401 with -32600 Authentication required and WWW-Authenticate: Bearer resource_metadata=… (two challenges in one header).
    Activity Log shows NO oauth:register or oauth:authorize after the reset, so the client gives up before starting OAuth.
    Both protected-resource metadata URLs (root and path-suffixed) return 200 application/json with the correct resource, and the authorization-server metadata returns S256 + client_id_metadata_document_supported: true.
    On 1.4.45 (Sept 3) the same client got as far as oauth:register (success) and then oauth:authorize failed with an empty client_id.
    Could server/discover (unauthenticated) need a non-401 response for protocol 2026-07-28, or could the duplicate Bearer challenge be the issue?

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support jayson35

    (@jayson35)

    Hey @snowmonkey78

    Thanks for the detailed write-up. Your second guess is almost certainly the cause.

    We checked snowmonkey.cz from outside. Everything else is healthy: both protected-resource documents return the correct resource, the authorization-server metadata is fine, and /register is reachable. The 401 on server/discover is also correct, since the MCP spec requires authorization on every request. The problem is the two Bearer challenges joined into one WWW-Authenticate header in 1.5.6.

    From our testing this only affects the Claude.ai connector. Clients built on the official MCP SDK (Claude Code, Cursor, VS Code, and Claude Desktop’s config-file setup) read that header correctly.

    Here’s a small fix you can install right now while we finish the next release:

    1. Download https://royalplugins.com/downloads/royal-mcp-single-challenge.zip and unzip it.
    2. Upload royal-mcp-single-challenge.php to wp-content/mu-plugins/ (create the mu-plugins folder if it doesn’t exist). Must-use plugins load automatically, so there’s nothing to activate.
    3. Check it’s working. The WWW-Authenticate line should now contain a single Bearer resource_metadata="..." value:

    curl -s -D – -o /dev/null -X POST https://snowmonkey.cz/wp-json/royal-mcp/v1/mcp -H “Content-Type: application/json” -H “MCP-Protocol-Version: 2026-07-28” -d “{\”jsonrpc\”:\”2.0\”,\”id\”:1,\”method\”:\”server/discover\”,\”params\”:{}}”

    1. Reset the OAuth state in Royal MCP, then in Claude.ai delete the connector, wait a minute, and add it again with the same URL.

    Delete the file once you’ve updated Royal MCP to the next release, which includes the fix.

    If Claude.ai still stops before oauth:register, reply with what the Activity Log and Protocol Insights show for that attempt and we’ll dig further. In the meantime you can also connect Claude Desktop with an API key, which skips OAuth entirely:
    https://royalplugins.com/support/royal-mcp/connect-claude-desktop-api-key/

    RP Team

    Plugin Support jayson35

    (@jayson35)

    Hey @snowmonkey78

    Royal MCP 1.5.7 is out on WordPress.org and includes the fix for this. The server now sends a single authentication challenge, so the Claude.ai connector completes discovery and registration on its own.

    To move over:

    1. Update Royal MCP to 1.5.7 (Dashboard > Updates).
    2. Remove the temporary workaround file from wp-content/mu-plugins/ – it is no longer needed and the download has been taken down.
    3. In Claude.ai, delete the old connector and add it again with https://your-site/wp-json/royal-mcp/v1/mcp so it picks up a fresh sign-in.

    1.5.7 also adds a Connected Clients screen under Royal MCP where you can see the Claude.ai connection and revoke it if you ever need to, plus a Site Health check that confirms the sign-in addresses are reachable from outside.

    Going to close this ticket and assume you’re good, if anything still fails after the update, paste the Protocol Insights lines again and we’ll take another look.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.