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
The Activity Log records every MCP request that reaches WordPress, as of version 1.7.2. That 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 | The request never arrived. The plugin cannot log a request it never received, and a completed sign-in with zero calls after it is the shape that absence takes. |
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 Block AI Bots setting, under Security and then Bots, along with Super Bot Fight Mode. 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.
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, switch off Block AI Bots under Security and then Bots. It works, and it stops filtering AI traffic across your whole site, which is more than you asked for.
The better one for most sites is to exempt only the endpoint. Add a rule that skips bot protection for the /mcp path and leave everything else covered. 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.