WordPress & AI Infrastructure
WordPress has put MCP Adapter 0.7.0 in the official WordPress.org plugin directory and is steering developers toward one canonical, standalone plugin for connecting WordPress abilities to AI tools. The release is important infrastructure—but it is not an AI assistant by itself, it is not part of WordPress core, and it should not be installed on a production site without a defined use case and permission plan.[1][2][4]
The release in 30 seconds
- Version: 0.7.0, published October 2, 2026 at 14:39:48 UTC; the WordPress.org directory lists the plugin as added that day.[1][2]
- Requirements: WordPress 6.9 or newer and PHP 7.4 or newer; the live directory currently says tested through WordPress 7.1.3.[2]
- What changed: this is the first MCP Adapter release published in the WordPress.org directory, and bundling the adapter inside other plugins is now deprecated.[1][4]
- What it does: it translates opted-in WordPress abilities into MCP tools, resources, and prompts for authenticated clients.[2][3]
What MCP means in plain English
Model Context Protocol is a standard way for an AI client to discover and call capabilities offered by another system. In WordPress, the Abilities API supplies named capabilities—such as retrieving information or updating something—while MCP Adapter translates selected abilities into MCP-compatible tools, resources, and prompts.[2][3]
Think of the adapter as a controlled bridge, not the driver. It provides the server, protocol negotiation, transports, permission hooks, and error handling. The abilities registered by WordPress core or other plugins determine what an authenticated AI client can actually discover or execute. The official FAQ says the adapter “does not provide any AI features itself.”[2]
What it can provide
What it does not provide
- An AI model or chatbot.
- A promise that every connected client is trustworthy.
- Automatic safety for abilities registered by third-party plugins.
- A reason for an ordinary site to install it without an MCP workflow.
- Blanket authorization for an AI agent to control the whole site.
Why “canonical plugin” matters
Earlier releases were available from GitHub and could also be bundled as a Composer dependency inside another plugin. Version 0.7.0 establishes MCP Adapter as the project’s canonical WordPress plugin and tells developers to move away from bundled copies. Plugins that require it can declare Requires Plugins: mcp-adapter; optional integrations can check that the adapter class and required version are available before enabling MCP features.[4]
That consolidation gives site owners one visible plugin to install and update, while giving developers a common dependency target. It does not mean every older bundled copy will disappear immediately: the migration guide says bundled usage still works for now, but logs a deprecation notice.[4]
What is new—and what may break—in 0.7.0
The protocol work is substantial. Version 0.7.0 has exact schema support for MCP revisions 2025-11-25 and 2026-07-28. Clients that propose the older 2025-06-18 or 2024-11-05 identifiers can still connect, but the adapter serves them through the 2025-11-25 schema. That is compatibility handling, not four equally native schema implementations.[1][4]
The 2026 revision adds a sessionless discovery flow, per-request protocol metadata, new HTTP headers, and support for direct callable tools to request elicitation input. The adapter also stops silently repairing malformed protocol fields: components that no supported revision can represent are rejected instead.[1][4]
On smaller screens, scroll the table horizontally.
| Who you are | Likely impact | What to do |
|---|---|---|
| Site owner using a standalone plugin and ordinary abilities | Ability registration declarations and callbacks generally do not need changes. | Back up, test on staging, inventory exposed abilities, and verify client authentication before production use.[4] |
| Plugin developer bundling MCP Adapter | Bundled-library use is deprecated and duplicate versions can produce notices or conflicts. | Remove the bundled dependency and use the canonical plugin dependency model.[4] |
| Developer using adapter internals, generated DTOs, validators, or custom transports | 0.7.0 contains breaking API and transport changes. | Read the migration guide, select exact schemas, update custom transports, and run raw-wire tests for every revision served.[1][4] |
The security model is layered—not automatic
The adapter documents two authorization layers: a transport-level permission gate for the server and a separate permission callback for each ability. The default transport gate requires a logged-in WordPress user. The individual ability should then check the specific capability and object involved before it executes.[5]
Abilities are private by default on the adapter’s default server. Effective default-server exposure requires meta.public=true or an explicit meta.mcp.public=true; an explicit meta.mcp.public=false overrides the general public flag. A custom MCP server can instead register abilities explicitly. Permission callbacks still run. But “authenticated” does not mean “read-only”: the default execution meta-tool can invoke a write-capable ability when that ability and the current user permit it.[3][6]
The default server logs errors but uses a no-op observability handler. Production teams that need request-level audit records must configure an observability handler and define retention and sensitive-data handling; otherwise, testing a call is not the same thing as retaining a useful request trail.[4]
Our production checklist before connecting an AI client
- Define the job first. Write down the client, the exact operations it needs, the responsible person, and the revocation plan. If there is no concrete workflow, do not add the plugin merely to “turn on AI.”
- Back up and stage it. Make a restorable file-and-database backup, then test activation, authentication, allowed calls, denied calls, logging, deactivation, and rollback on a representative staging site.[10]
- Create a dedicated least-privilege user. Avoid connecting an Administrator account for convenience. Give the integration only the capabilities needed for the abilities it will call.[7]
- Use a unique Application Password over HTTPS. Do not give an AI client the user’s normal WordPress password. WordPress Application Passwords are individually revocable and intended for API authentication.[9]
- Inventory every exposed ability. Review both
meta.publicandmeta.mcp.public, the transport gate, and each permission callback. Repeat the inventory after plugin updates because another plugin can register new abilities. - Require human approval for high-impact work. Publishing, deleting, changing users or settings, installing code, handling orders, or revealing private data should not become silent background actions just because the client supports the tool.
- Monitor and revoke. Retain relevant integration and error logs, rotate or revoke the Application Password if exposure is suspected, and disable the adapter or affected ability if calls do not match the approved workflow.[7]
One compatibility issue deserves watching
An open GitHub issue reports that when another plugin’s Jetpack Autoloader exposes an older bundled adapter first, the canonical 0.7.0 plugin can stand down, leaving the older class active and displaying a duplicate-version notice. The reporter reproduced the behavior in a minimal harness—not yet on a full WordPress installation—and maintainers were still discussing the intended conflict behavior as of our cutoff.[8]
That is a credible compatibility concern for mixed bundled-plus-canonical deployments, not evidence of a universal failure or a security vulnerability. If a production site already has plugins that bundle MCP Adapter, test the complete plugin stack on staging and do not paste an unreviewed issue workaround into production.
Do not confuse this plugin with WordPress.com’s MCP service
This article concerns the installable MCP Adapter plugin for a WordPress site. WordPress.com separately documents a hosted MCP server at https://public-api.wordpress.com/wpcom/v2/mcp/v1 using OAuth 2.1, with one connection able to reach eligible sites on a WordPress.com account.[11]
Eligible self-hosted WordPress.org sites connected through Jetpack can also use that WordPress.com-hosted endpoint with a Jetpack AI or Jetpack Complete plan. That remains distinct from installing MCP Adapter directly on the site.[11]
The hosted service and the installable plugin use different deployment and authorization models. Confirm which product, endpoint, account, and permission system your client is actually using before troubleshooting or approving access.
Who should install it?
Good candidates
- Developers building a specific WordPress ability for an MCP client.
- Organizations with a documented automation workflow and a least-privilege service account.
- Teams prepared to stage, log, review, and revoke the integration.
- Plugin authors moving from a bundled adapter to the canonical dependency.
Wait before installing
- You expect the plugin alone to add an AI assistant.
- You cannot name the abilities or client that need access.
- Your only available credential is an Administrator account.
- You have no staging site, tested backup, monitoring, or rollback path.
- Your plugin stack contains older bundled copies that have not been compatibility-tested.
Frequently asked questions
Is MCP Adapter now part of WordPress core?
No. It is an official project package distributed as a plugin in the WordPress.org directory. WordPress 6.9 includes the Abilities API that the adapter uses, but MCP Adapter remains a separate plugin.[2][3]
Will installing it give my site AI features?
No. The official plugin FAQ says it supplies the server and transport layer and does not provide AI features by itself. Useful behavior comes from abilities registered by core or another plugin.[2]
Does every WordPress ability become available to AI clients?
No. Exposure through the default MCP server is opt-in, and permission checks still run. Developers must still audit public metadata and authorization callbacks carefully.[2][6]
Does the default “read” capability make execution read-only?
No. That capability is part of the default server’s gateway check. A target ability can still write data if its implementation and its own permission callback allow the current user to do so.[5][6]
Should production sites update immediately?
Sites using MCP Adapter should review the 0.7.0 migration guide and test their full integration on staging, especially if they use adapter internals, custom transports, or plugins that bundle older copies. Sites with no MCP use case do not gain AI functionality merely by installing it.
Planning a safe WordPress automation?
The IT Guys can help Treasure Coast businesses evaluate the use case, back up and stage the site, define a least-privilege integration account, test the allowed and denied paths, and build a rollback plan before AI tooling reaches production. We do not recommend installing an integration endpoint first and inventing its permissions later.
Sources and verification
- WordPress/mcp-adapter v0.7.0 release, published October 2, 2026.
- WordPress.org MCP Adapter plugin listing, installation instructions, FAQ, and changelog.
- MCP Adapter v0.7.0 README.
- MCP Adapter 0.7.0 migration guide.
- MCP Adapter transport-permission documentation.
- MCP Adapter default-server documentation.
- WordPress Developer Blog: “From Abilities to AI Agents”, February 4, 2026.
- Open WordPress/mcp-adapter issue #365, checked October 7, 2026.
- WordPress Developer Resources: Application Passwords.
- WordPress Developer Resources: WordPress Backups.
- WordPress.com MCP Server documentation.
Reporting cutoff: October 7, 2026 at 11:08 a.m. EDT (15:08 UTC). “Canonical” describes the project’s recommended standalone plugin and dependency path; it does not mean the adapter is part of WordPress core or that every third-party ability or AI client is safe. Open compatibility reports are labeled as reports, not confirmed vulnerabilities.
Hero media note: The featured image is an original AI-assisted editorial illustration created for The IT Guys, combined with the official WordPress W mark for identification. It is not an official WordPress product image and does not imply endorsement.