zealousagenda

Adding a second data point to this thread, because I have the same ofid_* failure and server-side logs that isolate where it stops. I can’t start a new topic (my account can’t create them right now), so I’m replying here rather than opening the separate thread the pinned triage post asks for.

Reporting in the format that post requests:

Hosting provider: SiteGround — no Cloudflare, no WAF or security plugin active Royal MCP version: 1.5.2 (Free) Stack: WordPress 7.1.1, PHP 8.2.33, permalinks /%postname%/ Client: claude.ai custom connector, added from Claude Cowork Exact error text:

Authorization with AutumnSpring WP Site failed. You can check your credentials and permissions. If this persists, share this reference with support: “ofid_0e5516bb59e34e50”

(earlier attempt: ofid_47849260bd262c53) This is neither Class A nor Class B

The pinned triage post defines Class A as the “Unknown client_id / application has not been registered” authorization error, and Class B as “can’t reach the connector” / reconnect prompts. Mine is neither. Registration succeeds, the consent screen appears and is approved, the code is issued — and then the client reports a generic authorization failure. It may be worth adding a third class for this. Activity Log — oauth:* rows

Three attempts. Timestamps appear to be UTC. Attempt Time Logged oauth:token 1 + 2 Sep 20, 01:55 4 × oauth:register SUCCESS, 2 × oauth:authorize SUCCESS none — Sep 20, 02:14 oauth:reset SUCCESS — deleted 9 clients, 0 tokens, 2 auth codes — 3 Sep 20, 02:21 2 × oauth:register SUCCESS, 1 × oauth:authorize SUCCESS none

Zero access tokens have ever been issued by this server. Authorization codes are issued and never redeemed. Reset OAuth State, then retried on a completely clean slate — identical result. So this is deterministic, not stale registration state.

Attempt 3 detail, clean state:

POST /register   ip 160.79.106.181   user_agent "python-httpx/0.28.1"
  → 201 client_registered — "Dynamic client registered."

POST /authorize  ip 174.178.141.207  user_agent "Mozilla/5.0 (Macintosh…) Chrome"
                 client_id "rmcp_82d3…4070"
  → 302 code_issued — "Authorization code issued; redirecting to client callback."

POST /token      → no log row at all

Royal MCP does its part correctly — registers the client, issues the code, redirects to the client callback. The token request is simply never made. The host-blocking diagnosis does not hold for this site

The conclusion recorded in this thread — and in the general troubleshooting guidance — is that a host security layer silently drops the server-to-server token request, because it comes from a datacenter IP with a python-httpx User-Agent and therefore leaves no trace. @videoanimate already showed that a python-httpx User-Agent reached their server fine. My Activity Log falsifies the host-blocking explanation outright for my install, from the server side rather than by curl simulation.

The POST /register above came from python-httpx/0.28.1 at an Anthropic backend IP and returned a clean 201, minutes before the token call was due. A separate GET /token from another Anthropic IP (34.162.191.81, UA Claude-User/1.0) was received and correctly answered 405 — "This endpoint only accepts POST requests."

So Anthropic’s infrastructure demonstrably reaches these endpoints, and the edge is not interfering. Anyone sent to their host on this basis may be chasing the wrong thing — I lost several hours to it. A useful triage step would be: check the Activity Log for a /register success from python-httpx first. If it’s there, the host is not blocking.

For completeness, I’ve filed this with Anthropic as well — it matches an open client-side bug report (anthropics/claude-ai-mcp #1028, “server-side OAuth flow completes successfully, but Claude never calls /token”), where another reporter showed the same server works with MCP Inspector as a reference client. One thing on Royal MCP’s side that may be worth fixing

While investigating I found an RFC 9728 gap. I’m not claiming it causes the above, but it is real:

/.well-known/oauth-authorization-server                 → 200 ✓
/.well-known/oauth-protected-resource                   → 200 ✓
/.well-known/oauth-protected-resource/<resource-path>   → 404 ✗

The path-suffixed protected-resource metadata URL — https://autumnspring.co/.well-known/oauth-protected-resource/wp-json/royal-mcp/v1/mcp — returns 404. Only the bare path is served, and it declares:

{
  "resource": "https://autumnspring.co/wp-json/royal-mcp/v1",
  "authorization_servers": ["https://autumnspring.co"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["mcp:full"]
}

The declared resource is …/royal-mcp/v1, but the MCP Server URL the settings page tells users to configure is …/royal-mcp/v1/**mcp**. Those are different URIs. Under RFC 8707 — which the MCP authorization spec requires — the client sends resource=<canonical endpoint URI> with the authorization and token requests, and a strict client can reject a mismatch. Anthropic’s own connector compliance checklist lists all three well-known endpoints above as needing to return 200.

Suggested fix: serve the PRM at the path-suffixed URL as well as the bare one, and have resource return the full configured endpoint including /mcp. Two smaller notes

1. wp_get_plugin_settings redaction is misleading. Called via MCP for slug royal-mcp, it returns:

"oauth_client_id": "[REDACTED]",
"oauth_client_secret": "[REDACTED]"

Both fields are actually empty — the admin UI shows the “Leave empty for Dynamic Client Registration” placeholder. The redaction masks by key name regardless of whether a value exists, so the tool can’t distinguish “set” from “empty.” That sent me down a wrong diagnostic path for a while. Returning "" or null when empty would fix it.

2. WebMCP status badge. With “Enable browser agents (WebMCP)” ON, the settings page shows WebMCP bridge status: unknown — could not reach discovery path. Haven’t investigated; flagging in case it points at the same discovery routing as the PRM issue above.

Happy to run any diagnostic against this install and share the full Activity Log.