rpteam

Hi @alexandregenesis — circling back. The fix shipped in 1.4.13 as promised,
plus follow-on fixes in 1.4.14 and 1.4.15 worth noting.

1.4.13 (your specific fix): /register, /token, /authorize now send
Cache-Control: no-store, no-cache, must-revalidate, private and
Pragma: no-cache on every response. Should make the PowerBoost
cache-poisoning behavior you diagnosed structurally impossible.

1.4.14: GET /wp-json/royal-mcp/v1/mcp (without auth) now returns
401 + WWW-Authenticate: Bearer instead of 405 — restores Claude.ai web’s
RFC 9728 OAuth discovery probe.

1.4.15: Same no-store headers extended to the /mcp endpoint and every response
under /wp-json/royal-mcp/* — 1.4.13 was a partial fix, /mcp itself was still
vulnerable to the same edge-cache poisoning pattern. Also flipped 403→401 for
invalid API key (RFC 7235 alignment, helps strict MCP clients fall back to
OAuth correctly).

To verify after updating to 1.4.15:

curl -v -X POST "https://yoursite.com/register?_=$(date +%s)" \
  -H "Content-Type: application/json" \
  -d '{"client_name":"Test","redirect_uris":["https://claude.ai/api/mcp/auth_callback"],"grant_types":["authorization_code"],"response_types":["code"],"token_endpoint_auth_method":"none"}'

Response headers should now include Cache-Control: no-store, ... and the body
should be a 201 with client_id. Then try the Claude.ai connector directly —
should complete OAuth without the cache excludes you configured as a workaround.

If you still get a cached 405 even with the fresh query string, that means
PowerBoost is overriding Cache-Control: no-store on its own response
interception — a host-side bug worth escalating to o2switch. The
/register, /token, /authorize cache excludes would remain the permanent
solution in that case.

Mind giving 1.4.15 a try and letting us know? If it works without the manual
cache excludes, please mark the topic as resolved — helps the next person on
a LiteSpeed/PowerBoost setup land on the right answer faster.

— Royal Plugins team

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

Hi René,

I tested every endpoint on terraexperty.com from our side just now, and have a definitive picture for you. The good news: Royal MCP on your site is fully functional. Every OAuth endpoint reaches PHP correctly:

GET /.well-known/oauth-authorization-server → 200 ✅
GET /.well-known/oauth-protected-resource → 200 ✅
GET /wp-json/royal-mcp/v1/mcp → 401 ✅ (with WWW-Authenticate:
Bearer resource_metadata=”…”)
POST /register → 201 ✅ (dynamic client registration confirmed working — I just registered a test client and it succeeded)
GET /authorize → reaches PHP (X-Httpd: 1)

The 1.4.14 fix is verified live. DCR works. The plugin is doing its job.

Two important corrections on what you’re seeing:

1. Empty debug.log is GOOD news, not bad. WordPress’s debug.log only captures PHP
   errors and notices, not request traffic. An empty debug.log during OAuth attempts
   means no PHP errors were thrown — which is exactly what you want. It does NOT mean
   Claude.ai’s requests aren’t reaching your server. Royal MCP also doesn’t write
   OAuth handshake events to its own Activity Log (that log is for post-auth MCP tool
   calls). To see actual request traffic during OAuth attempts, pull your nginx
   access log from SiteGround Site Tools → Statistics → Access Log.
2. The most likely remaining blocker is Content-Type on your static files. Both
   .well-known/ files are returning: Content-Type: text/plain RFC 8414 §3.2 requires OAuth discovery responses to be served as application/json (“a successful response MUST use the 200 OK HTTP status code and return a JSON object using the application/json content type”). Most clients are lenient and parse JSON regardless of Content-Type. Strict clients reject the metadata even
   though the body is valid JSON. Another customer on SiteGround GrowBig hit this
   same fingerprint recently — same host configuration, same text/plain, same OAuth
   failure. That’s two production data points pointing at the same root cause. Two paths forward, depending on your use case:

Path A — Fix the Content-Type properly (works for Claude.ai web AND Claude Desktop) Open a SiteGround support ticket with this exact wording:

“We have two static files at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource that are required by RFC 8414 (OAuth 2.0 Authorization Server Metadata). They are currently being served with Content-Type: text/plain because they have no file extension, but RFC 8414 §3.2 mandates Content-Type: application/json. .htaccess ForceType doesn’t apply since nginx serves these files directly without falling through to Apache. Could you please add an nginx-level MIME type override so files at these two specific paths are served as application/json? They contain valid JSON; only the Content-Type header needs correction.”

SiteGround has granted similar exceptions for other customers’ OAuth needs.

Path B — Skip OAuth entirely on Claude Desktop (works in 2 minutes, today)

If your goal is to get Royal MCP working with an AI assistant and Claude Desktop
is acceptable for your workflow, you can bypass the OAuth flow entirely. Royal MCP
supports API-key authentication via mcp-remote’s –header flag — no
/.well-known/, no discovery, no consent screen. Confirmed working on SiteGround
GrowBig.

Full walkthrough:
https://royalplugins.com/support/royal-mcp/connect-claude-desktop-api-key.html

Quick version — paste this into your Claude Desktop config
(claude_desktop_config.json), substituting your API key from WP Admin → Royal MCP
→ Settings:

{
    "mcpServers": {
      "terra-experty": {
        "command": "npx",
        "args": [
          "-y",
          "mcp-remote",
          "https://terraexperty.com/wp-json/royal-mcp/v1/mcp",
          "--header",
          "X-Royal-MCP-API-Key: YOUR_KEY_HERE"
        ]
      }
    }
  }

Restart Claude Desktop and you’re connected.

Path A is the proper fix and unblocks Claude.ai web. Path B works around the issue
today if waiting on SiteGround isn’t workable.

Best,
Jameson

– Royal Plugins

Hi René,

I see the issue now, will have update addressing this in next 24hrs V1.4.14 – be on the lookout

Hi René,

Perfect — that confirms exactly what we suspected. SiteGround’s nginx will serve files
from /.well-known/ if they physically exist; it just refuses to fall through to
WordPress when they don’t. So the workaround is to drop two static files in your
webroot.

File 1: /.well-known/oauth-authorization-server (no file extension)

{
“issuer”: “https://terraexperty.com”,
“authorization_endpoint”: “https://terraexperty.com/authorize”,
“token_endpoint”: “https://terraexperty.com/token”,
“registration_endpoint”: “https://terraexperty.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”],
“service_documentation”: “https://royalplugins.com/support/royal-mcp/”
}

File 2: /.well-known/oauth-protected-resource (no file extension)

{
“resource”: “https://terraexperty.com/wp-json/royal-mcp/v1”,
“authorization_servers”: [“https://terraexperty.com”%5D,
“bearer_methods_supported”: [“header”],
“scopes_supported”: [“mcp:full”]
}

Steps:

1. Via SiteGround File Manager (Site Tools → Site → File Manager) or SFTP, navigate to
   your WordPress root (the folder containing wp-config.php).
2. Create a folder named .well-known if it doesn’t exist.
3. Inside it, create two files with no extension — name them exactly
   oauth-authorization-server and oauth-protected-resource.
4. Paste the JSON content above into each, save. Verify with curl: curl -i https://terraexperty.com/.well-known/oauth-authorization-server
   curl -i https://terraexperty.com/.well-known/oauth-protected-resource You should see HTTP/2 200 and the JSON body. If you see a 404, the file path is off —
   double-check the folder name starts with a dot. If the Content-Type header comes back as application/octet-stream rather than
   application/json, that’s fine — Claude.ai parses these endpoints as JSON regardless.
   If for any reason Claude still rejects, drop a .htaccess next to the files with: ForceType application/json
   ForceType application/json Once the files are live, retry the Claude.ai connection. We’re scoping a 1.4.14
   release that will auto-create these for SiteGround/managed-host users so this isn’t a
   manual step going forward — thanks for the patience and for helping us pin this down.

Best
Jameson

Hi René,

Thanks for the detailed write-up — you’ve already ruled out most of the usual suspects, which actually helps a lot. We’ve seen this exact failure mode on managed-WordPress hosts that run NGINX-level dynamic caching (SiteGround, o2switch, LiteSpeed). Even with Cloudflare removed, SiteGround’s own Speed Optimizer cache layer is still in front of WordPress, and it sometimes ignores the cache-bypass headers we send on the OAuth endpoints.

Before we dig deeper, two quick checks will tell us exactly what’s happening:

1. Confirm your Royal MCP version WP Admin → Plugins → Royal MCP. We need 1.4.13 or newer — earlier versions had a known cache-poisoning bug we fixed in 1.4.13. If you’re on an older build, please update first and retry the connection.
2. Check the Activity Log WP Admin → Royal MCP → Activity Log, then attempt the Claude.ai authorization again. Look for entries timestamped at the moment you clicked “Authorize.”

• Entries appear: OAuth is reaching WordPress — the issue is in the flow itself, and we’ll dig into the specific log lines.
• Log stays empty: The request never reached PHP, which confirms an upstream cache or WAF is short-circuiting it. This is the more likely scenario on SiteGround.

3. Inspect the cache headers (1 minute) Run this from any terminal — it tells us whether SiteGround is serving cached responses for our OAuth endpoints: curl -I https://terraexperty.com/wp-json/royal-mcp/v1/oauth/.well-known/oauth-authorization-server Send us the full response headers. We’re looking specifically for x-cache, x-proxy-cache, or x-sg-cache — if any of those show HIT, we’ve found the problem. If the Activity Log is empty (most likely): The fix is to exclude the OAuth and MCP endpoints from SiteGround’s Dynamic Cache. In WP Admin → SG Optimizer → Caching → Dynamic Cache → Exclude URLs, add these patterns: /wp-json/royal-mcp/*
   /wp-json/royal-mcp/v1/oauth/*
   /.well-known/oauth-authorization-server
   /.well-known/oauth-protected-resource

Then click Purge Cache in the SG Optimizer toolbar and retry the Claude.ai connection. This has resolved the same symptom for us on other NGINX-cached hosts.

If that doesn’t clear it, also worth checking SiteGround → Site Tools → Security → Site Scanner / Web Application Firewall — some custom WAF rules block JSON POSTs to non-standard REST namespaces, which would also produce the silent failure you’re describing.

Reply with the Activity Log findings and curl headers and we’ll take it from there. We’ll get this connected!

Best,
Jameson
Royal Plugins