Playground has added support for WebMCP, a draft browser API that exposes actions on a page as tools an AI agent can call. There is a proxy advertising an embedded site's tools on the outer page, so an agent working in the browser can act on a WordPress install running inside it.
This is early and it is a draft specification. It is still worth understanding now, because the design decisions it forces are the interesting part.
The detail everyone will skim past
Registering an ability does not expose it. You have to wrap it in a WebMCP tool, and that wrapping is a separate deliberate act.
That separation is the right design and you should copy it in anything you build here. An agent that can call every function a plugin registers has the run of the site. An agent that can call the three things you explicitly chose to expose is a feature. The distance between those two is the whole security story.
Treat it as an API surface
The mental shift that helps: stop thinking of an agent as a clever user, start thinking of it as an unauthenticated client that happens to write fluent prose. Every question you would ask of a public REST endpoint applies. What is the worst outcome if this is called with hostile input? What capability check runs first? Is the action reversible, and is there a record of who asked?
WordPress instincts map onto this well. Drafting rather than publishing, trashing rather than deleting. An agent that can create a draft is useful and recoverable. An agent that can publish is a different risk category, and one a person should have to opt into.
Where the value actually is
Set aside the demos of an agent writing a blog post. That is the least interesting application and the one most likely to produce something nobody wanted to read.
The useful cases are tedious and well-specified: auditing a site's configuration, finding every post still referencing a shortcode you deprecated, checking pending updates across a portfolio of forty sites, summarising what changed in staging since Friday. Tasks with clear success criteria, where a wrong answer is obvious immediately. That is the shape of work worth handing over.
Nothing here needs action this week; it is a draft API in a development tool. But if your plugin exposes capabilities an agent would find useful, spending an hour writing down which three you would expose and which you would refuse is time well spent. You will be asked that question eventually, and it is better answered deliberately than in response to a feature request.
