Introduction: the quietest big WordPress decision of the year
I have spent years telling clients the same thing: WordPress is not just where content lives, it is the system their whole business runs on. Posts, products, menus, users, settings — all behind one powerful login.
Last week that system took a step I think we will look back on as a turning point. At the WordPress AI Team meeting on October 21, 2026, team representative Jason Adams said co-founder Matt Mullenweg had approved making MCP a de facto part of the WordPress experience, with 7.3 floated as the target. How it gets there is still open, but the direction is no longer a debate. WordPress is opening its door to AI agents, officially. I am excited and nervous in roughly equal measure, and if you build WordPress sites the way I do, you should hold both feelings at once.
What actually happened on October 21
Be precise, because headlines are running ahead of the facts. Nobody announced that 7.3 will ship MCP. On October 7, 2026, the Core AI team published the MCP Adapter v0.7.0 in the official WordPress.org plugin directory, where it had already passed 40,000 installs from its GitHub days. Two weeks later, Adams reported Mullenweg's approval, with one condition: throw everything at avoiding new vulnerabilities. By that meeting the adapter had passed 50,000 installs. An exception pulling MCP into 7.2 was briefly considered and set aside — 7.2, due December 8, is already in beta. So 7.3 is a floated target, not a promise, and authentication is still unresolved.
MCP in plain English
MCP stands for Model Context Protocol, an open standard Anthropic introduced in November 2024, now with the Agentic AI Foundation under the Linux Foundation. Without a standard, every AI app needs its own WordPress integration. With MCP, WordPress lists what it can do, and any MCP client — Claude, ChatGPT, Gemini, Copilot — can use the same list. One plug socket, many appliances.
WordPress's version has two pieces. The Abilities API, shipped in WordPress 6.9 in December 2025, is a registry where WordPress and plugins describe what they can do and what permission each action needs — "get a post," "create a draft," "update a setting." The MCP Adapter then offers those abilities to AI apps. It invents no powers; it exposes only abilities someone chose to make public.
Here is the detail that surprises everyone: core registers only three abilities, all read-only, covering basic site, user and environment info. Everything useful comes from plugins. Install the adapter on a bare site and an agent can do almost nothing — exactly the right starting point. That is also why Bricks and WooCommerce built their agent features on the Abilities API and adapter rather than their own servers, though both are still experimental or developer preview.
WordPress.com got there first
Want to see the self-hosted future? Look at WordPress.com, which launched its MCP server read-only in October 2025 and added write access in March 2026. Its docs describe OAuth 2.1 authentication, per-connection full or read-only access, on all paid plans, a free site's first 30 days, and Jetpack-connected self-hosted sites with Jetpack AI or Complete.
There is nothing to install: switch on the tools you want per site — content, media, settings, plugins, themes, users, domains — connect your AI app, and sign in with a WordPress.com login you can revoke. WordPress.com users can already talk to their AI to create and update websites. Five years ago that sounded like science fiction. Today it is a documented paid-plan feature, and a much better shape than the self-hosted route, which leans on Application Passwords. More on that below.
What this means if you build with Elementor
Elementor's MCP opened as a beta in September 2026. I have not seen a feature list I would bet a client site on yet, and you should treat any beta that way — but the strategic point is clear: the builder powering a huge share of WordPress sites is building its own agent surface on the same standard.
Once it matures, an agent that sees an Elementor page as abilities rather than a blob of HTML could draft a landing page, swap a hero section, or update one call-to-action across dozens of pages through the builder's own structures. But an agent editing a page builder is also the highest-stakes version of this idea: a wrong draft is embarrassing, a wrong global template change is visible on every page, and a wrong settings change has no revision to roll back to. My rule for now: staging first, drafts only, I publish. The agent proposes; I dispose.
The awkward benchmark nobody quotes
Now the part that should slow everyone down. In a recent independent benchmark, shared by contributor Andy Peatling and discussed at the October 21 meeting, agents were asked to build websites without WordPress being mentioned. Across nearly 300 runs with seven agents (Claude Code, Codex, Gemini and others) and 28 everyday prompts like "website for my bakery," agents chose WordPress 0% of the time for the 19 requests it would have suited. They built 193 sites, none on WordPress, though headless WordPress and WordPress.com would have counted. Two-thirds were plain HTML or React, and only 7% used a CMS with a place to edit content.
Yet afterwards, agents named WordPress as a good option 50 to 74% of the time. They know it; they just do not pick it. The meeting also cited 0% task completion through the MCP Adapter alone. Exposing an ability is not the same as an agent knowing how to finish a real job on a real site. The plumbing is arriving; the competence layer is not. Anyone selling "AI builds your WordPress site" today should show you a finished site, not a demo video.
Safety: the part Mullenweg got right
Mullenweg's condition — throw everything at avoiding new vulnerabilities — is the most important sentence in this story. An MCP server acts as a real WordPress user, and on self-hosted sites that usually means an Application Password. Those work only over HTTPS and can be revoked one at a time, which is good — but each carries the user's full permissions, never expires on its own, and WordPress has no built-in way to limit one to certain actions. Connect an agent as administrator and it has the keys to everything. That is how WordPress authentication works today, and it must be solved before MCP becomes a default.
Then there is prompt injection: an agent reads your content to work, and cannot reliably tell your instructions from instructions hidden in a comment, form entry or imported post. Researchers showed this in 2025 by steering a GitHub agent into copying private data somewhere public. No public case against a WordPress MCP server exists yet — which is not the same as impossible. The defence is limiting what a fooled agent could do.
Then the undo problem. WordPress keeps revisions for posts, pages, templates and menus, but none for settings, most plugin settings, widgets, media, categories, tags or users, and deleted media skips the Trash. A backup is the only undo for those. Finally, new code has holes: Patchstack counted 11,334 WordPress-ecosystem vulnerabilities in 2025, 91% in plugins, and recent MCP plugins have had permission bugs letting low-privilege accounts reach powerful tools. Prefer servers built on the Abilities API, and keep them updated.
My ladder: read and report on any site, once you choose what it can read. Write drafts anywhere, with you publishing. Publish live only with approval on every change. Change settings, menus, plugins or users on staging first, live only with a fresh backup. Run PHP code or database queries on staging only, always — one popular AI plugin left that power out entirely, calling it genuinely unsafe. Believe it.
What I would do this week
Do not install the adapter on a live site to "see what happens." Install it on staging with no abilities public, ask the agent what it can do, and read the answer — almost nothing, which is correct. Create a dedicated low-role user for the agent, never your administrator, with its own Application Password, and revoke it when testing ends. Test the boring job first — drafting posts, writing alt text — because if the agent cannot do that reliably, it cannot be trusted with the interesting job. Back up before it changes anything beyond a draft, and confirm you can restore that backup; a backup never restored is a hope, not a backup. On WordPress.com, start read-only and switch on one write tool at a time. With Elementor's beta, test on a staging clone with a change you can check in thirty seconds.
Conclusion: the door is opening slowly, and that is the right speed
WordPress letting agents in is not a gimmick. It is the platform behind a huge share of the web deciding the next interface to a website might be a conversation, not a dashboard. The Abilities API gives that conversation a vocabulary, the adapter gives it a standard plug, and Mullenweg's approval gives it a destination in core, with 7.3 floated as the target. But the benchmark warns us: agents know WordPress and still do not choose it, and the security model — permissions, authentication, revocation, undo — must be solved before this becomes a default.
My prediction: MCP in core will arrive later than optimists say and matter more than sceptics think. The sites that benefit first will not hand an agent the administrator password on day one. They will start with read-only reporting and drafts, check the agent's work, and expand its permissions one careful step at a time. I will be testing it on staging this week, starting with drafts and alt text. The agent can propose. I will still publish — because when something breaks at 2 a.m., it is still me who answers for it.
FAQ
Is MCP already part of WordPress core?
No. As of October 2026 it is available through the official MCP Adapter plugin (v0.7.0, in the WordPress.org directory since October 7, 2026). Building it into core is approved in principle, with 7.3 floated as a target, but implementation and authentication are unresolved.
What is the difference between the Abilities API and the MCP Adapter?
The Abilities API (WordPress 6.9) is the registry where WordPress and plugins describe what they can do and the permission each action needs. The adapter exposes those abilities to AI apps over MCP. It adds no powers of its own.
Does installing the MCP Adapter open my site?
No, not on its own. Its default server only offers an ability after someone marks it public, and core registers only three read-only abilities. The agent acts with the permissions of the user account you connect it with.
Can I use MCP with WordPress.com and Elementor today?
WordPress.com's built-in MCP is on paid plans (plus a free site's first 30 days), with per-tool switches and OAuth sign-in. Elementor's MCP is a September 2026 beta — test it on staging, not a live client site.
Is it safe to let an AI agent manage my site?
It can be, if you limit it: a dedicated low-privilege user, never administrator; read-only and drafts first; approval for every live change; a tested backup, since settings, media and users have no revision history; and never let an agent run PHP code on production.
