easymcpaisupport1

Hi,

Good news first: the 404 on /wp-json/easy-mcp-ai/v1/oauth/authorize is expected. That route does not exist, and it is not the cause of your problem. In this plugin the authorize endpoint is intentionally served at the site root, not under /wp-json. The real URL is:

https://YOURSITE.com/?easy_mcp_ai_oauth=authorize

Claude Desktop never builds the /wp-json/…/oauth/authorize URL itself. It discovers the correct one from the plugin’s discovery documents. So the place to look is whether those discovery docs (and the root authorize URL) are reachable through Cloudflare, LiteSpeed, and Wordfence. Could you grab these for me, ideally in an incognito or logged-out window, and paste the raw output plus the HTTP status of each?

1. The discovery document Claude Desktop actually reads (root level, NOT under /wp-json): https://YOURSITE.com/.well-known/oauth-authorization-server This should return JSON. If it returns a 404, or HTML, or a cache page, that is the real problem.
2. The protected-resource document: https://YOURSITE.com/.well-known/oauth-protected-resource
3. The real authorize URL opened directly in a browser: https://YOURSITE.com/?easy_mcp_ai_oauth=authorize You should get a login or consent screen, not a 404. If you instead get a 404 or a cached or blank page, a caching or security rule is interfering.
4. The exact error message Claude Desktop shows when the connection fails, and at which step, rather than the manual browser 404.

A few things specific to your setup are worth checking in parallel, since this stack is the usual suspect for this kind of issue:

Cloudflare: make sure requests to /.well-known/ paths and URLs containing the ?easy_mcp_ai_oauth= query string are not being cached or challenged. A “Cache Everything” page rule or Bot Fight Mode can break the flow. Try temporarily switching Cloudflare to Development Mode and retest.

LiteSpeed Cache: exclude /.well-known/ and the easy_mcp_ai_oauth query argument from caching (Cache, then Excludes), and confirm query strings are not being dropped.

Wordfence: allowlisting your own IP does not help here. Check the Wordfence live traffic and blocked-requests log for hits on .well-known or the authorize URL while you attempt the connection.

WordPress address: confirm your Site Address (URL) under Settings, then General is the exact https:// domain you expect. The authorize and
discovery URLs are built from that value, so a mismatch (wps) will break discovery.

Once I see the outputs of items 1 through 4, I can tell you exactly which layer is dropping the request.

Hi,

The issue might be caused by a well-known file on some servers with error warnings enabled, which leads to the format error. The fix is available in version 1.7.7 (https://downloads.wordpress.org/plugin/easy-mcp-ai.1.7.7.zip). It will be available for update from the WordPress dashboard within 24 hours. Please let me know if this resolves the issue. If not, could you please provide more details about the environment where the issue occurs, such as whether any security, caching plugins, firewalls, etc., are in use?

Thank you.

Can u please share the response of this CURL so i can investigae the tools/list response format? (Copy response only here, do not include curl request/token/domain)

curl -s -X POST https://example.com/wp-json/easy-mcp-ai/v1/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_TOKEN_HERE" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}' | jq .

Let me know if the new version solved these issues. We will mark this as resolved.

Hello,

Sorry for the late response. Based on the information provided, the possible issues are related to LiteSpeed Cache or Cloudflare.

For LiteSpeed Cache: A cached MCP/OAuth response can be served stale, breaking the handshake. To check this, add /wp-json/easy-mcp-ai/* and /.well-known/* to the cache plugin’s “do not cache” list, purge the cache, then retry in a private window. If it connects, caching was the cause.

For Cloudflare: Ensure that the firewall blocking AI bots or AI user agents does not prevent Claude from accessing your site.

You can also try checking your site at https://easymcpai.com/diagnose, where we have improved diagnostic tools.

Please let me know if you have more detailed information about your WordPress or server settings so we can investigate further.

Hi,

The new version is already available on wp.org. If you don’t see the update in the admin dashboard, WordPress might delay it by up to 24 hours. Otherwise, you can download it from this link: https://downloads.wordpress.org/plugin/easy-mcp-ai.1.7.6.zip

Let me know whether this fixes the issue.

Thank you!

Version 1.7.4 has already been uploaded to wp.org and will be available to users within the next 24 hours, according to the new WP rule.

Hi @kishie ,

Thanks for the detailed report — you diagnosed this correctly.

Root cause: The 5 CPT tools (wp_list_cpt_items, wp_get_cpt_item, wp_create_cpt_item, wp_update_cpt_item, wp_delete_cpt_item) were never added
to the OAuth scope map when they were introduced. Every other tool category has a corresponding OAuth scope (e.g. mcp:posts:read,
mcp:media:write), but mcp:cpt:read and mcp:cpt:write were missing entirely. Because Claude.ai uses OAuth, the token issued at authorization
time never included CPT tools — regardless of the admin whitelist setting, which operates on top of the token scope, not instead of it.

Fix: We will add mcp:cpt:read and mcp:cpt:write scopes to the scope map. After updating, you’ll need to re-authorize your Claude.ai connector so a new token is issued that includes the CPT scopes.

This will be released in version 1.7.4 within 1–2 days.

Thanks for the patience