WordPress.com Adds AI Agent Post Publishing

WordPress.com added MCP write access on March 20, which means AI agents can now create, edit, publish, and delete site content through connected clients like Claude Desktop, ChatGPT, Cursor, and VS Code. For developers building agent workflows on top of content systems, the release turns WordPress.com from an AI-readable CMS into an AI-writable one.

Product Scope

WordPress.com’s new content management capabilities add 19 writing actions across six content types: posts, pages, comments, categories, tags, and media. The practical change is broad. An agent can draft and publish blog posts, build and update pages, moderate comments, organize taxonomy, and update media metadata including alt text, captions, titles, and descriptions.

This extends the MCP integration WordPress.com introduced in October 2025, when access was read-only. The missing half was execution. It is now live.

WordPress.com exposes the integration on all paid plans through the MCP endpoint below:

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

Tooling Model

The write and delete path is consolidated into a single MCP tool, wpcom-mcp-content-authoring. It supports list, describe, and execute actions, which is a useful pattern if you care about predictable agent behavior. The model can inspect available operations, describe the intended mutation, then perform it through a structured call, similar to the function-calling patterns used in modern agent stacks. If you are working with MCP or designing agent skills, this is the part worth studying.

The documented content operations are specific enough to be production-relevant. posts.create defaults to draft, but also supports publish, future, pending, and private. Posts can include SEO-related fields such as advanced_seo_description, jetpack_seo_html_title, and jetpack_seo_noindex.

Pages support hierarchical creation with optional templates. Comments can be created, updated, and deleted. Media operations are limited to metadata updates, which matters because agents are not uploading arbitrary binary assets through this tool, they are modifying how existing assets are labeled and presented.

Permissions and Safety Controls

WordPress.com put explicit friction in front of mutations. Write operations are never auto-executed. The agent must describe the action, request confirmation, and pass user_confirmed in the execute parameters.

Several controls reduce blast radius for common workflows:

Control	Behavior
Post creation	Defaults to draft
Deletion recovery	Posts, pages, comments, and media generally recoverable from trash for 30 days
Permanent deletes	Categories and tags delete permanently
Auditability	Changes appear in the Activity Log
Permissions	Existing WordPress.com roles still apply

The role model is especially important. Administrators, Editors, and Authors get full content authoring access. Contributors are limited. Subscribers and customers do not get content authoring access. If you are evaluating AI agents vs chatbots, this is the operational difference in one product release: the system is no longer generating suggestions inside a chat window, it is taking authenticated actions against production content.

Authentication and Client Support

WordPress.com uses OAuth 2.1 with PKCE for MCP authentication. That is the enabling infrastructure behind this launch. Agent connections no longer depend on improvised credential handling, which lowers the integration cost for desktop and IDE clients.

Supported MCP-capable clients include Claude Desktop, ChatGPT, Cursor, and VS Code, with Gemini and Perplexity also named in support material. ChatGPT support has a product constraint worth noting: it requires Developer Mode and a Plus, Pro, Team, or Enterprise plan.

Design-Aware Content Generation

The technical detail that stands out is theme awareness. Agents can inspect the active theme and presets before generating content, including colors, fonts, spacing, and block patterns. WordPress.com recommends retrieving theme.active and theme.presets from wpcom-mcp-site-editor-context so agents use preset slugs instead of hard-coded style values.

This matters if you are building agents that generate block-based layouts rather than plain text. The agent is not just filling a body field. It can produce pages aligned to the site’s design system. That shifts the task from text generation toward structured UI assembly, which also raises the bar for evaluating agents. You now need tests for content correctness, permission boundaries, and visual consistency with the theme.

Comparison With the Previous State

The progression is straightforward:

Capability	October 2025	March 20, 2026
Read site data via MCP	Yes	Yes
Create and edit posts/pages	No	Yes
Moderate comments	No	Yes
Manage categories and tags	No	Yes
Update media metadata	No	Yes
OAuth 2.1 for MCP auth	Added later	Yes

For teams automating editorial workflows, this reduces the amount of custom middleware needed between an LLM client and a CMS. You can treat WordPress.com as an authenticated action surface directly, then focus your work on context engineering, approval policy, and evaluation rather than building your own publishing connector.

If you plan to use it in production, keep the agent on draft-first workflows, restrict access by WordPress role, and test destructive actions separately from publishing flows before giving the model any path to a live site.