Support / Royal MCP / Royal MCP on SiteGround

Royal MCP on SiteGround: The Complete Setup Playbook

SiteGround is a good WordPress host that happens to have three specific infrastructure characteristics that stack together to make Royal MCP’s OAuth flow tricky. None of them are SiteGround being difficult; it’s just that Royal MCP’s OAuth flow lands on paths and Content-Types that SiteGround’s optimization layers treat differently than most WordPress requests. Fix all three in order and it works cleanly. Under 15 minutes end-to-end.

📍 Do the three layers in order

Each layer masks the next. If you skip Layer 1, Layers 2 and 3 have nothing to work with. If you fix Layer 3 without Layers 1 and 2, OAuth discovery still fails at first contact. The good news: you only have to do this once per site.

Prerequisite: Royal MCP 1.4.14 or newer

The Royal MCP 1.4.14 release fixed a GET /mcp returning 405 that Claude.ai treats as “server unreachable”, which stops the OAuth flow before it starts. Anything from 1.4.14 onward has this fix. Confirm your version at WP Admin → Plugins → Installed Plugins, and update if needed before working through the three layers below.

The Three Layers, in Order

Layer 1: SiteGround’s nginx intercepts /.well-known/*

Symptom: curl on the OAuth metadata URL returns a tiny 404 with Server: nginx and no X-Httpd header. WordPress never sees the request.

Verify:

curl -sI https://your-site.com/.well-known/oauth-authorization-server

Windows PowerShell users: use curl.exe for every curl in this playbook, and skip the | grep pipes further down (just read the full response and eyeball the header instead).

Fix in one line: create two static JSON files in your webroot at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource. SiteGround serves anything that physically exists at /.well-known/; it just refuses to fall through to WordPress otherwise. Full walkthrough with the exact file contents:

SiteGround Returns 404 for /.well-known/
Step-by-step: create the static files via SiteGround File Manager or SFTP, with the exact JSON body to paste.

Layer 2: Those static files get served as text/plain not application/json

Symptom: after Layer 1, the same curl now returns 200 with the JSON body, but the Content-Type header shows text/plain (or nothing at all). RFC 8414 requires OAuth discovery to serve application/json. Strict MCP clients (Claude Desktop, mcp-remote) reject the metadata even though the body parses.

Verify:

curl -sI https://your-site.com/.well-known/oauth-authorization-server | grep -i content-type

Fix in one line: a free Cloudflare Transform Rule at the edge overrides the response Content-Type to application/json. Since SiteGround moved to Google Cloud infrastructure they no longer make per-customer nginx overrides, and .htaccess ForceType is silently ignored because nginx serves /.well-known/ files directly without falling through to Apache. The Cloudflare edge is the working path. Two-minute setup:

Fix /.well-known/ Content-Type with a Cloudflare Transform Rule
Step-by-step Cloudflare dashboard walkthrough. Free plan works. No SiteGround support ticket needed.

Layer 3: SG Optimizer Dynamic Cache poisons the OAuth handshake endpoints

Symptom: after Layers 1 and 2, discovery works but Claude.ai still shows “Authorization with the MCP server failed” after clicking Authorize. The /authorize, /token, or /register endpoints return stale cached responses from earlier probe attempts.

Verify:

curl -sI https://your-site.com/authorize | grep -iE 'x-cache|x-proxy-cache'

If any of these headers appear in the response with a non-empty or HIT / True value, cache is in the way. SiteGround emits x-cache-enabled and x-proxy-cache-info; other stacks use HIT / MISS on x-cache.

Fix in one line: in SG Optimizer → Caching → Dynamic Cache → Exclude URLs, add /wp-json/royal-mcp/*, /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource, /authorize, /token, and /register. Then Purge SG Cache from the toolbar. The purge is critical, without it any cached 4xx responses from earlier attempts keep getting served regardless of the new exclusions. Full walkthrough with screenshots:

OAuth Fails on Managed Hosts (SiteGround, o2switch, LiteSpeed) → Option A
SG Optimizer exclusion list + purge instructions + how to spot cache-hit headers on the OAuth endpoints.

Verify the Connection Works

After all three layers are in place, add the connector in Claude.ai (or Claude Desktop) with just your MCP URL and Advanced Settings empty. What success looks like:

  1. Claude’s OAuth consent screen appears (you grant access).
  2. Claude shows the connector as connected in Settings.
  3. Try a prompt like “list my last 5 WordPress posts” and real data comes back.
  4. WP Admin → Royal MCP → Activity Logs shows an oauth:register row followed by oauth:authorize and oauth:token Success entries.

Need It Working Today? Skip OAuth Entirely with Claude Desktop

If you can use Claude Desktop instead of Claude.ai web, you can sidestep all three layers above. Royal MCP supports API-key authentication via mcp-remote’s --header flag, no /.well-known/ discovery, no consent screen, no Cloudflare Transform Rule. Confirmed working on SiteGround. Two-minute setup:

Connect Claude Desktop via API key
Paste 8 lines into your Claude Desktop config, restart, done. Bypasses OAuth completely.
Credit

The three-layer breakdown in this playbook was distilled by @vipestudio on the wp.org forum after working through the full sequence himself. His summary captured what several rounds of our own support responses hadn’t yet consolidated in one place. Thanks Ivan.

Back to Troubleshooting Start Here Royal MCP Support Hub