Macro photo of an orange braided network cable plugging into a glowing port on a small home-lab switch, teal and orange cables beside it in deep shadow, for connecting AI assistants to WordPress with MCP.

هذا المقال متوفر باللغة العربية — اقرأ بالعربية

More site owners are asking me the same question: can I just let ChatGPT, Claude or my code editor talk to my WordPress site directly? The honest answer in October 2026 is yes, partly, and with care. The official route is WordPress MCP support through the MCP Adapter, a package from the WordPress project that sits on top of the Abilities API. This guide explains what it is, what an AI client can and cannot do through it, how authentication works, and the safety rules I follow before connecting anything to a real business site.

Everything below is checked against the official documentation on modelcontextprotocol.io, developer.wordpress.org, make.wordpress.org and the WordPress GitHub repository. Where the docs stop, this guide stops too.

What the Model Context Protocol is

The Model Context Protocol (MCP) is described on its official site as an open-source standard for connecting AI applications to external systems. Instead of every AI tool building its own custom connection to every service, MCP defines one common way for an AI application (the client) to talk to a system that offers data or actions (the server).

An MCP server can offer three kinds of things, and you will see these words again later:

  • Tools: actions the AI can call, such as “create a draft post”.
  • Resources: data the AI can read, such as site information.
  • Prompts: reusable templates that guide the AI through a task.

The specification is versioned by date. At the time of writing, the MCP site lists version 2026-07-28 as the latest. The protocol itself says nothing about WordPress. It is just the plug shape. Something on the WordPress side has to offer a matching socket, and that is where the Abilities API and the MCP Adapter come in.

The Abilities API: the foundation underneath

The Abilities API was introduced by the WordPress Core AI team, and its first implementation shipped in WordPress 6.9. The developer handbook states plainly that it is only available for WordPress 6.9 and above. If you already read my overview of the AI features that landed in WordPress core this year, this is the piece that came first.

According to the handbook, an “ability” is a distinct unit of functionality with:

  • a unique name in the namespace/ability-name pattern,
  • a human readable label and description,
  • input and output definitions written in JSON Schema,
  • a category (each ability belongs to exactly one),
  • an optional permission callback that decides whether the current user may run it,
  • a callback function that does the actual work.

All abilities live in a central registry. Core, plugins and themes can register them, and other code, including external systems like AI agents, can discover them. The key point for site owners: an ability is a deliberately defined action with a permission check, not open access to your database.

What the WordPress MCP Adapter is

The MCP Adapter is the official WordPress package for MCP integration. Its README describes it as part of the AI Building Blocks for WordPress initiative, and says it exposes WordPress abilities as MCP tools, resources and prompts for AI agents. In other words, the Abilities API defines what your site can do, and the adapter translates that into the language MCP clients understand.

Here is the current status as I verified it on October 10, 2026:

  • The code lives at github.com/WordPress/mcp-adapter, licensed GPL-2.0-or-later.
  • It is also listed in the WordPress.org plugin directory as “MCP Adapter”, authored by WordPress.org.
  • The latest release is version 0.7.0, published on October 2, 2026.
  • The plugin directory lists WordPress 6.9 or later and PHP 7.4 or later as requirements.

Notice the version number. It is still below 1.0, and the repository ships migration guides for versions 0.3.0, 0.5.0 and 0.7.0. That tells you the API has changed between releases and may change again. Treat it as early software: fine for staging, testing and carefully scoped production use, but pin your version and read the migration notes before every update.

Main features, per the README

  • Abilities are converted into MCP tools, resources and prompts.
  • Multiple MCP servers can run on one site, each with its own transports and abilities.
  • HTTP and STDIO transports, plus an interface for custom transports.
  • Pluggable error handling and observability, so you can plug in your own logging.
  • Per-server transport authentication and per-ability permission checks.

What an AI client can and cannot do through it

This is the part most people get wrong. Connecting an AI client does not give it “control of WordPress”. It gives it access to whatever abilities have been registered and exposed, and only when the connected user is allowed to run them.

The README is explicit: WordPress abilities are private by default. A developer has to set meta.public (or meta.mcp.public) to true to expose one. The default server then offers three meta-tools for working with them: mcp-adapter/discover-abilities, mcp-adapter/get-ability-info and mcp-adapter/execute-ability.

Question Short answer Why
Can the AI see every plugin’s features? No Only abilities that are registered and marked public are exposed
Can it bypass user roles? No, by design Each ability can run a permission check against the connected user
Can it run arbitrary PHP or SQL? Not through the adapter itself It only executes defined abilities with schemas, unless someone writes an unsafe ability
Can it act as an administrator? Yes, if you connect it as one It inherits the capabilities of the WordPress user it authenticates as

That last row is the real risk. The adapter is only as safe as the abilities that are exposed and the account the client uses. A poorly written ability from a plugin, or an admin account handed to an AI, undoes all the careful design.

How AI clients connect: two transports

The README and the CLI usage guide describe two ways to connect.

STDIO through WP-CLI (local sites)

For a site running on your own machine, the adapter includes a WP-CLI command, wp mcp-adapter serve, that speaks MCP over standard input and output. Many MCP clients can launch this as a subprocess. The guide lists Claude Desktop, Claude Code, VS Code and Cursor as examples of clients you can configure. The command accepts --server to pick a server and --user to choose which WordPress user’s permissions apply. Without --user it runs unauthenticated with limited capabilities. There is also wp mcp-adapter list to see which servers are registered.

HTTP (remote sites)

For a live or staging site, an HTTP client points at the endpoint /wp-json/mcp/mcp-adapter-default-server. Since many desktop clients expect a local process, the docs describe using the @automattic/mcp-wordpress-remote proxy, which runs locally and translates the client’s STDIO messages into HTTP REST calls to WordPress. Authentication here uses Application Passwords.

Authentication with Application Passwords

Application Passwords have been part of WordPress core since version 5.6. The official integration guide on make.wordpress.org explains the parts that matter here:

  • You generate them from the Edit User screen in the dashboard, where you can also view and revoke existing ones.
  • They are meant for API access by applications, not for people logging in interactively.
  • By default they are available to all users on sites served over SSL/HTTPS.
  • WordPress records when each password was last used, which helps you spot and revoke ones nobody needs.

Two practical consequences. First, an application password carries the full capabilities of the user it belongs to, so the user you choose is the real permission boundary. Second, each AI client or tool should get its own named password, so you can revoke one without breaking the others.

Setup walkthrough, as far as the official docs go

I’ll keep this to what the official documentation describes. If your host, client or plugin adds its own steps, follow their docs for those parts.

  1. Use a staging copy first. Confirm it runs WordPress 6.9 or later and PHP 7.4 or later, and that it is served over HTTPS.
  2. Install the MCP Adapter. It is available in the WordPress.org plugin directory and on GitHub. Developers can also bundle it as a package; the repository’s Quick Start guide covers that.
  3. Check which abilities exist. Remember they are private by default. Nothing useful is exposed until a developer (or a plugin) registers abilities and marks them public.
  4. Create a dedicated WordPress user for the AI client, with the lowest role that can do the job. For content drafting, that may be an Author or Editor, never an Administrator.
  5. Generate an Application Password for that user from the Edit User screen, and name it after the client.
  6. Configure your MCP client. For HTTP, the CLI guide shows a configuration like the one below.
  7. Test with read-only actions first, then try one write action on staging and check the result in the dashboard.
{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": [
        "-y",
        "@automattic/mcp-wordpress-remote@latest"
      ],
      "env": {
        "WP_API_URL": "https://staging.example.com/wp-json/mcp/mcp-adapter-default-server",
        "LOG_FILE": "/path/to/logs/mcp-adapter.log",
        "WP_API_USERNAME": "your-username",
        "WP_API_PASSWORD": "your-application-password"
      }
    }
  }
}

Never paste this file into a chat, a shared document or a public repository, because it contains a live credential. If you build sites with AI help in general, my guide on what AI tools can and can’t build on a WordPress site covers where a developer still needs to step in.

Permissions and safety rules I follow

MCP makes it easier for an AI to take actions. That is exactly why the rules around it need to be stricter, not looser. These are the same principles I apply when reviewing the security of AI plugins on client sites.

Least privilege

The adapter’s own CLI guide says to avoid running as admin unless necessary and to use least-privilege accounts. I go further: an AI client never gets an Administrator account on a production site. Create a role or user that can do only the task at hand.

Narrow servers and permission callbacks

By default, a server created with the adapter allows any logged-in user, using is_user_logged_in(). The transport permissions guide shows how a developer can add a custom permission callback, for example current_user_can('edit_posts'). Developers can also run separate servers with only the abilities a specific client needs, rather than one server that exposes everything.

Staging first

Every new ability, client or adapter version goes to staging before production. Given the pre-1.0 version and the migration guides, this is not optional.

Logging and review

The adapter supports pluggable observability and error handlers, and the proxy configuration includes a log file. Turn logging on, and actually read it during the first weeks. Combine this with a normal activity log plugin and backups, as in my regular WordPress maintenance routine.

Human approval for anything public

Let the AI create drafts, not publish. A person reviews and publishes. The same applies to orders, prices, users and settings.

Practical use cases

For site owners

  • Asking an assistant to summarize what content exists or to prepare draft posts, using an Author level account.
  • Getting quick site information through read-only abilities instead of logging in.
  • Preparing bilingual drafts that a human editor then checks, which pairs well with a solid bilingual SEO setup for Arabic and English pages.

For developers

  • Exposing a plugin’s own features as abilities, with schemas and permission checks, so AI clients can use them in a controlled way.
  • Testing abilities locally over STDIO with wp mcp-adapter serve and the --debug flag before going near a live site.
  • Running separate MCP servers for different jobs, such as a content server limited to editors.

What I would not do today: connect an AI to a WooCommerce store’s production orders, or let it change plugins and settings unattended. The building blocks are promising, but the risk sits with the business owner.

Pre-connection checklist

  • WordPress 6.9 or later, PHP 7.4 or later, HTTPS active.
  • MCP Adapter installed on staging first, version noted and pinned.
  • Migration guide read for the version you install.
  • Only the abilities you need are public.
  • Dedicated WordPress user with the lowest workable role, never Administrator.
  • One named Application Password per client, stored outside chats and repositories.
  • Server permission callback set by your developer where appropriate.
  • Logging enabled and reviewed.
  • Fresh backup taken before the first write action.
  • Drafts only; a human publishes.
  • Plan to revoke the password the moment a client is no longer used.

Frequently asked questions

Is the MCP Adapter part of WordPress core?

The Abilities API is in core from WordPress 6.9. The MCP Adapter is a separate official package, available on GitHub and in the WordPress.org plugin directory. Its latest release is 0.7.0.

Does connecting an AI give it access to my whole site?

No. Abilities are private by default, only exposed ones are reachable, and each runs with the permissions of the WordPress user the client connects as. That is why the choice of user matters so much.

Which AI clients can I use?

Any client that supports MCP. The official CLI guide mentions Claude Desktop, Claude Code, VS Code and Cursor as examples, connecting either through WP-CLI over STDIO or through the HTTP proxy.

Can I use it on shared hosting?

The HTTP route needs only the REST API, HTTPS and an Application Password, so it does not depend on shell access. The STDIO route needs WP-CLI on the machine running the site, which usually means a local or developer setup.

Final thoughts

MCP and the Abilities API give WordPress a standard, permission-aware way to work with AI clients, which is far better than the ad hoc integrations we had before. But the adapter is still pre-1.0, and safety depends on how abilities are written and which account you hand over. Start on staging, keep permissions narrow, and keep a human in charge of publishing. If you want help planning or building this for your site, book a free consultation and we’ll look at it together.

References