How to run an MCP server on WordPress

The problem is simple: Claude cannot open your WordPress admin panel. It cannot query your post database, update a meta description, or publish a draft. You can paste content into a chat window, get a rewrite, and paste it back. That works for ten posts. It does not work for ten thousand.

A MCP server for WordPress changes that. It gives AI agents a structured, permissioned channel into your WordPress installation so they can read posts, write meta, update taxonomies, and trigger publish workflows, all without a human in the copy-paste loop. This post covers what MCP actually is, why WordPress is the right target, three use cases worth building for, the architecture options with real tradeoffs, the security requirements you cannot skip, and what it costs to have this built.

What Model Context Protocol Actually Is

Model Context Protocol (MCP) is an open standard, published by Anthropic, that defines how AI agents communicate with external systems. The analogy that holds up: it is a USB-C spec for AI tools. Any MCP-compatible client (Claude Desktop, the Claude API, or any agent framework that implements the protocol) can connect to any MCP-compatible server and immediately discover what tools and data resources that server exposes. No custom integration code. No bespoke webhook design. One protocol, interchangeable clients and servers.

The architecture has three moving parts. The client is the AI agent. The server is a lightweight process you run alongside your system. The tools are named, typed functions the agent can invoke, such as get_post, update_post_meta, or list_media. Resources are read-only data sources the agent can sample without side effects, useful for giving the agent context about your site's taxonomy or post structure before it starts writing.

What MCP eliminates is the brittle middle layer. Without it, you either prompt-engineer an agent to "use the WordPress REST API" and hope it generates correct curl syntax, or you write a one-off integration for every tool the agent needs. With MCP, you define tools once. The agent discovers them, reads their typed schemas, and calls them correctly.

Why WordPress Is the Right Target for model context protocol integration

WordPress runs somewhere around 43% of the public web. That is not a marketing number; it is the Netcraft and W3Techs figure that has held reasonably steady for several years. The content teams managing those sites are already using AI assistants to draft, rewrite, and edit. Every agency that builds on WordPress has clients asking about AI. The missing piece is not the AI model. It is the connection between the model and the content system.

Right now, every AI-assisted content workflow on a WordPress site has a human relay in the middle. The writer asks Claude to improve a product description. Claude returns a better version. The writer copies it. The writer opens WordPress. The writer pastes it. The writer saves. Multiply that by 500 pages and you have not automated anything. You have made the writer faster at one step of a many-step process.

MCP closes that gap structurally. When a WordPress site exposes a proper MCP server, an agent can pull a list of posts with thin content, rewrite each one against a brief, push the new body back into the draft, and set a custom field flag to queue human review. The agent does the mechanical labor. The editor reviews a diff, not a blank page.

The case is even more compelling for teams already running headless WordPress, where the CMS feeds a Next.js or Astro frontend. In a decoupled setup, WordPress is already functioning as a structured data store exposed through an API. Adding an MCP layer on top of that existing API surface is a natural extension. The agent has one structured interface to read from and write to. The front end renders whatever the CMS holds. The human reviews what the agent changed. No workarounds, no screen-scraping, no copy-paste relay.

Three Use Cases Worth Building For

Bulk content operations

You have 200 WooCommerce product descriptions written five years ago. They are thin. They have no target keywords. They were copied from the manufacturer's data sheet and never touched since. A human content team would need three weeks to rewrite them all, and the brief would have to be communicated across dozens of hand-offs.

An MCP-enabled agent handles this differently. It calls list_posts with post_type: product and retrieves all 200. It scores each description against a keyword brief and minimum word count, rewrites the ones below threshold, and calls update_post with the new content body. It sets a _ai_reviewed custom meta field to pending. You get a queue of 200 updated drafts waiting for a single editorial pass.

The same logic applies to image alt text. If your site has been running for five years, you almost certainly have thousands of images with empty alt fields. An agent with access to get_media and update_media tools can describe each image using a vision model and write the alt text directly to WordPress. No bulk plugin, no CSV export, no manual re-import. One agent run.

SEO automation at scale

Every page on a WordPress site has a meta title and meta description field, whether the site uses Yoast SEO, RankMath, or another SEO plugin that registers its own meta keys. Most of those fields are either empty or auto-generated from the post title. Neither state is optimal.

An agent connected through your WordPress REST API integration can pull every published post in batches, evaluate the existing Yoast _yoast_wpseo_title and _yoast_wpseo_metadesc meta values against a target keyword list, score each one, and rewrite the ones that are missing or below a threshold character count. It writes the output back via update_post_meta. For a 500-page site, that is a full-day human task reduced to a twenty-minute agent run.

Internal link suggestions work on the same principle, but the agent needs broader context. It reads all your posts via list_posts with full content, builds a semantic understanding of what each post covers, and then for each post, identifies two or three others that are topically related but currently unlinked. It returns those as suggestions: post ID, anchor text, target URL. You review the suggestions as a batch, approve or edit, and the agent writes the links in the next pass. This is a closed workflow that a human editorial team would spend days running manually, and would typically only do once.

Automated schema generation is another fit. The agent reads a post's content, category, and custom fields, generates appropriate JSON-LD structured data (Article, Product, FAQPage), and writes it to a custom meta field that your theme renders in the <head>. No plugin configuration, no manual schema entry per post.

Editorial workflow automation

This is the most common entry point for teams new to MCP, because it does not require bulk data access and the human stays in control at every stage.

The flow: a content brief arrives in a spreadsheet, a Notion database, or a form submission. A webhook or a scheduled agent call reads the brief. The agent calls create_post with status: draft, fills in the title, writes a first-pass body based on the brief, and sets _brief_source meta to the originating record. An editor receives a Slack notification (triggered by a webhook on the draft post creation). The editor opens the draft in the WordPress block editor, which looks exactly like any other draft. They read, edit, and publish.

The agent has done the first-draft work. The editor has done the judgment work. Nobody copied anything from one window to another.

This workflow scales horizontally. If your brief queue has 40 posts, the agent runs 40 create_post calls in sequence. Each draft lands in the editorial queue. The bottleneck moves from "who is writing this?" to "who is reviewing this?" That is a better problem.

Architecture Options and Honest Tradeoffs

There are three practical implementation paths for a wordpress ai automation setup with MCP. Each makes different tradeoffs on speed, capability, and security.

Option 1: REST API wrapper.

You write a lightweight Node.js or Python MCP server that translates agent tool calls into WordPress REST API requests at /wp-json/wp/v2/. Authentication uses Application Passwords, which WordPress has supported natively since version 5.6. You generate an application password for a dedicated WordPress user, encode it in a Basic auth header, and every tool call the agent makes hits a REST endpoint under those credentials.

This is the fastest path to a working server. Two to five days of engineering gets you a set of tools covering posts, pages, media, and taxonomies. The tradeoff is scope: you are limited to what the native REST API exposes. Custom post type fields registered with ACF, complex meta relationships, or actions that require running PHP hooks are not available without additional route registration. For many content teams, the native endpoints are sufficient. For sites with heavy custom data architecture, you will hit the ceiling quickly.

Option 2: WP-CLI bridge.

Instead of the REST API, the MCP server executes wp commands on the server via SSH or a subprocess call. wp post update 42 --post_content="..." is the equivalent of a REST PATCH. This gives the agent access to virtually anything WP-CLI can do: database queries, user management, plugin activation, option updates, cache flushes, and custom WP-CLI commands your plugins register.

The power is genuine. The requirement is shell access to the server, which most managed hosting environments restrict or prohibit. Kinsta, WP Engine, and Cloudways have SSH access, but they may not allow arbitrary subprocess execution from a web context. This option works well for self-managed VPS setups and for administrative agents (maintenance, migration, configuration). It is not suitable for multi-tenant environments or shared hosting.

Option 3: Custom WordPress plugin.

The architecture that belongs in production. A dedicated plugin registers custom REST routes (/wp-json/mcp/v1/) that map directly to the tool definitions in your MCP server. Each route handler runs current_user_can() before touching any data. Every successful write operation appends to a structured audit log (post ID, field changed, previous value, new value, timestamp, user). The MCP server authenticates via an application password tied to a dedicated WordPress user with exactly the capabilities required and nothing more.

This takes longer: one to three weeks of engineering depending on the tool count and complexity. But the result is a clean, maintainable surface. When you need to add a new tool, you add a new route in the plugin and a new tool definition in the MCP server. When a security audit happens, you can point to the audit log and the role definition. When the AI model changes, the WordPress side does not need to change.

For most agency clients: Option 1 for proof-of-concept, Option 3 for production. The work of building custom WordPress plugins that expose typed, permission-checked API surfaces is exactly what a production MCP deployment requires.

Security: What You Must Get Right

Exposing WordPress to an AI agent via an API creates a new attack surface. This section is not optional.

Capability-scoped tokens. Create a dedicated WordPress user for every agent integration. Assign the minimum role: contributor or author for content-only agents, editor if the agent needs to publish. Do not use your own administrator account. Do not create an agent user with the administrator role. Application Passwords in WordPress are per-user and independently revocable. If the agent credential leaks, you revoke that one password without touching anything else on the site.

Never expose manage_options by default. The manage_options capability covers update_option(), which can change the site URL, the email address, the active theme, and plugin settings. An agent that can call arbitrary options updates can take down a site or redirect it. If a legitimate use case requires reading or writing an option, build a narrowly scoped tool that touches exactly that option key and logs the change. Never expose a general-purpose options tool.

Audit logging on every write operation. WordPress does not natively log what the REST API writes. Your MCP plugin must do this. Minimum log entry: timestamp, tool name, WordPress user ID, post ID or resource identifier, field changed, previous value hash, new value hash, response status code. Store in a custom database table or structured log on S3. You need to answer "what did the agent change between midnight and 6am?" with a precise record.

Rate limiting at the MCP server level. Agents can enter unexpected loops. A poorly constructed multi-step prompt or a bug in tool orchestration can generate hundreds of identical write calls in seconds. Your MCP server should implement per-tool rate limits (for example, no more than 50 update_post calls per minute per agent session) and return a structured error when the limit is hit. This prevents runaway writes from corrupting content at scale.

Idempotency on writes. Each update_post call should be idempotent: calling it twice with the same arguments should produce the same result as calling it once. Pass the current content hash as a precondition check. If the content changed between when the agent read it and when it writes, reject the write and return a conflict error. This prevents race conditions when multiple agent sessions are running concurrently.

A Working MCP Tool Definition

This is a real tool definition in TypeScript using the official MCP SDK. It calls the WordPress REST API with Application Password authentication to fetch a single post. This is the exact pattern your MCP server would use for every tool.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const WP_BASE = process.env.WP_BASE_URL; // e.g. https://yoursite.com
const WP_USER = process.env.WP_APP_USER;
const WP_PASS = process.env.WP_APP_PASSWORD;

const auth = Buffer.from(`${WP_USER}:${WP_PASS}`).toString("base64");

server.tool(
  "get_post",
  { id: z.number().describe("WordPress post ID") },
  async ({ id }) => {
    const res = await fetch(`${WP_BASE}/wp-json/wp/v2/posts/${id}`, {
      headers: { Authorization: `Basic ${auth}` },
    });
    if (!res.ok) throw new Error(`WP API error: ${res.status}`);
    const post = await res.json();
    return {
      content: [{ type: "text", text: JSON.stringify(post, null, 2) }],
    };
  }
);

In production, you add update_post, list_posts, create_post, get_media, update_media, and update_post_meta on the same pattern. Each tool takes typed arguments defined with Zod schemas. The MCP client calls list_tools() when it connects and receives the full typed catalog. The agent reads those schemas to understand exactly what each tool expects, which arguments are required, and what the valid value ranges are.

The server process registers these tools and exposes them over a stdio transport (for local integrations like Claude Desktop) or an HTTP transport with Server-Sent Events (for cloud-hosted agents that need a persistent endpoint). The transport choice depends on your deployment architecture. Most production WordPress MCP setups use HTTP transport with an authentication layer in front of the MCP server itself.

One note on naming convention: use snake_case tool names that match WordPress conventions (get_post, update_post_meta) rather than camelCase. The tool descriptions you write in Zod .describe() calls become part of the agent's decision-making context. Write them carefully.

What to Expect on Timeline and Cost

A production-ready MCP server for WordPress, built as a custom plugin with proper auth scoping, audit logging, rate limiting, and a set of 8 to 12 tools covering posts, pages, meta, media, and taxonomies, runs $500 to $2,000 as a build engagement. Infrastructure after that is $50 to $100 per month depending on agent call volume, hosting environment, and whether you need any managed orchestration layer on top.

What drives scope upward: custom post types with complex ACF field groups, multi-agent setups where different agents need different tool subsets, integration with a third-party orchestration layer like n8n or a custom workflow engine, and compliance requirements that add audit retention and access control complexity.

Timeline by approach:

• REST API wrapper proof-of-concept: 3 to 5 days
• REST API wrapper with proper error handling and rate limiting: 1 to 2 weeks
• Custom plugin (full Option 3 implementation): 2 to 3 weeks

These figures reflect our WordPress development pricing for scoped AI service engagements. The $500 floor covers a focused REST API wrapper for a site with standard post types. The $2,000 ceiling reflects a custom-plugin implementation with audit logging, multi-role scoping, and 10 or more tools. Enterprise scope with custom compliance requirements is quoted separately.

What Comes After the Build

A working MCP server is infrastructure. The value compounds as you build on top of it.

Once the server is running, you can layer agent workflows on top without touching the MCP server again. A new content type to process in bulk? Point list_posts at it. A new SEO rule? Write the evaluation logic in the agent prompt. The separation of concerns is the point: WordPress holds the content, the MCP server defines the typed surface, the agent implements the logic.

The Right Time to Build This

Teams that move on this in 2026 will have working AI content infrastructure when competitors are still evaluating which tools to use. The protocol is stable. The client ecosystem is growing. WordPress is not going anywhere.

The infrastructure connecting WordPress to AI agents is the gap worth closing now. If you want a custom MCP server for your WordPress site, built with proper security scoping and the tools your content team will actually use, tell us what you're working with. We scope and build these as part of our 2026 AI service line.