WordPress.com Opens Write Access to AI Agents via MCP

WordPress.com expanded its Model Context Protocol integration to give AI agents write access across posts, pages, comments, media, and taxonomy - 19 new operations, all requiring explicit user confirmation before execution.

WordPress.com Opens Write Access to AI Agents via MCP

WordPress.com has flipped the switch on write access for AI agents. On March 20, the platform extended its Model Context Protocol (MCP) server from read-only queries to full content management: agents connected via Claude, ChatGPT, Cursor, or any MCP-compatible client can now draft posts, publish pages, moderate comments, and bulk-update media metadata without ever opening a browser.

That scope matters. WordPress powers 43% of all websites globally. If MCP write access becomes the norm rather than the exception, a large share of the web's publishing infrastructure will be routinely accessible to automated agents.

TL;DR

  • WordPress.com added 19 new MCP operations across posts, pages, comments, media, categories, and tags
  • Works with Claude, ChatGPT, Cursor, and any MCP-enabled client via https://public-api.wordpress.com/wpcom/v2/mcp/v1
  • Every write operation requires explicit user_confirmed flag before execution; new posts always default to draft
  • Available now on all paid WordPress.com plans; enable at wordpress.com/me/mcp
  • Builds on read-only MCP access launched in October 2025 and the WordPress 6.9 Abilities API

What the Update Actually Adds

The March 20 release is the second phase of a rollout that started quietly in October 2025 when WordPress.com launched read-only MCP access - letting agents query posts, analytics, and site settings without being able to touch anything. Write access was the piece developers were waiting for.

The 19 New Operations

The new wpcom-mcp-content-authoring tool exposes operations across six content types:

  • Posts - posts.create, posts.update, posts.delete
  • Pages - pages.create, pages.update, pages.delete
  • Comments - comments.create, comments.update, comments.delete
  • Categories - categories.create, categories.update, categories.delete
  • Tags - tags.create, tags.update, tags.delete
  • Media - media.update, media.delete

That last one is underrated. Bulk-fixing broken alt text across a media library is the kind of tedious task that actually benefits from agent automation, and it's the kind of operation that rarely gets built into plugins.

Design-Aware Content Generation

Before producing any content, agents can call the theme context endpoint to read the site's block patterns, color palette, typography, and spacing. According to the official announcement: "Before creating content, your AI agent can search your theme's design and understand its colors, fonts, spacing, and block patterns."

In practice, this means an agent drafting a landing page can pull the site's button style and heading fonts rather than generating generic HTML that then needs manual cleanup.

WordPress.com MCP settings panel showing per-site operation toggles The MCP dashboard at wordpress.com/me/mcp lets site owners enable or disable individual operation types per site. Source: developer.wordpress.com

How It Works Under the Hood

The write capabilities are built on the WordPress Abilities API introduced in WordPress 6.9, with a MCP Adapter translating Abilities into MCP primitives. Three meta-tools are always available: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info, and mcp-adapter-execute-ability. Specific content operations register as Abilities that must be flagged meta.mcp.public: true to appear on the MCP surface.

Connecting to the Server

The MCP endpoint is public and documented:

https://public-api.wordpress.com/wpcom/v2/mcp/v1

For local use, the WP-CLI transport works on self-hosted installs:

wp --path=/path/to/wordpress mcp-adapter serve \
  --server=mcp-adapter-default-server \
  --user={admin_user}

Remote access uses the @automattic/mcp-wordpress-remote Node.js proxy, which handles the OAuth handshake and forwards tool calls to the WordPress.com REST API.

Authentication

The platform moved to OAuth 2.1 in January 2026, adding PKCE, dynamic client registration, and token rotation. The security model is explicit in the docs: "Your WordPress.com credentials are never stored on your computer or shared with your AI client; only secure, expiring access tokens are used."

Self-hosted WordPress installs can use application passwords as an alternative, which is less elegant but works without touching OAuth configuration.

Safety Guardrails

Every write operation requires user_confirmed: true in the tool call parameters. The MCP server won't execute without it - the agent has to describe the action and receive approval before anything changes. Permanent deletes (categories, tags) require a second confirm_permanent_delete: true flag on top of that.

New posts default to draft status. A published post being modified triggers an additional warning. Everything is logged in the Activity Log. WordPress role permissions are enforced: an Editor can manage posts but can't touch site settings, a Contributor can draft but can't publish.

Site owners control access at the operation level. Individual tool types can be toggled on or off per site in the MCP dashboard.

MCP general architecture diagram showing host, clients, and servers MCP connects AI clients (Claude, Cursor, ChatGPT) to WordPress.com's server, which translates agent tool calls into WordPress REST API operations. Source: descope.com

The Rollout Timeline

  • October 2025 - Read-only MCP launched on WordPress.com; agents can query posts, analytics, site settings.

  • January 2026 - OAuth 2.1 authentication added, replacing the earlier application password-only flow.

  • February 5, 2026 - Official Claude Connector released as a read-only connector on the Anthropic MCP registry.

  • February 17, 2026 - WordPress AI Assistant launched, giving non-technical users a guided interface to the same MCP layer.

  • March 20, 2026 - Write capabilities go live with 19 new operations across six content types.

The MCP Adapter is also tracking toward inclusion in WordPress Core with version 7.0. The Automattic/wordpress-mcp GitHub repository has been deprecated for the canonical WordPress/mcp-adapter repo, which is a signal that this infrastructure is being treated as a platform feature rather than a plugin.

WordPress.com website interface screenshot WordPress.com now positions MCP as a standard feature for paid plan subscribers, accessible from the account settings menu. Source: thenextweb.com

Compatibility at a Glance

ClientConnection MethodAuthAvailable Now
Claude Desktop / Claude CodeMCP remote server URLOAuth 2.1Yes
ChatGPTMCP remote server URLOAuth 2.1Yes
CursorMCP remote server URLOAuth 2.1Yes
VS CodeMCP remote server URLOAuth 2.1Yes
Self-hosted WP-CLISTDIO transportApp passwordsYes (self-hosted)
Any MCP clientRemote HTTP proxyOAuth 2.1 / App passwordsYes

Where It Falls Short

The safety story is solid for deliberate, attended use. An agent asking before every write, defaulting to drafts, and logging changes covers the obvious failure modes. But the docs don't address what happens when an agent operates on a long multi-step task with pre-approved confirmation patterns - the kind of autonomous workflow that Claude Code's Auto Mode enables. If confirmation gets baked into an automated pipeline rather than surfaced to a human, the guardrails stop functioning as designed.

The write capabilities are also gated to paid plans with no public pricing on which tier qualifies. Developers building automations on top of the API face uncertainty about whether their users' plan levels will support the tooling.

More structurally, MCP as a protocol doesn't distinguish between a trusted human-supervised client and an autonomous agent with delegated permissions. VS Code 1.110 and other tools already support persistent MCP connections with minimal per-action friction. A site owner who connects Claude once and forgets about it is effectively leaving write access open. There's no session expiry or inactivity revocation visible in the current docs.

The scale concern is real too. WordPress.com is not the first platform to add MCP write access - attackers already built custom MCP servers to automate exploitation chains against network infrastructure, and Meta's own AI agents have written to internal systems without authorization. The same protocol that makes content management smooth makes policy enforcement harder. Automattic's role-based permission model is a reasonable baseline, but it was designed for humans with browsers, not for agents with persistent tokens and automated triggers.


WordPress.com's MCP implementation is technically clean - better designed than most first-generation agent integrations shipping right now. The question isn't whether agents should have write access to CMS platforms, they'll have it everywhere soon. The question is whether the permission model will scale as agent autonomy increases, or whether the current confirmation-per-action design will turn into a rubber-stamp click that nobody reads.

Sources:

WordPress.com Opens Write Access to AI Agents via MCP
About the author AI Infrastructure & Open Source Reporter

Sophie is a journalist and former systems engineer who covers AI infrastructure, open-source models, and the developer tooling ecosystem.