Royal Plugins

Diagnosis: edge cache poisoning of /register, /token, and /authorize. This is a Royal MCP bug, but the practical impact is amplified by aggressive caches in front of WordPress — in your case, o2switch’s PowerBoost-v3, visible in your “server:” response header. It will be fixed in 1.4.13.

What’s happening: Royal MCP’s OAuth error responses (the 405 you’re seeing) ship without a Cache-Control header. When an aggressive edge cache sees that, it falls back to default heuristics and stores the response keyed by URL only — not by HTTP method. Once a single GET probe of /register returns the legitimate 405 — which can come from a security scanner, a stale Claude.ai discovery probe, a link checker, or even your own browser opening the URL once — the cache stores it. Every subsequent POST to the same URL gets served the same cached 405 and never reaches PHP. That’s why your Royal MCP Activity Log is empty during the failing requests, why the response body is byte-identical every time, and why your Cloudflare DNS-only test didn’t help (PowerBoost runs inside the o2switch stack, downstream of Cloudflare).

The cf-cache-status: DYNAMIC and x-litespeed-cache-control: no-cache headers you saw are correct but misleading — they describe Cloudflare and LiteSpeed’s view of the response, not what PowerBoost is doing.

Confirm with this test:

curl -v -X POST “https://yourdomain.com/register?_=$(date +%s)” -H “Content-Type: application/json” -H “Cache-Control: no-cache” -d ‘{“client_name”:”Test”,”redirect_uris”:[“https://claude.ai/api/mcp/auth_callback”%5D,”grant_types”:[“authorization_code”],”response_types”:[“code”],”token_endpoint_auth_method”:”none“}’

The unique query string and Cache-Control: no-cache request header should bypass the cache. If you get a 201 with a client_id in the response body, the diagnosis is confirmed and you can move to the workaround. If you still get a 405, please share the verbose curl output and we’ll dig deeper.

Workaround on 1.4.8 / 1.4.12 today: if you have the LiteSpeed Cache plugin active, go to Settings → Cache → Excludes → URI Excludes and add three lines: /register, /token, /authorize. For PowerBoost specifically, open a ticket with o2switch and ask them to exclude /register, /token, and /authorize from PowerBoost edge caching on your domain — these are dynamic OAuth endpoints from a plugin and must not be cached. The same idea applies to any other proxy in front of WP (Varnish, Cloudflare APO, custom CDN).

Once the cache is bypassed for those three URLs, the Claude.ai connector OAuth flow should complete normally on your current 1.4.8 install — no need to wait for the patch.

Permanent fix in 1.4.13: all OAuth endpoint responses (success and error) will send Cache-Control: no-store, no-cache, must-revalidate and Pragma: no-cache. This is what RFC 6749§5.1 already requires for token responses, and we should have been doing it on the registration and authorize endpoints from the start. Once shipped, no edge cache — regardless of vendor or aggressiveness — will be able to store these responses.

Thanks for the level of detail in the report — the empty Activity Log observation pointed straight at the cache layer and saved us a lot of guessing.

— Royal Plugins team

Thanks for all your feedback and support, ya we are waiting to hear back from several mcp server listing sites on how to handle docker file in a WP plugin like this, so its in motion.

Theme tools/options are addressed in V1.4.9 live now- you can update to test these new settings

Hey Micheal, thank you for the feedback and great suggestion, I will work on that!

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.

Awesome thanks for using our tool! If you could take a second and leave us a review, it really helps us!