The Model Context Protocol (MCP) is an open standard from Anthropic that lets an AI assistant like Claude connect directly to external tools and data sources instead of just generating text you copy and paste. For WordPress, that means Claude can create posts, manage media, update navigation, and handle routine site operations through conversation rather than manual clicks in wp-admin. Below is a practical overview of how the connection works, the common setup paths, and the plugins most people reach for.
How the connection actually works
At a high level, an MCP server sits between Claude and your WordPress site. It receives structured requests from Claude, translates them into WordPress REST API calls, handles authentication, and returns the results. When Claude “manages WordPress,” it’s really calling a defined set of tools that map to real actions: listing posts, updating pages, uploading media, editing navigation menus, and so on.
Common setup paths
There isn’t one official route — the ecosystem has grown a few distinct approaches, each with different tradeoffs.
- Dedicated MCP plugins — Plugins built specifically to expose an MCP endpoint from your site (often something like
/wp-json/your-plugin/v1/mcp). Install from the plugin directory or upload a zip, activate, generate an authentication token in the plugin’s settings, then add the server URL to Claude as a connector. - The WordPress MCP Adapter (Abilities API) — Built on WordPress 6.9’s Abilities API, this approach registers specific “abilities” (get site info, get posts, etc.) and exposes only what you explicitly allow. It’s more granular but requires a bit more configuration, including enabling core abilities and creating an Application Password for a dedicated user.
- Managed WordPress platforms — Some hosting platforms bundle MCP support directly into the dashboard, auto-installing the plugin, generating tokens, and standing up the connection in a couple of clicks. Convenient, but ties you to that platform’s infrastructure.
- Self-hosted Node.js MCP servers — For full control, some setups run an open-source MCP server locally or on your own infrastructure, connecting to WordPress via REST API and Application Passwords. More setup and maintenance, but no dependency on a third-party plugin’s servers.
Authentication methods you’ll run into
- Application Passwords — Built into WordPress core since 4.7+. Generated per-user under Users → Profile → Application Passwords, scoped to one connection, and revocable at any time without touching your main login credentials.
- OAuth 2.1 — A browser-based authorization flow; after the first approval, tokens refresh automatically. Generally the more secure, lower-maintenance option long-term.
- JWT tokens — Generated from the plugin’s settings screen and pasted into the client config directly. Simple, but tokens expire and need periodic regeneration.
Plugins worth knowing about
- A dedicated MCP/AI bridge plugin — whichever one matches your setup (self-hosted vs. WordPress.com, or a specific vendor’s implementation) — is the core requirement, since it’s what exposes the MCP endpoint in the first place.
- A REST-API-friendly security plugin configuration — if you run Wordfence, iThemes Security, or similar, make sure the
/wp-json/path isn’t blocked for authenticated requests, or the connection will fail with 403 errors before it ever reaches the MCP layer. - SEO plugins with API support (e.g., Yoast) — several MCP implementations can read and update SEO metadata directly, which is a nice bonus if your plugin’s MCP bridge supports it.
Practical setup checklist
- Confirm the REST API is reachable (visit
/wp-json/in a browser and check for a JSON response). - Install and activate the MCP-enabling plugin of your choice.
- Generate a scoped Application Password or token — ideally under a limited-permission user, not a superadmin account.
- Add the connection details to Claude as a connector.
- Test with a simple, read-only request first (e.g., “list my recent posts”) before trying anything that writes to the site.
A few habits worth keeping
- Use role-scoped tokens. An editor-level token for content work, a separate token for anything touching plugins or settings.
- Set expiration dates on tokens where the plugin supports it, and rotate them periodically.
- Test on staging first for anything beyond simple content edits — especially plugin, theme, or settings changes.
- Default to drafts. Have Claude create and update content as drafts, then review before publishing, rather than letting changes go live automatically.
Once the connection is working, the real value shows up in the repetitive work it removes: batch-creating draft pages, reorganizing navigation, cleaning up media, or running a quick content review across dozens of posts — all without the usual click-and-load cycle of the WordPress admin.
