156. WebMCP in Playground

While WebMCP is still a proposed Internet standard, it’s already been integrated into WordPress Playground for use with the ChatGPT desktop app, which supports it.

Program transcript

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from September 7 to 13, 2026.

The WordPress 7.2 Release Squad has now been formed, with Matt Mullenweg back as Release Lead following the call for volunteers. David Baumwald is coordinating the release, George Mamadashvili and Peter Wilson are the Tech Leads, and the team is rounded out by the triage and testing leads, plus the design and development leads for the new default theme, Twenty Twenty-Seven, headed by Henrique Iamarino on design and Maggie Cabrera and Carolina Nymark on development.

As has been the norm since 6.7, 7.2 keeps the small-squad model, relying heavily on each Make team’s representatives to coordinate work from within their own teams rather than centralizing everything in the release squad. Volunteer interest far exceeded the available slots, so anyone not selected this time can still contribute through testing, bug scrubs, triage, or documentation throughout the cycle — which is really where the bulk of each release’s workload shows up.

WordPress Playground now supports WebMCP, a standard still in draft stage that lets a web page expose actions directly as tools an AI agent can discover and use without leaving the browser. It’s a different approach from MCP, which connects to a local or remote server: WebMCP works inside the web page itself, with no intermediary. OpenAI has already added support for this in the built-in browser of the ChatGPT desktop app, under the name “Site tools,” so you can now also work with Playground by asking it in natural language to build a landing page or spin up a reproducible plugin demo.

The interesting technical challenge is that WordPress runs inside a nested iframe within the Playground page, and an agent that only looks at the top-level page can’t see the tools a plugin registers inside that WordPress instance. The solution is a WebMCP proxy that exposes tools registered inside the site to the outside and forwards calls back in, so that a plugin offering, say, an action to create an event draft becomes discoverable and usable by the agent without standing up a separate server.

The team has already tested several real-world workflows: building a complete tourism landing page from a single prompt, putting together a WordPress version-compatibility tracking dashboard with editable cards, and turning a plugin’s features into interactive demos that any visitor can try without installing anything.

The Plugins team has turned on an automated security review for every new release of any plugin in the directory, before it goes out through the update API. Until now, new plugins were reviewed before entering the directory, but subsequent updates went through no systematic check, so a plugin that was safe today could introduce a vulnerability or malicious code in any future version without anyone catching it in time. The specific trigger was a real incident: on July 28, a backdoor made it into an update for a plugin with roughly 20,000 active installs, which the automated review flagged and scored as high-risk, blocking its distribution before it reached any site — with the plugin fully closed 26 minutes later.

The mechanism builds on the six-hour quarantine period that’s existed since June for every plugin and theme update: during that window, several AI models analyze each release’s changes, cross-check results against one another to cut down on false positives, and assign a risk score. If it crosses the high-risk threshold, distribution is blocked automatically without depending on a team member being available at that moment, and all plugin authors are notified by email with the specific findings; a high score doesn’t imply malicious intent, since an unintentionally introduced vulnerability can score just as high as a deliberate attack.

The Community team has proposed setting up a joint educational sponsorship fund for WPCredits and WordPress Campus Connect students, intended as a standard package in the sponsor prospectus for the three flagship WordCamps: Asia, Europe, and US. Until now this has been handled case by case: WordCamp US 2025 hosted two Campus Connect students, and WordCamp Europe 2026 hosted five WPCredits students, with ratings of 8 to 10 out of 10 in the post-event impact report. The proposal aims to turn that ad hoc effort into a repeatable process, with a recommendation form filled out by organizers or mentors, and selection criteria focused on a track record of sustained contribution and the quality of the student’s WordPress profile.

The plan is to launch it first as a pilot at WordCamp Asia 2027, with a cohort of eight students, a funding goal of $30,000, and a minimum sponsor contribution of $3,000, before expanding it to Europe and the US if it goes well. Plenty of open questions remain: how to structure sponsorship into price tiers per slot, where to host a centralized, year-round interest link for sponsors instead of repeating the process for every event, what happens if only half the planned slots get funded, and the logistics of confirming funds with enough lead time for students to arrange flights and visas.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!