sreepadmaflora

Thank you so much for digging into this and confirming a fix path — really appreciate the clear explanation. I’ll wait for your follow-up once the update is available, then update the plugin and test the connection again. Let me know if you need anything else from me in the meantime.

Hi,

Thanks for the detailed breakdown — we’ve worked through all of this, and we now have a clear, fully isolated finding. Here’s where things stand on each item:

1. /.well-known/oauth-authorization-server — Confirmed working. Returns valid JSON with the correct authorization_endpoint:

"authorization_endpoint":"https://sreepadma.com/?easy_mcp_ai_oauth=authorize"

2. /.well-known/oauth-protected-resource — Also confirmed working. Valid JSON, correctly points to:

"resource":"https://sreepadma.com/wp-json/easy-mcp-ai/v1/mcp"
"authorization_servers":["https://sreepadma.com"]

3. The root authorize URL opened directly — https://sreepadma.com/?easy_mcp_ai_oauth=authorize is now fully working. Visiting it without OAuth parameters correctly returns:

Authorization Error
invalid_request: Missing required parameter: client_id

That’s the expected, correct behavior for hitting the endpoint without a client_id — it confirms your plugin’s OAuth handler is live and responding properly at this URL. (Earlier in our troubleshooting this URL was returning a cached homepage instead of reaching the plugin at all — that’s now resolved, likely from the Cloudflare/cache changes we made propagating fully.)

4. Claude Desktop’s exact error — This is the one remaining issue, and it’s now clearly isolated to Claude Desktop itself. When Claude Desktop attempts the connection, it does not use the authorization_endpoint from your discovery document. Instead, it builds and requests this URL, which returns a rest_no_route 404 since that path was never meant to exist:

https://sreepadma.com/wp-json/easy-mcp-ai/v1/oauth/authorize?response_type=code&client_id=dbebe560312195c689176233ac4e53c3&redirect_uri=http%3A%2F%2Flocalhost%3A9192%2Foauth%2Fcallback&scope=...&state=...&code_challenge=...&code_challenge_method=S256&resource=https%3A%2F%2Fsreepadma.com%2Fwp-json%2Feasy-mcp-ai%2Fv1%2Fmcp

We confirmed this isn’t a stale/cached request — multiple fresh attempts each generated a new state and code_challenge, but Claude Desktop kept constructing the same wrong path every time, ignoring the authorization_endpoint value your discovery document actually provides.

Summary: Every part of the server-side OAuth chain is now confirmed correct and fully functional — discovery documents, protected resource metadata, HTTPS, Cloudflare, and the real authorize endpoint itself (which now correctly enforces required parameters rather than serving a cached page). The only remaining gap is that Claude Desktop is not reading authorization_endpoint from the discovery document it successfully fetches, and instead assumes a wp-json/{namespace}/oauth/authorize path pattern that doesn’t apply to this plugin.

Two questions for you:

1. Have other users with the root-level authorize URL pattern reported this same Claude Desktop mismatch?
2. Would it be feasible to add a compatibility route at /wp-json/easy-mcp-ai/v1/oauth/authorize that redirects to the real root-level authorize URL, as a workaround for clients that assume that path?

Happy to test anything further on our end — this connection is now failing at exactly one well-defined point, so any workaround should be straightforward to verify.