frustratednow
Forum Replies Created
-
Activity Log confirms it — the POST never arrived.
Nine entries, and not one is oauth:token. The last is my authorise from last night:
August 24, 2026 8:16 PM — OAuth Server — oauth:authorize — SUCCESS
Request: POST /authorize, client_id wp_rQlaudyF6QRf5MvCqqk8OKzv
Response: 302, code_issued, "Authorization code issued; redirecting to client
callback."
Nothing after it. No token_issued, no invalid_client, no invalid_grant, no
invalid_request. claude.ai took the redirect and never came back to /token. Your
read was right.
For anyone finding this thread later: the cause is upstream at claude.ai — not the
plugin, not your host. Search "mcp_token_exchange_failed" and you'll find the same
failure across many self-hosted MCP servers: anthropics/claude-ai-mcp issues 215,
271, 313, 315, 360 and 690. #215 matches this symptom exactly and is closed as not
planned. Don't spend four days on your .well-known folder like I did.
Thanks for going back through the whole ticket rather than sending me at the root
.htaccess. I'd have lost an evening on option A for nothing.
I'm going the Claude Desktop route with the API key header instead.
One for your docs: the static Client ID and Secret in Settings > Advanced get you
all the way to a successful /authorize and code issuance with no .well-known file
present at all. That's a useful diagnostic state and it isn't documented anywhere
— it's what proved the failure was downstream of the plugin.Here we go again ….
Update — I’ve got past DCR entirely, and the failure has moved. Details below, because I think this is a state nobody in this thread has seen yet.
Your reply mentioned Claude can be given a pre-registered client. Following that, I found the plugin’s own Royal MCP > Settings > Advanced (Legacy REST API base URL, manual OAuth credentials) section and used its Generate buttons to create a static OAuth Client ID and Secret. I put both into the OAuth Client ID and Client Secret fields on Claude.ai’s custom connector.
Three of the four steps now work:
- WORKS. Dynamic Client Registration — skipped entirely. Never called.
- WORKS. GET /authorize served the real Royal MCP consent screen — “Costa & Mason (static) wants to connect to your WordPress site”, signed in as me, four scopes listed, Powered by Royal MCP.
- WORKS. I clicked Authorize. WordPress issued the code and redirected to https://claude.ai/api/mcp/auth_callback
- FAILS. The token exchange. Claude landed back on /settings/connectors?error_code=mcp_token_exchange_failed with “Authorization with costa & mason website failed.” Reference ofid_1d57ea224b045cb9
So the failure is now isolated to the POST to /token.
Important context on the site’s state while this ran: everything from my last post is still reverted. There are no files in .well-known/ at all — /.well-known/oauth-authorization-server does not resolve. Discovery is completely absent, and step 2 still worked.
Which is what I can’t reason about from here:
Claude reached /authorize with no metadata document available, so something is constructing that URL from the server URL rather than reading .well-known. If /token is resolved the same way, then discovery isn’t the blocker and the failure is inside the exchange itself.
Two questions that would let me narrow it:
- When a static Client ID and Secret are set, does the /token step still depend on the .well-known metadata document, or is it constructed like /authorize appears to be?
- Does the plugin’s /token endpoint expect the client secret as an Authorization: Basic header, or in the POST body? If Claude sends one and the plugin reads the other, that would produce exactly this result with a perfectly valid secret.
Also — is a failed token exchange recorded anywhere in the plugin? I went looking for the Activity Log and couldn’t reach it.
One correction for the thread, on your option C. API-key auth cannot be used with the Claude.ai web connector. Its “Add custom connector” dialog has exactly four fields: Name, Remote MCP server URL, OAuth Client ID, OAuth Client Secret. There is no header field and no API-key field, and an existing connector has no edit screen at all — only Remove. That matches your own help text on the API key, which says “Claude Desktop config, raw REST calls”. So it’s a working fallback for Claude Desktop, but not an escape hatch for Claude.ai. Might be worth saying so in the docs.
I haven’t tried your option A (the root .htaccess rewrite) yet. Given that /authorize now works without any .well-known file present, I’d rather know whether /token needs one before I start editing the site root.
Follow-up to rpteam’s reply — I ran the tests. Results below.
POST /register → 201 with a valid client_id JSON body. So per your
Scenario A, the rewrites are working and registration itself is fine.GET /authorize with a bogus client_id → 400 (not 404), which confirms
the OAuth rewrite rules are registered.POST /wp-json/royal-mcp/v1/mcp → 401, Content-Type application/json.
Endpoint alive.The failure is in discovery. Both metadata files return 200 with the
correct JSON body, but with:Content-Type: application/octet-streamClaude.ai fails at “Couldn’t register”, which I believe is it refusing
to parse the metadata because of that content type.What I tried, all in public_html//.well-known/.htaccess:
- ForceType application/json inside blocks — this was already
there. No effect. - Added Header always set Content-Type “application/json” alongside
it. No effect. - Made .json copies of both files. Those DO serve as application/json.
Added mod_rewrite rules in the same .htaccess to map the
extensionless URLs to the .json copies. The rewrite never fired.
Since mod_rewrite, mod_headers and ForceType all fail there, my
conclusion is that the .htaccess inside .well-known is ignored
entirely on this host — Webempresa serve that directory through their
own handler because it is their ACME/SSL path.All of the above has been reverted; the site is back to its original
state.Also worth noting: the RFC 9728 path-suffixed variants return 404, e.g.
/.well-known/oauth-protected-resource/wp-json/royal-mcp/v1/mcpQuestion: is there a supported way for the plugin to serve the
discovery metadata from WordPress itself rather than from static files
in .well-known? If WordPress handled those two addresses, the host’s
handling of that directory would stop mattering.Host: Webempresa (WePanel, LiteSpeed/CloudLinux). Royal MCP 1.4.42.