WordPress MCP: We Connected Our Site to Claude

The StartingUp Summer. We're using the season to map out, unvarnished, a year that upended our methods. After the questions AI made obsolete, here's an experiment run in production: connecting our WordPress to Claude via MCP, and letting AI write directly into our CMS.

The last update to this site's legal notice didn't go through the WordPress admin. It was drafted in a conversation with Claude, Anthropic's assistant, which then wrote the content itself into our CMS, with the permissions we had granted it. No copy-pasting, no admin tab open: one instruction, one review, and the page live a few seconds later.

Behind this small moment of domestic science fiction lies an open standard you'll hear more and more about: MCP, for Model Context Protocol. We connected our WordPress to it, for real, in production. Here's what this protocol covers, why it deserves a decision-maker's attention, how we implemented it, and what we learned along the way.

Connecting WordPress to Claude via MCP is now within reach of any site: WordPress 6.9's Abilities API declares the CMS's capabilities, the official mcp-adapter exposes them as MCP tools, and the assistant connects to them with the rights of a dedicated account. Three standard building blocks, which we break down below.

Before MCP, every connection between an AI assistant and a business tool was a custom build. Ten tools, three assistants: thirty integrations to write and maintain. In late 2024, Anthropic published MCP as open source to solve exactly this problem: a single protocol through which any assistant can discover and use the capabilities of any tool that implements it. The official documentation uses an image that's since become canonical:

Think of MCP like a USB-C port for AI applications.

Official Model Context Protocol documentation (translated by us)

What could have stayed a proprietary format has become, in eighteen months, a de facto standard. OpenAI adopted it in spring 2025, Google followed, and in late 2025 Anthropic handed the protocol's governance to a neutral foundation under the Linux Foundation: MCP no longer belongs to one vendor, it belongs to the ecosystem. That ecosystem now counts thousands of published servers, from databases to design tools. The specification keeps evolving (a major revision is in the works as we write this), but the foundation is stable and very widely deployed.

The workflow everyone practices today looks like this: you draft with AI in one tab, copy, paste into the site's admin, recreate the formatting, fix the links lost along the way. The friction is low per instance, considerable in aggregate, and every manipulation is an opportunity for error.

MCP flips the logic: instead of bringing your content to the AI, the AI comes to work inside your tool. Concretely, once the CMS is connected:

• AI-assisted writing lands directly as a draft in the CMS, formatting included, with no copy-pasting;
• Bulk updates become a single instruction: refreshing a legal notice, fixing a detail that appears on several pages;
• Content becomes queryable in plain language: which articles already cover a given topic, which ones haven't been touched in two years.

The decisive point for a decision-maker fits in one sentence: the AI reads and writes your content with the permissions you give it, and only those. This isn't a robot let loose in your back office, it's a collaborator whose job description you write.

Our site is a headless WordPress paired with a self-hosted Next.js front end, whose containerization on our own VPS we've already told you about. The back end already exposed an API; adding an MCP socket to it was a natural evolution, and the WordPress ecosystem made the exercise surprisingly short.

The foundation now exists in WordPress core: since version 6.9, the Abilities API lets you declare a site's "capabilities" in a standardized way. Each capability bundles four things: a name, a schema describing the accepted inputs, an execution function, and a permission rule. The official mcp-adapter, published by the WordPress project, then exposes these capabilities as MCP tools on a REST route of the site. Our share of the work: a mu-plugin of about 160 lines that declares three editorial capabilities: create content, update it, list what exists. A few dozen lines per capability, and here's the first one, barely simplified:

Nothing exotic: standard WordPress from end to end. The value is in the two safeguards: the input schema tells the AI what it can send, the permission rule bounds what it's allowed to do.

For authentication, we settled on Application Passwords, native to WordPress: a dedicated password, revocable at any time, tied to a specific account and sent over HTTPS. Claude connects with this account and inherits exactly its rights, no more, no less. One last bonus, specific to our headless architecture: when Claude edits a piece of content, our Next.js front end's revalidation mechanism triggers automatically, and the up-to-date page is served to visitors a few seconds later.

The story would be suspect without the failures. Here are ours, in the order they cost us time.

• The input schema isn't optional. Our first capabilities didn't declare one: the adapter then rejected any argument supplied, and crashed with an unhelpful PHP error when none was given. input_schema is the contract between the AI and your site; without it, nothing works, and that turns out to be a good thing.
• A 404 can hide something obvious. An adapter that's installed but not activated simply doesn't create the route: checking whether the plugin was active before suspecting its configuration would have saved us an evening.
• Never expose it without authentication. An MCP server capable of writing is a door into your site. Authentication mandatory, HTTPS, and an account with minimal rights: our read capability requires the read permission, the write ones edit_posts, and never an administrator account.
• Draft by default. Our capabilities create content as draft unless explicitly told otherwise: publishing stays a human decision, made after review.

The clearest gain isn't spectacular, it's daily: editing tasks that used to mean juggling screens now settle inside the conversation where the work already happens. The draft is born where it will be published, bulk corrections no longer depend on the patience of whoever's clicking, and taking stock of content is as simple as asking a colleague a question.

Honesty demands the other side too. Human review stays systematic: the AI writes well, it can also get things wrong with confidence, and published content is your company's responsibility. Our implementation covers the editorial essentials, not everything: no media management, no fine-grained SEO settings at this stage. The protocol moves fast, which means keeping up with updates to the adapter and the spec. Last and most important: connecting an AI to your CMS is less a technical question than a governance one. Who's allowed to do what, on which content, with what review? That answer has to come before the connection, not after.

The cost of the experiment fits in three lines: an official adapter, about 160 lines of PHP, an application password. What matters isn't the feat, it's the position gained: a CMS connected to MCP stops being a silo you copy into, it becomes a tool your AI assistants can read and feed, under your control and your rules.

If there's one question to take from this piece, let it be this: in your business tools, what are the three actions your teams redo by hand every week that would deserve a standard socket? For us, the answer came down to three verbs: create, update, list. We started there; it's modest, and it's already a different job.