WordPress has moved a significant piece of its AI-agent infrastructure into the mainstream plugin ecosystem. MCP Adapter 0.7.0 is the first release of the official WordPress MCP integration published in the WordPress.org plugin directory, turning registered WordPress Abilities into Model Context Protocol primitives that compatible AI agents can discover and invoke.
For SEO teams, the important change is conceptual: a website can increasingly be designed not only to be crawled, indexed and cited, but also to expose controlled capabilities that an AI agent can actually use.
What WordPress MCP Adapter actually does
The adapter bridges the WordPress Abilities API and the Model Context Protocol. An Ability registered by WordPress core, a plugin or other site code can be represented to MCP clients as a tool, resource or prompt.
An agent could therefore discover a capability, inspect what it does and — when permissions allow — execute it programmatically.
The adapter itself does not magically add AI functionality to a WordPress site. It is the server and protocol layer. Useful functionality still depends on Abilities being registered by WordPress or plugins.
Version 0.7.0 is the WordPress.org milestone
The official GitHub release notes for version 0.7.0, released October 2, 2026, explicitly identify it as the first release published to the WordPress.org plugin directory.
This matters because MCP Adapter is no longer merely something developers need to retrieve as an external package from GitHub. WordPress is positioning the standalone plugin as the supported integration path.
The same release deprecates bundling MCP Adapter as a Composer library and tells plugin developers to depend on the standalone plugin instead.
Two current MCP protocol revisions
Version 0.7.0 serves the 2025-11-25 and 2026-07-28 MCP schema revisions.
Older clients proposing 2025-06-18 or 2024-11-05 can still connect, but the adapter serves them through the 2025-11-25 schema.
The 2026-07-28 implementation adds sessionless server/discover, per-request protocol metadata and new HTTP headers including Mcp-Method, Mcp-Name and Mcp-Param-*.
HTTP and STDIO are supported
The official project supports both HTTP and STDIO transports, allowing different deployment patterns for live sites and local development.
It also supports multiple MCP servers with their own transports, abilities and handlers, rather than forcing every WordPress capability into one undifferentiated endpoint.
The default HTTP endpoint is registered through WordPress's REST infrastructure, while WP-CLI can be used for STDIO scenarios.
The critical security detail: exposure is opt-in
Installing MCP Adapter does not mean every capability on a WordPress installation suddenly becomes callable by an AI agent.
WordPress documentation is explicit: an Ability must be marked public for MCP access before it is reachable through the default server, and permission checks still apply to the authenticated WordPress user before execution.
This distinction is fundamental. Agent readiness should not mean exposing an entire CMS indiscriminately.
From crawlability to executability
Traditional technical SEO asks whether a crawler can access a URL, render its content, understand its structure and index it.
AI visibility expanded that model: can an answer engine retrieve the content, identify its entities, understand who produced it and decide that it is worth citing?
MCP introduces another layer. The question becomes: can an agent discover what the site can do and safely perform an action through a documented interface?
That is a different optimization problem.
A WordPress page can be content; an Ability can be an action
Imagine a travel site. Search engines may crawl destination pages, while AI answer engines may cite those pages in responses.
An MCP-enabled capability could instead let an authorised agent query live availability, retrieve structured information, create a draft itinerary or initiate another application-specific workflow.
For an ecommerce site, the difference could be between an AI assistant reading a product page and an authorised agent invoking a capability that checks current inventory or performs a controlled cart operation.
The exact actions depend on the Abilities implemented by the site. MCP Adapter supplies the bridge, not the business logic.
This is not a new ranking signal
There is currently no evidence that installing MCP Adapter improves Google rankings, causes AI Overviews to cite a site more often or makes ChatGPT select a domain as a source.
Those claims would confuse agent interoperability with search ranking and retrieval.
A site can be perfectly indexable without MCP. It can also expose excellent MCP capabilities while having weak organic visibility.
The strategic connection is broader: websites are gaining another machine-facing interface alongside HTML, feeds, structured data and APIs.
Agent readiness needs its own technical checklist
For teams experimenting with MCP, a useful audit should begin with questions that are closer to API governance than classic SEO:
- Which site capabilities should agents be allowed to discover?
- Which should be read-only and which can change data?
- What authentication is required?
- What WordPress permissions apply to each operation?
- Does an Ability have clear input and output semantics?
- Can an agent understand failures without guessing?
- Are destructive or sensitive actions deliberately excluded?
These issues may eventually sit beside crawlability, structured data and AI citation analysis in broader visibility audits.
Why opt-in Abilities matter for publishers
Publishers have good reason to be cautious about giving automated systems write access to a CMS.
The WordPress architecture addresses that concern by separating the existence of an Ability from its MCP exposure. A capability can exist internally without automatically being available to external agents.
That allows site owners to expose a narrow set of useful operations instead of treating MCP as an all-or-nothing switch.
One migration issue developers should watch
Version 0.7.0 contains breaking changes for developers extending earlier releases. Generated DTO and validator classes were removed, custom transports must now delegate through the newer request-handling architecture, and components that cannot be represented in supported protocol revisions are rejected instead of silently repaired.
Plugins that previously bundled their own copy of MCP Adapter should also migrate to a dependency on the standalone plugin.
That transition is worth checking before assuming that installing 0.7.0 automatically means every other plugin on the site is using the same adapter version.
The SEO implication is bigger than WordPress
For years, SEO has treated the website primarily as a collection of documents that machines retrieve.
Agent protocols push the web toward something more operational: a collection of documents plus capabilities.
That does not replace SEO. Search discovery, brand authority, citations and content quality still determine whether users and AI systems find a site in the first place.
But once an agent finds the business, MCP can potentially determine what that agent can do next.
NetContentSEO take
WordPress MCP Adapter 0.7.0 is an agent-readiness milestone, not an SEO ranking update.
The important shift is that WordPress now has an official, directory-distributed bridge from its Abilities API to MCP tools, resources and prompts, with explicit permission controls and current protocol support.
SEO made websites discoverable. Structured data made parts of them easier for machines to interpret. AI visibility made source selection and citation a new battleground.
MCP adds the next question: after an AI agent discovers your site, can it actually use it?