Here is a failure that looks exactly like a broken plugin and is not one.
You add your site as a connector in ChatGPT or Claude. The browser opens, you approve the connection, and it completes. The client says it is connected. Then you ask the agent to do something on your site and nothing happens: no tools, no error you can act on, just an agent behaving as though your site is not there.
The instinct is to go looking at the plugin, because the plugin is the thing you just installed. Almost always it is not the plugin. The request never got there.
What the signal looks like
As of version 1.7.2 the Activity Log records every tool call, every sign-in, and the requests that reach WordPress and fail, as (transport) rows, at most five of each kind per source address every ten minutes. A request that succeeds without calling a tool leaves no row. That still gives you a clean test, and it takes about ten seconds.
Open the Activity Log tab and look at the moment you tried to connect. You should see the sign-in. Then read what comes after it.
| What the log shows after the sign-in | What it means |
|---|---|
| Ability calls | The connection works. Whatever is wrong is somewhere else. |
| Ability calls that were denied | The request arrived and the plugin refused it. The row names what was denied, so this is a permission question. Start at safety controls. |
| Nothing at all | No tool call arrived. Most often something in front of WordPress stopped the request. The plugin cannot log a request it never received, and a completed sign-in with no tool calls after it is the shape that takes. A client that connected but never chose a tool looks the same, so ask the agent to make one small read and look again. |
Since 1.9.0 you can narrow the log with a date range around the moment you tried to connect, and with the Connection filter once an app has made a call. How to find what an AI agent did on your WordPress site covers the filters.
That last row is the one this post is about. The sign-in and the MCP request take different roads even though they end at the same site, and only the first one made it.
Why the sign-in gets through and the tool call does not
Because they come from different places and look like completely different traffic.
The sign-in happens in your browser. It is you, on your own machine, with your own browser’s user agent, clicking approve on a page. To anything sitting in front of your site, that is an ordinary human visit.
The MCP request that follows does not come from your browser. It comes from the AI client’s own servers, and it announces itself with an AI user agent. To a bot filter, that is precisely the traffic it exists to stop.
So a rule that blocks AI traffic will wave the sign-in through and block everything after it. The connection appears to succeed and then does nothing, which is the most confusing possible arrangement of those two outcomes.
The concrete culprit
The common one is Cloudflare’s AI bot blocking, along with Super Bot Fight Mode. That was the Block AI Bots setting, which Cloudflare’s Block AI Bots page marks as deprecated from 15 September 2026, and which Cloudflare now replaces with Configure AI bot policies under Security Settings. This is not hypothetical. It came out of a real user report where the connection kept failing, and the trace ended at the edge with the plugin never having seen the request.
Other CDNs and WordPress security plugins have the same kind of feature under different names. The pattern is what matters more than the vendor: anything that filters requests by user agent or by source before they reach PHP can do this.
On WP Engine, check the edge rules and the 429 limit
If your site uses WP Engine’s Global Edge Security, check it first. In the User Portal, open the environment’s Insights menu, go to Traffic and Security, then the Settings tab, and look at Edge traffic rules. WP Engine’s support page for Global Edge Security says an edge traffic rule for a bot category blocks traffic from bots in that category, at the Cloudflare level. Remove the rule that covers your AI client.
The plugin’s FAQ also notes that WP Engine rate-limits some AI bots across its platform, and that you cannot turn that off yourself. If the agent’s calls fail with HTTP 429 errors on WP Engine, contact WP Engine support and ask them to review the limit for your site.
Confirm it before you change anything
Do not skip this step. It takes a minute and it tells you whether you are about to fix the right thing.
Open your CDN’s firewall or security event log and look for a blocked request to your site’s MCP endpoint, whose path ends in /mcp, from the AI client’s IP range, around the time you tried to connect. The log entry will name the rule that blocked it. If you find that entry, you have your answer and you know which rule to change.
If you do not find it, stop and look elsewhere. Troubleshooting covers the other failure shapes, including a /.well-known/ path blocked at the web server, which produces its own distinct symptom.
The two fixes
Once you have confirmed it, you have a choice of two.
The blunt one is to turn the rule off. On Cloudflare, allow the AI traffic under Configure AI bot policies in Security Settings (the older Block AI Bots setting, deprecated from September 15, 2026, did the same job). It works, and it stops filtering AI traffic across your whole site, which is more than you asked for.
The narrower one is to exempt only the endpoint. Add a rule that skips bot protection for the /mcp path and leave everything else covered. Cloudflare’s pages do not say whether a Skip rule covers the AI bot policies, so add it, retry the connection and confirm it worked before you rely on it. The endpoint you deliberately opened stays reachable, and the rest of the site keeps the protection you turned on for a reason.
Exempting that path is not a hole in your governance, because the endpoint was never relying on the CDN for its safety. It is behind OAuth or an Application Password, it acts as one scoped WordPress user, every ability is off until you enable it, every call is re-checked against that user’s capabilities, and every call is logged. The bot rule was never the thing keeping an unauthorized agent out. It was keeping an authorized one out.
Why the log is the part that matters here
This is not a plugin bug, and 1.7.2 did not fix it, because there is nothing here for the plugin to fix. What 1.7.2 changed is that you can now tell. Before transport rows landed in the Activity Log, “the agent arrived and did nothing” and “the agent never arrived” looked identical from inside WordPress, and telling those two apart is the whole diagnosis.
That is the same reason the log records denied attempts alongside allowed ones. A log that only writes down what succeeded tells you that something is broken. A log that writes down what arrived tells you whose problem it is, which is usually the question you actually needed answered.