Sorry to hear you are having issues, judging by what you said and by what we changed from 1.4.2-1.4.3…
Most likely causes (ranked)
- Plugin activated but not enabled in settings
Activation only creates the option royal_mcp_settings[‘enabled’ => false] (royal-mcp.php:111). Nothing works until you toggle Enabled in Royal MCP → Settings. All requests return 403/503 with “Royal MCP is currently disabled” (Server.php:106-114, royal-mcp.php:194-202). This matches “no DB records” perfectly — requests die before anything gets written.
But you said OAuth showed the authorize screen — which would NOT happen if disabled (royal-mcp.php:196 returns 503 for non-metadata actions when disabled). So either it IS enabled, OR something I’m missing. Worth double-checking first.
- Cloudflare “Block AI Bots” / “Block AI Crawlers” Your own settings page warns about this (settings.php:434). Claude.ai‘s backend (not the user’s browser) makes the server-to-server calls for /register, /token, and /mcp. Cloudflare blocks Anthropic’s ASN by default on new zones. Symptoms match exactly:
- Default token: Anthropic backend POSTs /mcp → blocked → “Couldn’t reach MCP server”
- OAuth: browser loads /authorize (user’s IP, not blocked) → Authorize → redirect → Anthropic backend POSTs /token → blocked → “Authorization failed”
- Also explains empty tables — /register blocked → no client row written
- Rewrite rules not flushed after upgrade /authorize, /token, /register live at domain root via rewrite rules (royal-mcp.php:168-174). If you upgraded in place (not deactivate→reactivate), flush may not have run. Go to Settings → Permalinks → Save to force flush.
- Apache/LiteSpeed stripping Authorization header Common on shared hosting. validate_auth reads Authorization: Bearer … (Server.php:117). If the server drops that header before PHP sees it, every request 401s regardless of what Claude sends.
- Is the Enabled toggle on in Royal MCP → Settings?
- Is the site behind Cloudflare? If yes, turn off “Block AI Bots” (Security → Settings).
Go from there
I have checked everything and it seems fine. But I have another site using royal mcp plugin which connected to my claude desktop without any problem. will that be the case that I cannot connect two or more with claude?
It’s not a “two sites” limitation — Royal MCP is fine running on any number of sites, each is fully independent (separate DB tables, separate OAuth secrets, separate client registrations). The difference you’re describing between the two sites is actually the clue to your problem.
Your working site connects via Claude Desktop. Your failing one uses claude.ai in the browser. Those are very different network paths:
Claude Desktop connects from your own computer’s IP directly to the WordPress site. No Anthropic server is in the middle.
claude.ai (web) does NOT connect directly. The browser tells Anthropic’s backend to connect. Anthropic’s servers then hit your site’s /register, /token, and /mcp endpoints. Those requests come from Anthropic’s network (AS 399358).
If the failing site is behind Cloudflare, this is almost always the culprit. Cloudflare’s “Block AI Bots” / “Verified Bots” settings (Security → Settings → Bots) block Anthropic’s AS by default. Your site sees the block, not Royal MCP. Symptoms match exactly:
Default token mode: no /authorize step, so Anthropic goes straight to /mcp → blocked → “Couldn’t reach MCP server”
OAuth mode: /authorize happens in YOUR browser (not blocked), you click Authorize, then Anthropic’s backend calls /token → blocked → “Authorization failed”
Empty DB tables: /register is also blocked, so no client row ever gets written
To confirm it’s this: open your WordPress site’s access log (or Cloudflare → Security → Events) during a failed connection attempt. Look for 403s on /register, /token, or /wp-json/royal-mcp/v1/mcp from IPs not yours. If you see those 403s, it’s Cloudflare.
The ofid_ references in your error messages are Anthropic’s internal trace IDs, not ours. If Cloudflare isn’t the answer and you want Anthropic to check what their end saw, you can send those references to Anthropic support. We can’t decode them.
A couple more things worth checking:
On the failing site, visit https://YOURSITE.com/.well-known/oauth-authorization-server directly in your browser. It should return JSON. If you get a 404, your rewrite rules aren’t flushed — go to Settings → Permalinks → Save Changes (no need to change anything).
Is the failing site on any host that strips the Authorization header before it reaches PHP? Some shared hosts do this on LiteSpeed. If so, /mcp will always 401.
Let us know what you find and we’ll go from there.
I have tried with Claude desktop, when adding more than one custom connector to royal mcp, I could not get the second site authorized and connect. I have tried having the second site installed on different server and same thing happened with it. Having trouble connect and the authorized page getting skipped. And get skipped right back to the desktop without authorization or token input
Returning:
Couldn’t reach the MCP server. You can check the server URL and verify the server is running. If this persists, share this reference with support: “ofid_xxxxxxxxxxxxxx”
I am sure the server is running as my first site is connected without any problem. Please advise on the issue. thank you.
Thanks for testing on a second server — that rules out hosting/network as the cause, which is genuinely useful.
Before we dig further, one quick question so we test the exact same thing you’re seeing:
When you say “adding more than one custom connector to Royal MCP” and “the second site,” which of these are you doing?
(A) Two different WordPress sites, each with Royal MCP installed, added to Claude Desktop as two separate custom connectors (one per site).
(B) One WordPress site with Royal MCP, added to Claude Desktop as two separate custom connectors pointing at the same URL.
(C) Something else — please describe.
The reason I’m asking: scenario (B) is a configuration we’ve genuinely never tested at scale, and if that’s what you’re doing it’s likely a real bug we need to fix. Scenario (A) should work — every site is fully independent on our side — so if that’s failing it points to a different cause, and we’ll want to look at Claude Desktop’s logs.
If you can grab the Claude Desktop log from a failed connection attempt, that would also help a lot:
- Windows: %APPDATA%\Claude\logs\ (look for files starting with mcp-server- or
main)
- macOS: ~/Library/Logs/Claude/
The relevant lines are usually anything mentioning oauth, register, discovery, or your second site’s hostname. Feel free to redact tokens before pasting.
We’re going to try to reproduce both scenarios on our end in parallel.
Plugin Support
rpteam
(@rpteam)
Hi @beerloft — circling back. Since 1.4.3 we’ve shipped 1.4.13, 1.4.14, and 1.4.15
with several fixes that line up with what you reported:
• 1.4.13 — Added Cache-Control: no-store to OAuth endpoints (/register, /token,
/authorize). Pre-1.4.13, host-level edge caches (LiteSpeed, Cloudflare APO,
fastcgi cache) could pin an auth-error response and serve it back indefinitely
to every subsequent request.
• 1.4.14 — GET /wp-json/royal-mcp/v1/mcp without auth now returns
401 + WWW-Authenticate: Bearer instead of 405. This is what claude.ai’s web
connector probes for to start its OAuth flow — pre-1.4.14 it would silently
fail with exactly the “Couldn’t reach the MCP server” message you saw, with
no authorization window ever appearing.
• 1.4.15 — Same no-store headers extended to the /mcp endpoint itself and to
every response in the namespace (1.4.13 was a partial fix). Also flipped
invalid-API-key responses from 403 to 401 with a WWW-Authenticate header,
which is what RFC 9728 strict MCP clients need to fall back to OAuth
correctly.
If you’re up for retesting:
1. Update both sites to 1.4.15.
2. Settings → Permalinks → Save Changes on each (forces a rewrite flush in
case any /authorize routes weren't registered cleanly during prior upgrades).
3. If either site is behind Cloudflare, double-check that "Block AI Bots" /
"Verified Bots" is OFF — Anthropic's backend (AS 399358) makes the
server-to-server /register and /token calls, and Cloudflare blocks that
ASN by default on new zones. This was the most likely cause of your
original symptoms and we still see it bite people regularly.
4. Try connecting from claude.ai web again (since that was the failing path).
If it works, would you mind marking the topic as resolved or comment back as resolved so I can? That helps the next person Googling the same symptoms land on the answer faster. If it still doesn’t, please share which scenario applies (A/B/C from my earlier reply) and any new error message and we’ll dig back in.
— Royal Plugins
