WordPress MCP: Publishing From an AI Assistant

WordPress MCP is not one product. On a self-hosted site, the official route is the MCP Adapter, a WordPress package that turns abilities registered through the Abilities API (added in WordPress 6.9) into MCP tools; it replaced Automattic’s earlier wordpress-mcp plugin, which is now archived. On WordPress.com, and on self-hosted sites connected through Jetpack on eligible plans, there is a hosted MCP server with OAuth sign-in and ready-made tools for posts, pages, media and more. And there are third-party plugins. The difference that matters most: the hosted server can draft and publish posts out of the box, while the adapter exposes only what abilities on your site allow, and WordPress core does not yet register abilities that write posts.

Which WordPress MCP you have

• Self-hosted WordPress (your own server or a typical host): the MCP Adapter, connected over WP-CLI or HTTP. You decide which abilities it exposes.
• A site on WordPress.com: the built-in server at https://public-api.wordpress.com/wpcom/v2/mcp/v1. No plugin to install.
• A self-hosted site connected through Jetpack: the same WordPress.com server and tool catalog, on a Jetpack AI or Jetpack Complete plan.
• Anything else: a third-party plugin that runs its own MCP server. Judge it with the questions further down.

The MCP Adapter, from Automattic’s plugin to WordPress core’s package

Automattic built the original WordPress MCP plugin. Its repository is now archived, and its description points to the WordPress/mcp-adapter repository↗ (opens in a new tab), which the WordPress AI team maintains as part of the AI Building Blocks for WordPress initiative. Automattic still publishes the @automattic/mcp-wordpress-remote proxy that connects clients to the adapter over HTTP. As of September 30, 2026, the latest adapter release is v0.6.1 from August 13, 2026, a pre-1.0 version number, and it is installed from the GitHub release ZIP or with composer require wordpress/mcp-adapter, not from the Plugin Directory.

The adapter works on abilities. An ability is a named unit of work (namespace/ability-name) with a typed input and output schema, a permission callback and an execute callback, registered once and callable from PHP, JavaScript and the REST API. The adapter turns abilities into MCP tools, resources and prompts. Three points shape what an assistant can actually do:

• Abilities are private by default. An ability reaches the default MCP server only when it is marked public, with meta.mcp.public or the general meta.public flag that WordPress 7.1 introduces, which the adapter’s README also accepts.
• The default server, mcp-adapter-default-server, exposes three meta-tools: discover abilities, get ability info, and execute ability. The assistant finds the right ability and calls it through them.
• WordPress 6.9 ships three core abilities, all read-only: site info, user info and environment info. Creating or publishing a post needs an ability from a plugin, or one you write.

The roadmap to WordPress 7.2↗ (opens in a new tab) says where this is going, with no promise it lands in core: more abilities in the AI plugin, including exploring write abilities; updating the adapter for the latest MCP specification; publishing the adapter in the Plugin Directory; and letting administrators turn MCP on through the AI plugin. Until then, treat the adapter as a developer tool.

Connecting a client to the adapter

The WordPress developer blog’s guide to the MCP Adapter↗ (opens in a new tab) gives two transports. For a local site, the client starts WP-CLI directly over STDIO, running as a WordPress user you name. For a site on the internet, the client runs Automattic’s proxy, which talks to the site’s REST endpoint. The proxy’s own README lists OAuth, JWT tokens and application passwords; the blog post calls application passwords the default and custom OAuth the option for better security. The same JSON goes into Claude Desktop, Cursor and Claude Code’s .mcp.json; VS Code uses a servers key instead of mcpServers.

{
  "mcpServers": {
    "wordpress-local": {
      "command": "wp",
      "args": [
        "--path=/path/to/your/wordpress",
        "mcp-adapter",
        "serve",
        "--server=mcp-adapter-default-server",
        "--user=ai-contributor"
      ]
    },
    "wordpress-remote": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "ai-contributor",
        "WP_API_PASSWORD": "your-application-password"
      }
    }
  }
}

Note the user. The adapter runs every call as the WordPress user in --user or the application password, and each ability’s permission callback checks that user’s capabilities. The developer blog’s advice is a dedicated user with limited capabilities, read-only abilities on anything reachable over the internet, and no __return_true permission callbacks on destructive abilities. Keep the application password out of any file you commit; the difference between a local and a remote server is covered in local vs remote MCP servers.

WordPress.com and Jetpack sites

The hosted route is much shorter. Per the WordPress.com MCP docs↗ (opens in a new tab), you turn MCP on in your WordPress.com account settings, then add the server URL to your client. One connection reaches every site on the account. Sign-in is OAuth 2.1 with PKCE and dynamic client registration, so no secret is stored on your machine, and you revoke a client under Security, Connected Apps. MCP is available on all paid WordPress.com plans, for the first 30 days on a free site, and on Jetpack-connected sites with Jetpack AI or Jetpack Complete. Claude Desktop connects through the Connectors Directory, ChatGPT through the WordPress.com plugin, and Claude Code with one command:

claude mcp add --transport http wpcom-mcp https://public-api.wordpress.com/wpcom/v2/mcp/v1

The tools are grouped behind a few facade tools, such as wpcom-mcp-content-authoring, each with list, describe and execute actions. According to the tools reference↗ (opens in a new tab), posts.create makes a draft by default, posts.update with a status of publish goes live immediately, and deleting a post moves it to the trash for 30 days. Every write must carry user_confirmed: true, which the agent is supposed to set only after describing the change and getting your explicit yes. Some deletions are permanent: categories, tags, media and taxonomy terms have no trash.

Publishing from an assistant without regretting it

The safest pattern is the one WordPress already has for new writers: the assistant writes, a person publishes. WordPress’s roles and capabilities↗ (opens in a new tab) article defines a Contributor as someone who can write and manage their own posts but cannot publish them, and an Author as someone who can publish their own. Run the adapter as a Contributor account and a publish attempt fails on permissions, whatever the prompt says. On WordPress.com, where the connection acts as your own account, the same line has to be held by the confirmation step and your instructions.

1. Ask for a draft with a title, excerpt, categories and tags, and say “do not publish” in the prompt.
2. Open the draft in the editor. Check facts, links, images and alt text, and anything in the voice of a real person.
3. Publish or schedule it yourself.
4. For edits to live posts, prefer section-level changes (post-sections.replace on WordPress.com) over replacing the whole body, and read the diff before confirming.

Comments and form entries are text strangers wrote. An assistant that reads them can meet instructions planted there, which is indirect prompt injection; do not give the same session rights to publish and delete.

Choosing the best WordPress MCP plugin

There is no single best one; there is the one that fits your hosting. On WordPress.com or Jetpack, use the built-in server. On a self-hosted site, start with the official adapter and a plugin whose abilities you trust. For any third-party MCP plugin, ask:

• Does it register abilities through the Abilities API, or run its own separate server and endpoints?
• How does a client authenticate, and can you give it a user with fewer capabilities than an administrator?
• Are destructive operations off by default, and do deletes go to the trash?
• Does it log which tool was called, by whom and with what input?
• Who maintains it, how often is it updated, and does it follow the current MCP specification?

WordPress or Webflow

Webflow has one hosted server with a fixed set of tools and a publish action behind your own role. WordPress gives you either a hosted catalog or an adapter that is only as capable as the abilities on your site. If you run a Webflow site as well, Webflow MCP covers it.

Tracking editorial work on a board

Drafts need an owner and a next step, and neither lives in WordPress’s draft list. With fenbs connected as another MCP server at https://fenbs.ai/api/mcp, the assistant can open a task for each draft it writes, with the draft’s edit link in the note and the outline in the plan, and set the test status to show what it checked (links, alt text) and what a person still has to. Paste an editorial calendar into Add many to turn a list of headlines into tasks in one step. Tasks move from To Do through Next Up and In Progress to Completed, and History shows which assistant changed what. Put “assistants never publish” on the Decisions and rules page so every connected assistant reads it first.

fenbs has no due dates or assignee field, so a publish date or an editor’s name goes into the note as text. The post itself stays in WordPress.