Version 1.7.2 adds two things, and they land at opposite ends of the same connection. The consent screen an agent shows you at sign-in was rebuilt so it says who is actually asking. The Activity Log now records every MCP request that reaches WordPress, so afterwards you can check what actually arrived. Both are about being able to see the governance work rather than take our word for it. The catalog itself did not move: still 153 governed abilities, 83 core plus 70 across the integrations, and no ability was added, removed, renamed, or repermissioned.
The consent screen was showing you very little
The consent screen is the one moment where a person, not a policy, decides whether an agent gets in. Until 1.7.2 it was a plain WordPress form. It asked you to approve a connection without giving you much to approve it on.
Now it carries three things. A brand mark for the plugin, so you can tell at a glance which plugin is asking. Your site’s own Site Icon, with an initials fallback if you have not set one, so you can tell which site you are about to hand access to. And, when the plugin recognizes the connector, that connector’s own icon.
Why the icon is keyed to the redirect host
The third one took an actual decision, because an OAuth client sends a display name along with its request and that name is self-declared. Nothing stops a client from calling itself anything it likes. A screen that renders an icon based on the name it was told will happily show a familiar logo to something that is not that product at all, and then the icon is worse than decoration, because it vouches for the claim.
So the plugin does not use the name. It matches the connector’s verified redirect host, the address the token actually gets sent back to, against the connectors it knows. If the host matches, you get that connector’s icon. If it does not, you get no icon rather than a wrong one. The name still appears as a label, because it is useful information, but it never decides identity.
A logo rendered from a name a client made up is worse than no logo, because it turns a guess into a reassurance. The consent screen recognizes a connector by where its token goes, which is the one thing about it that cannot be renamed at will.
If you are setting up a connection for the first time, connecting a client walks the flow end to end, and OAuth or an Application Password covers why the browser approval path exists at all.
The Activity Log now records what arrived
The second addition is on the other side of the connection. The Activity Log has always recorded ability calls, denials included. What it did not record was the transport layer underneath: the MCP requests themselves, arriving at WordPress before any ability is chosen. 1.7.2 writes a row for every MCP request that reaches WordPress.
That sounds like plumbing detail, and it makes exactly one thing readable that was not readable before. A completed sign-in with no ability calls after it now means something specific: the request never arrived. Not that the plugin refused it, not that a capability check failed, but that it never got to WordPress at all, which points at a CDN or a firewall in front of the site rather than at the plugin.
Before 1.7.2, that state and “the agent connected and then did nothing” looked identical in the log. Now they do not. We wrote that pattern up separately in your agent signs in, then nothing happens, because it is a diagnosis worth knowing whether or not you ever hit it.
What did not change
No ability was added, removed, renamed, or moved to a different permission. The count is still 153. Nothing about who can call what is different, and nothing was switched on for you in the catalog. The one setting 1.7.2 does change on your behalf is dynamic client registration, which is covered in what we fixed in the 1.7.2 connection release along with the rest of that release’s fixes.
The full history is on the changelog, the current safety controls are on security, and what the audit log actually stores covers what does and does not end up in a row.