rpteam

Thanks for the detailed write-up — that level of triage actually narrows this down a lot.

Your symptom matches a pattern we now see frequently on managed shared hosts (SiteGround included): the OAuth consent screen renders fine because your browser hits /authorize, but the
server-to-server POST /token step is made by Claude’s broker with User-Agent: python-httpx/0.28.1 from Anthropic’s IP range 160.79.104.0/22. On several managed stacks, the host’s edge security layer (separate from any page/cache exclusion in the optimizer plugin) blocks that User-Agent or that IP range before the request reaches WordPress. The request never hits our PHP, so it looks like our /token rejected it — but really it never arrived.

A few minutes of work should tell us if this is your case.

1. The one log line that routes this in a single round-trip Go to WP Admin → Royal MCP → Logs (or Activity Log on slightly older versions). Reproduce the failure, then look for entries around that timestamp. Three possible shapes:

• A row for /token with error + description (e.g. invalid_grant: …, invalid_client: …, invalid_request: …) — that’s a PHP-layer rejection, fixable cleanly.
• A row for /authorize but no row for /token at all — that’s the host-WAF-blocking-the-token-POST pattern. Anthropic’s request never reached us.
• No rows at all for the attempt — same family as the above; the edge layer is dropping requests before they hit WordPress.
  
  Paste whichever you see

1. Two curl probes you can run yourself to confirm (or rule out) the edge block From any external machine (your laptop is fine):
   curl -A “Mozilla/5.0 Chrome/120.0” \
   -X POST https://dizionedigitale.it/register \
   -H “Content-Type: application/json” \
   -d ‘{“redirect_uris”:[“http://localhost”%5D,”client_name”:”diag”}’
   
   curl -A “python-httpx/0.28.1” \
   -X POST https://dizionedigitale.it/register \
   -H “Content-Type: application/json” \
   -d ‘{“redirect_uris”:[“http://localhost”%5D,”client_name”:”diag”}’
   
   If the browser-UA probe returns 201 Created (or a JSON invalid_request 400) but the python-httpx-UA probe returns a 403/406/429 — confirmed. The fix is on the host side: ask SiteGround support to allow User-Agent: python-httpx/* on these paths, or to allow Anthropic’s IP range 160.79.104.0/22, or to add path exclusions for /register, /authorize, /token, /wp-json/royal-mcp/*, /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource. SiteGround support can usually action this same-day.
2. Two other possibilities worth quickly eliminating while you wait on the log entry

• Static client secret saved? In Royal MCP → Settings → Advanced, the Generate button populates the input but doesn’t persist until you click Save Settings at the bottom of the page.
  
  If Client ID was saved but Client Secret was Generated-then-not-Saved, the token POST fails with invalid_client. Reload that admin page — both fields should still show values after
  the reload. If either is blank after reload, click Generate + Save Settings, then re-enter both into the Claude connector’s Advanced Settings (fresh paste — don’t reuse the prior
  values).
• Static .well-known/ files — you said you verified single https:// prefixes, but please double-check all four fields in both files (issuer, authorization_endpoint, token_endpoint,
  registration_endpoint). A common gotcha is the first field looking right while one of the endpoint lines silently has https://https://.
  Just curl https://dizionedigitale.it/.well-known/oauth-authorization-server and eyeball the JSON.

If you need MCP working immediately while we sort this Claude Desktop’s API-key path bypasses OAuth entirely — no /register, /authorize, /token involved, so the edge-WAF question doesn’t apply. Setup is one block in your Claude Desktop config using mcp-remote –header X-Royal-MCP-API-Key: . Walkthrough: https://royalplugins.com/support/royal-mcp/connect-claude-desktop-api-key.html. Customers blocked on Claude.ai web for host-WAF reasons often use this as the working transport while their host adjusts the rules. Send the log entry (or the curl results) and we’ll close this out.

Glad to report we got this connected and working. Sharing the two issues we
identified — both fixed now — in case anyone else lands here with similar
symptoms.

Issue 1: ambiguous placeholder in our SiteGround static-files walkthrough

Our /.well-known/ 404 fix walkthrough
(https://royalplugins.com/support/royal-mcp/siteground-well-known-404.html) used
YOUR-DOMAIN.com as a placeholder inside the JSON template. The intent was “swap
with your bare domain,” but a reasonable reading was to swap with the full URL
https://yoursite.com — which produced https://https://yoursite.com/authorize
(etc.) in the saved static file. Browsers then parse the resulting URL with
https as the hostname, DNS lookup fails, and you get a
DNS_PROBE_FINISHED_NXDOMAIN / “site can’t be reached” page when OAuth tries to
redirect.

If you see doubled https://https:// on any of the OAuth endpoint URLs in your
/.well-known/oauth-authorization-server response, edit your static files and
remove the duplicates. We’ve patched the walkthrough to use a literal
example.com placeholder with explicit “do NOT include https:// in your
replacement” guidance and a verification step, and swept the same fix across the
rest of our support docs so this shouldn’t trip anyone else.

Issue 2: Microsoft Store version of Claude Desktop uses a sandboxed config path

If you installed Claude Desktop from the Microsoft Store, it’s sandboxed and
reads/writes config from
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ — NOT
the standard %APPDATA%\Claude\ that every Anthropic doc and our own walkthroughs
reference. Manual edits to the config at the standard path get silently ignored, restart Claude Desktop all you want, nothing picks up.

Two fixes:

• Uninstall the Microsoft Store version and reinstall from https://claude.ai/download (recommended — every documented walkthrough then
  works as written), or…
• Put your config at the sandboxed path above We’ve added a warning to the Connecting to Claude walkthrough (https://royalplugins.com/support/royal-mcp/connecting-to-claude/#browser-and-desktop) so this is surfaced upfront on Windows installs. Marking this resolved. If anyone hits either of these and the guidance above doesn’t get you unstuck, please open a fresh thread.

RP Team

• This reply was modified 2 weeks, 1 day ago by rpteam. Reason: typo

Hi — quick correction to my last reply. After running deeper probes against your site, I’ve identified the actual root cause and it’s NOT one of the five invalid_grant / invalid_request cases I asked you to
check for. It’s a layer above.

The block is at your hosting provider’s edge, not at Royal MCP.

Reproducible from any external machine:

$ curl -A “python-httpx/0.27.0” https://kemoso.com/.well-known/oauth-authorization-server
HTTP/1.1 429 Too Many Requests
Content-Type: text/html; charset=iso-8859-1
Too Many Requests

vs.

$ curl -A “Mozilla/5.0” https://kemoso.com/.well-known/oauth-authorization-server
HTTP/1.1 200 OK
Content-Type: application/json
{“issuer”:”https://kemoso.com”,”authorization_endpoint”:”https://kemoso.com/authorize”, … }

Confirmed across two separate probes three minutes apart — the 429 is persistent and User-Agent-targeted, not burst rate limiting. The plain text/html; charset=iso-8859-1 body shape is a cPanel-managed-security
signature, likely Imunify360 or mod_security with a UA filter rule active on your account.

Why this matches your symptom perfectly:

1. You open /authorize in your browser → 200 OK (real Chrome UA, not blocked)
2. You click Authorize → consent screen renders correctly ✅
3. Behind the scenes, Anthropic’s backend POSTs /token using User-Agent: python-httpx/* → Xneelo’s WAF returns 429 before the request ever reaches your WordPress install
4. Your client sees mcp_token_exchange_failed
5. The oauth:token → ERROR row you see in the Activity Log is most likely from the browser-side /authorize step, OR a single intermittent /token POST that slipped through. The dominant failure mode is the 429 at the edge.

Fix — Xneelo support ticket

Royal MCP can’t change what User-Agent Anthropic sends. The fix has to happen at the Xneelo / WAF layer. Paste this verbatim into a support ticket with Xneelo:

Hi Xneelo support,

My WordPress site at kemoso.com runs a plugin (Royal MCP) that needs to accept OAuth requests from a service that uses the User-Agent string python-httpx/0.27.0. Your managed security stack is currently returning 429 Too Many Requests for any request with that User-Agent — even for single, non-bursty requests.

Reproducible from any external IP:

curl -A "python-httpx/0.27.0" https://kemoso.com/.well-known/oauth-authorization-server
returns 429 Too Many Requests, while

curl -A "Mozilla/5.0" https://kemoso.com/.well-known/oauth-authorization-server
returns 200 OK with the expected JSON response.

Could you please either:
1. Whitelist User-Agent: python-httpx/* on this domain, OR
2. Exclude these specific paths from User-Agent-based filtering: /register, /authorize, /token, /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource

The whitelist is preferable as it allows the plugin's authentication to work site-wide. The path exclusion is an acceptable fallback.

Thanks!

Once Xneelo applies that change, the OAuth flow should complete end-to-end. No changes needed on the WordPress / Royal MCP side.

RP Team

Hi,

Good news on both counts — what you’re asking for already exists, and there’s a better
path for Elementor specifically.

The post-meta tools you’re describing (wp_get_post_meta, wp_update_post_meta,
wp_delete_post_meta) have been in Royal MCP for a while. You should already see them in
your Claude connector’s tool list — they expose every custom field on any post.

That said, I’d strongly recommend NOT using them on _elementor_data directly. Elementor
stores pages as a deeply nested JSON tree where elements have random IDs, widget
settings are type-specific, and Elementor 4.0+ atomic widgets use an opaque schema
that’s unsafe to decode. Round-tripping that JSON through raw meta read/write will
break atomic widgets, duplicate element IDs (which breaks the editor), and mangle
escape sequences on save.

Royal MCP 1.4.19 added six dedicated Elementor tools that handle all of that safely:

elementor_clone_page — duplicate an existing page with fresh element IDs and draft
status
elementor_replace_text — bulk text substitution across heading, button, text-editor,
and other text-bearing widgets
elementor_replace_image — image URL swap across image, image-box, background, and
gallery widget settings
elementor_get_page_outline — compact section/container hierarchy for AI to reason over
without burning the JSON budget
elementor_list_local_templates — enumerate saved templates from the Elementor Library
elementor_import_template — wrap Elementor’s official import API for safe template
ingestion

They auto-register when Elementor is active and are hidden otherwise. Make sure you’re
on Royal MCP 1.4.19 or later (the latest is 1.4.22) and Claude should see all six in
the tool list.

The design intentionally avoids letting AI generate Elementor JSON from scratch —
clone-and-customize from a known-good source is far more reliable than trying to
construct widget JSON by hand. If you want to walk through a specific workflow, happy
to help.

Hi @michealdupont — thanks for the request, good thing to surface so we can
explain where we draw the line.

Short answer: PHP file editing isn’t on the roadmap and probably never will be,
and I want to give you the why so it doesn’t feel arbitrary.

The threat model. Every Royal MCP tool today operates on content that lives in
the database — posts, pages, products, taxonomy, comments, settings. All of
that is recoverable from a backup, and the worst-case scenario for a leaked API
key is “someone messes with your content.” Adding PHP file write turns that
into “someone plants a backdoor in functions.php and hides their tracks.” Same
credential, completely different blast radius. We’d need to assume every
install was one phished API key away from full code execution, and that’s not a
trade we want to make for a free WP.org plugin.

WP-side constraints. A meaningful percentage of production installs define
DISALLOW_FILE_EDIT or DISALLOW_FILE_MODS in wp-config.php specifically to
prevent any plugin (or admin user) from editing PHP files. Honoring those
constants means the tool silently no-ops on those sites. Not honoring them
breaks WordPress best practice. Either way the feature is unreliable by design.

Existing paths that already do this safely. WP-CLI over SSH (wp eval-file,
wp shell), an IDE with SFTP/SSH access, or a “Code Snippets”-style plugin
that stores PHP in a DB row with syntax validation and an instant kill switch.
Each of those has guardrails (atomic write, lint, rollback) that an MCP
file_put_contents tool would lack without a substantial engineering investment
that doesn’t fit our scope.

For your specific case — hiding sidebars and going full-width — the CSS via
Customizer route the AI suggested is actually the cleanest answer regardless
of capabilities. It’s theme-update-safe, doesn’t need a child theme, and
reverts with one click if it ever causes layout issues.

Hope that explains the stance, assuming since haven’t heard anything more on
this in over a week that the CSS approach worked, so marking as resolved for now.

Hi René,

Owe you an apology before anything else — I made a mistake in my very first reply that’s been quietly compounding through this entire thread. The SG Optimizer cache exclusion list I gave you was both wrong in one place and missing the most important endpoints. That alone could explain why nothing has stuck. Let me correct it and give you a definitive next step.

The exclusion list I gave you originally:
/wp-json/royal-mcp/*
/wp-json/royal-mcp/v1/oauth/* ← MISTAKE: this path has never existed in
Royal MCP
/.well-known/oauth-authorization-server
/.well-known/oauth-protected-resource

The /wp-json/royal-mcp/v1/oauth/* line does nothing. There’s no such REST namespace in the plugin — Royal MCP’s OAuth endpoints are root-level rewrite rules at /authorize, /token, and /register — and those three paths were never in your exclusion list. They’re the actual OAuth handshake endpoints, and they’re the ones SG’s edge cache is most likely poisoning. Anyone who got “Authorization with the MCP server failed” on SG without those exclusions was probably hitting a cached response from a stale GET
probe.

Step 1 — fix the SG Optimizer exclusion list

WP Admin → SG Optimizer → Caching → Dynamic Cache → Exclude URLs. Replace the list with:

/wp-json/royal-mcp/*
/.well-known/oauth-authorization-server
/.well-known/oauth-protected-resource
/authorize
/token
/register

Save, then click Purge SG Cache in the SG Optimizer toolbar. The purge is critical — without it any cached 4xx responses from your earlier test attempts (when GET /mcp was still returning 405 pre-1.4.14) will keep getting served regardless of the new exclusions.

Step 2 — two diagnostic curls (run AFTER the cache purge)

These will tell us if anything else is in the way:

(A) Content-Type on the metadata files — should be application/json
curl -sI https://terraexperty.com/.well-known/oauth-authorization-server | grep -i content-type
curl -sI https://terraexperty.com/.well-known/oauth-protected-resource | grep -i content-type

(B) Force a cache-busted POST to /register — should return 201 with a client_id
curl -v -X POST “https://terraexperty.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” ],”grant_types”:[“authorization_code”],”response_types”:[“code”],”token_endpoint_auth
method”:”none”}’

Send back the output of both. If (A) shows text/plain, that’s a separate Content-Type
blocker (covered in step 3). If (B) returns 201 Created with a client_id, the OAuth
registration plumbing is working and you can retry the Claude.ai connection right
then.

Step 3 — retract my “Path A” SiteGround support ticket recommendation

In my last reply I told you to open a SiteGround ticket asking for an nginx MIME-type override on the /.well-known/ paths. Don’t bother — that path is now closed. SiteGround confirmed to another Royal MCP customer yesterday that they no longer make per-customer nginx changes since their migration to Google Cloud infrastructure. The escalation route I pointed you at has been removed.

If diagnostic (A) above shows text/plain, the working alternative is a free Cloudflare Transform Rule that overrides the response Content-Type at the edge — works around SG entirely:
https://royalplugins.com/support/royal-mcp/siteground-cloudflare-content-type-fix.html

Two-minute setup on Cloudflare’s free plan, no SG involvement needed. Walkthrough on
that page.

The .htaccess ForceType application/json advice I gave you earlier in the thread also doesn’t work on these paths — nginx serves /.well-known/ files directly without falling through to Apache, so .htaccess is silently ignored. Apologies for sending you down that road.

Step 4 — fallback if you just need it working today

If the goal is simply “get Royal MCP usable with Claude” and Claude Desktop is acceptable, you can sidestep OAuth entirely with the API-key bypass — works in two minutes, no /.well-known/, no consent screen, no Cloudflare:
https://royalplugins.com/support/royal-mcp/connect-claude-desktop-api-key.html

Quick version: paste this into your Claude Desktop config, 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. Connected.

Send back the curl output from step 2 once you’ve done step 1 and we’ll either be done or know exactly which layer to tackle next. Sorry again for the runaround on the wrong cache list — that should have been right from the start.

Best,
Jameson

-Royal Plugins

V.1.4.14 is live, test it and let me know

Hi René,

That diagnostic is gold — those green checkmarks prove the static-file workaround unblocked the host-level OAuth handshake. The “Unknown client_id” is the next layer down, and it points at Claude.ai’s
connector configuration on your side, not a Royal MCP bug.

What’s happening:

Claude.ai’s MCP connector supports two modes:

1. Automatic OAuth (the standard flow Royal MCP expects) — you give Claude only your MCP URL. Claude auto-discovers your OAuth metadata at /.well-known/oauth-authorization-server, calls /register to
   dynamically register itself per RFC 7591, receives a fresh client_id, then sends the user to /authorize. Royal MCP recognizes the freshly-registered client_id and the handshake completes.
2. Custom OAuth credentials / Bearer Token — you pre-register a client and paste a client_id (or token) into Claude’s connector form manually. Claude skips /register entirely and sends whatever client_id you
   entered straight to /authorize. If that ID doesn’t exist in Royal MCP’s clients table, you get exactly the error you’re seeing. Your first message mentioned “creating a custom connector with a Bearer Token” — that’s mode 2, and Claude.ai may still be using that cached configuration even if you’ve since pasted the URL alone. That
   perfectly matches your observation that /register is never called and /authorize arrives with an unknown ID. The fix:
3. In Claude.ai → Settings → Connectors, fully remove the existing Royal MCP / Terra Experty connector. Don’t just edit it — remove it completely so Claude purges its cached config.
4. Wait ~10 seconds.
5. Click Add connector and select the standard “Add MCP server by URL” option (not the “Custom OAuth” / “Bearer Token” option).
6. Paste only the MCP URL: https://terraexperty.com/wp-json/royal-mcp/v1/mcp — no client_id, no secret, nothing else.
7. Click through the OAuth flow. Verify it’s now using DCR: While you click “Add connector”, tail your access log: tail -f /var/log/nginx/access.log | grep -E ‘(register|authorize|token)’ You should see POST /register HTTP/2 201, then GET /authorize …, then POST /token …. If /register does not appear, Claude is still running in the custom-credentials mode — back to step 1. About the empty Activity Log: Royal MCP’s Activity Log records MCP tool calls (post-auth), not the OAuth handshake itself. So an empty log during the connection attempt is expected behavior, not a separate signal of trouble — once you’re
   connected and Claude makes its first tool call, you’ll see it land in the log. Try the remove-and-re-add and send back the access-log lines. We’re one click away from a working connector.

Best
Jameson