Tell a blocked connection apart from a plugin problem

An agent reports that it cannot do something on your site, and now you are guessing. Is the ability switched off? Is the bound user missing a capability? Or did the request never arrive in the first place, because something sitting in front of WordPress quietly dropped it? Those three failures look identical from the agent’s side, and they have completely different fixes.

The Activity Log settles it. Since version 1.7.2 it records every MCP request that reaches WordPress, not just the ability calls that succeed, so what the log contains (and what it does not) tells you which of the three you are dealing with. This prompt reads that log and reports the verdict. It changes nothing.

Something is failing on this site and I want to know where. Read only, change
nothing.

First confirm which site this connection is bound to, so I know we are looking
at the right install. Then read the Activity Log for [the last two hours],
newest first.

Walk me through what you find. Show me any sign-in, and tell me whether any
calls follow it or whether the log goes quiet straight after. Then split the
rows by status so I can see denied calls, errored calls, and successful ones
separately, with the ability name and timestamp on each.

Finish with a plain verdict on which of these it looks like: the agent was
stopped before it reached WordPress, it arrived and was denied on a
capability, or it arrived and hit a real error. Say which evidence in the log
you based that on.

Why this is safe to run

Both abilities here are reads. Reading the Activity Log reports history that already happened and cannot rewrite a row of it, and the site-info read returns the site name, tagline, URL, and language. Neither can touch a setting, a post, or a connection, so the worst case is a quiet window and no verdict.

One honest note on the method, because the most useful signal in this recipe is an absence rather than a reading. When the log shows an agent signing in and then nothing at all, the plugin is not telling you a request failed. It is telling you no request arrived, and you are inferring the rest. That inference is a good one now that every arriving request gets recorded, but it points at a layer the plugin cannot see into. The log stores no network addresses on purpose, so it can never name the CDN or firewall responsible; that trail is in your host’s logs, and this prompt’s job is to send you there instead of into the plugin’s settings.

The other thing to plan for is who runs it. The Activity Log read is gated behind the manage-options capability, which a properly scoped agent user should not hold, and a connection that cannot reach WordPress cannot run anything anyway. So this is an administrator’s read: you run it from a connection that works, and it tells you about the one that is failing.

Already connected? Skip the paste. From an admin connection, ask your agent for the “tell a blocked connection apart from a plugin problem” recipe, or just ask why the other agent’s calls are not showing up, and it runs the same reads against your own log.