WordPress MCP setup guide: official MCP Adapter vs WP-MCP vs Site Agent vs hosted servers

WordPress MCP setup is mostly a question of which server you put between your AI client and the site, because that server decides what the client is allowed to do. If the endpoint or the authentication is wrong, the client connects fine but the tool you wanted is missing, or every write comes back as a permission error. For developer work on a self-hosted site, I’d start with Site Agent, because its content and code tools run inside WordPress and you control their access from wp-admin.

WP-MCP should be used when the REST API already covers your task and you’d rather not install another plugin on the site. The official MCP Adapter on its own is for developers who register their own abilities and want to expose exactly those, and a hosted connector is for someone who wants browser sign-in and a managed setup instead of pasting credentials into a config file.

I built Site Agent and WP-MCP, and you should keep that in mind when you read my preference. Site Agent is a free WordPress plugin that packages site-management tools around the official MCP Adapter. WP-MCP is a Node.js server that runs on your own computer and turns WordPress REST API operations into MCP tools. These overlap on content work but their setup and their permissions are different.

Quick Comparison

You should choose the server by the task in front of you and by how much access you’re prepared to hand over. A connection that succeeds only proves the client and the server can talk. The server still has to offer the operation you want, and on the official adapter that depends on what the plugins on your site have registered.

Tool	Where It Runs	Authentication	Main Capability	Important Limit
Official MCP Adapter	Inside WordPress; HTTP or local WP-CLI/STDIO	Application Password for HTTP; selected WordPress user for local STDIO	Exposes registered WordPress abilities	Useful abilities must already exist and be exposed. OAuth needs additional server support.
WP-MCP	External Node.js process, usually local	WordPress Application Password	Core REST operations and discovery of plugin REST routes	Available routes and user permissions limit access. Published-post updates take effect immediately.
Site Agent	Directly inside WordPress	Application Password, in a header or an authenticated URL	Content and media tools, hash checks, access controls and optional developer tools	Administrator required, including for reads. Tool-group and per-password limits apply; no built-in OAuth.
Novamira	Directly inside WordPress	OAuth or Application Password	PHP execution and developer file operations through abilities	Administrator required. Its PHP sandbox is not a security boundary or a rollback of database changes.
WordPress.com / Jetpack	Hosted WordPress.com server	Browser OAuth	Managed content, media and supported site operations across eligible sites	Eligible WordPress.com sites or qualifying Jetpack subscriptions required. Tools depend on plan, role and settings.
WPVibe	Hosted relay to your existing WordPress host	WPVibe sign-in and WordPress authorization	REST operations, builder skills and managed approval workflows	Requests pass through its relay. Deeper features need its plugin; usage has daily limits.
InstaMCP	Managed integration for sites hosted on InstaWP	Token in the generated site URL	Structured content and site tools, with optional power tools	Tied to InstaWP hosting. The URL is a credential; power tools require separate enablement.

Site Agent runs on the official adapter under the hood, so picking it means picking its tool library and its access switches rather than a different protocol. If your own plugin already registers the abilities you need, the standalone adapter is enough.

How WordPress MCP Works

The troubleshooting section at the end leans on one idea, so I want to settle it before the setup steps. MCP stands for Model Context Protocol. It is the standard an AI client uses to ask a server which tools it has and to call them with structured inputs. The protocol is the same everywhere, and the server you install decides which site operations those tools can perform. That is why the options in this guide behave differently from each other.

There are broadly three ways to connect:

• A local server such as WP-MCP receives MCP calls from your client, then calls the site’s REST API over HTTPS.
• A site-side server such as Site Agent receives authenticated MCP requests inside WordPress and executes its registered operations there.
• A hosted connector receives requests through a provider-managed service and connects to an eligible WordPress site or account.

The WordPress Abilities API is a registry of named operations, each with its input schema and its own permission check, and the official adapter is what publishes the eligible ones over MCP. A REST route and a WordPress ability are different things, and this is the first thing to check when a tool is missing. Registering a normal REST endpoint doesn’t give the official adapter a matching action, so a plugin can have a complete REST API and still show up with nothing to call.

WP-MCP goes the REST way, including reading plugin endpoint schemas to generate tools. Site Agent ships its own selected abilities on a private server of its own, so you shouldn’t expect its endpoint to expose every ability every plugin on the site has registered either.

There is also one naming trap worth clearing up. Older tutorials often mean Automattic’s archived wordpress-mcp plugin when they say “WordPress MCP.” That project is deprecated, it has nothing to do with my @wpgaurav/wp-mcp package, and its old /wp-json/wp/v2/wpmcp URLs shouldn’t be copied into a current official-adapter setup.

Set Up Site Agent

Site Agent is where I’d start when you want a coding agent to understand the WordPress installation and make scoped changes to it. You can begin with content reads alone and switch on developer access only when a task needs it.

The install requirements are:

• WordPress 6.9 or newer, which supplies the Abilities API.
• PHP 8.0 or newer.
• HTTPS for a remote connection.
• A WordPress administrator, or a super administrator on multisite. Site Agent requires this even for content-only access.
• An MCP client that can send an Authorization header over Streamable HTTP, or one that accepts a single server URL once you switch on URL authentication.

An Editor account is enough for some content-only REST workflows, but it cannot authenticate Site Agent’s tools at all. Its permission checks require administrator rights, and the way to narrow what a connection can do is to restrict its enabled tool groups rather than to use a lower role.

Install and Enable the Plugin

The Site Agent download includes the plugin and a free update license. Every feature works without activating the license, and the license only switches on automatic updates. A complete packaged plugin is also available in its GitHub release.

1. Upload the WordPress plugin ZIP through Plugins > Add New Plugin > Upload Plugin, then activate it. The companion ZIP is for a client integration, so ensure you’re uploading the plugin package.
2. Open Tools > Site Agent and enable access.
3. Leave Content writes and the developer groups off for the first connection.
4. Save the settings.

Read access lets the agent inspect the site and find content. The other groups each cover a separate job:

• Content writes, including draft creation and supported media operations.
• Source inspection, for reading plugin and theme files.
• Source editing, for changing executable files.
• PHP execution inside WordPress.
• Foreground WP-CLI commands on the server.

PHP and WP-CLI have broad privileges. It is wise to leave these off until you have a backed-up staging site and a concrete reason to use them.

Add the Connection

Create a dedicated Application Password under Users > Profile. The client authenticates with your WordPress login name and this new password, never with your normal account password.

Site Agent’s settings page has a small converter that runs in your browser and turns the login and Application Password into the Authorization value and a ready MCP configuration. For a compatible client, that configuration has this general shape:

{
  "mcpServers": {
    "site-agent": {
      "url": "https://example.com/wp-json/site-agent/v1/mcp",
      "headers": {
        "Authorization": "Basic BASE64_OF_USERNAME_COLON_APPLICATION_PASSWORD"
      }
    }
  }
}

The URL your own settings page shows is the one to use. The header placeholder stands for the Base64 encoding of username:application-password, and Base64 is reversible, so anyone who sees that value has the password. Your client may want a different configuration format, but the endpoint and the authentication header still have to match what Site Agent expects.

Some clients only take a URL. The connector screens in ChatGPT and Claude ask for one server address and give you nowhere to add a header, so Site Agent has a second route for them. Switch on URL authentication in Tools > Site Agent, use Copy authenticated endpoint in the converter, and the client gets the same credential as a query string:

https://example.com/wp-json/site-agent/v1/mcp?auth=BASE64_OF_USERNAME_COLON_APPLICATION_PASSWORD

This route is off by default for a reason. A URL ends up in browser history and in proxy logs, and the MCP authorization guidance discourages tokens in URLs, so give it a dedicated Application Password that you can revoke on its own and keep the header route for every client that can send one. Site Agent doesn’t include OAuth, so if your client requires OAuth sign-in you need a compatible bridge or one of the servers below that supports it.

Site Agent With ChatGPT Web

I have Site Agent working with ChatGPT Web on gauravtiwari.org. ChatGPT identified my WordPress installation and reported the content and developer tools available through the connection. That gives me a way to work on my site directly from a conversation in my browser, with access to the site’s content and the code behind it.

With the relevant tool groups enabled, you can ask ChatGPT to:

• Inspect the WordPress environment and discover the tools the connection can use.
• Find content across post types, including drafts and scheduled posts, then read its raw Gutenberg markup and current content hash.
• Create drafts or stage supported changes to published content as an autosave for review.
• Update supported SEO fields and publishing details. Direct saves can assign taxonomy terms or change the featured image; those fields aren’t part of an autosave.
• Import images into the Media Library and fix their alt text or other attachment details.
• Read plugin and theme source files, then create or change files inside allowed paths. Edits to existing files use hash checks to detect a newer version.
• Run PHP inside WordPress or execute WP-CLI commands when those developer groups are enabled.

A useful first task is to find the exact content you want to work on:

Find every published article mentioning WP Rocket. Return the URL and the
passages that mention it. Do not change any content or settings.

For developer work, you can begin with an inspection request:

Inspect GT Performance's installed plugin code for obvious issues.
Report the file paths and line references, explain the consequences,
and propose the smallest fix. Do not change any files.

The access in my connection comes from the groups I’ve enabled. You should give a content-only connection a narrower scope and keep PHP and WP-CLI off until you need them.

Limit and Test Access

The per-Application-Password controls let you narrow each connection to a subset of the groups you’ve enabled globally. A password the agent uses to prepare drafts, for example, can have Content writes on while its code-execution groups stay off.

Use Test connection in the settings, then ask your client:

Read the site context and list 5 recent posts. Report the site URL and the
available tools. Do not change any content or settings.

Site Agent’s content reader returns the stored block markup along with a SHA-256 hash of it, which is a fingerprint of the content at the time of the read. An update has to send that hash back, so if someone edited the post after the agent read it, the save fails instead of overwriting their work. That check isn’t a database transaction, though, and two callers can still read the same content before either one saves, so simultaneous edits still need care.

Its content-save behavior also matters for published posts:

• New content defaults to draft.
• An update to a published, private or scheduled post with status omitted stages supported fields as a WordPress autosave.
• That staging route supports title, content and excerpt. It doesn’t stage changes to taxonomy or SEO metadata.
• The primary content returned after staging is still the live post. Review the autosave through the WordPress editor before applying it.
• An explicit published-status save can change the live article. The plugin doesn’t make every write a draft.

Set Up the Official MCP Adapter

The official MCP Adapter on its own is the right route when your plugin or site already registers useful WordPress abilities. You keep the exposed operations small and every ability carries its own permission check, which is a cleaner access model than handing an agent a whole REST API.

Its released plugin requires WordPress 6.9 or newer and PHP 7.4 or newer. For a remote desktop connection through the local proxy, you also need a supported Node.js installation on the client machine.

Install the Adapter

Download the complete ZIP from the official MCP Adapter releases, then upload and activate it in WordPress the same way. The plugin isn’t in the WordPress.org directory yet and the trunk branch describes features that haven’t shipped, so the release ZIP is the route to trust.

If you already use WP-CLI, the documented equivalent is:

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

The default server endpoint is:

https://example.com/wp-json/mcp/mcp-adapter-default-server

The latest standalone release is 0.6.1. Site Agent bundles a pinned prerelease of the upcoming 0.7.0 runtime, so the two shouldn’t be treated as the same code when you compare behavior or read the docs.

Connect a Remote Site

For a client that launches local MCP processes, Automattic’s remote proxy can bridge that process to the HTTP adapter endpoint. Create an Application Password for a user whose capabilities match the abilities you intend to call, then configure:

{
  "mcpServers": {
    "wordpress-adapter": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "mcp-reader",
        "WP_API_PASSWORD": "REPLACE_WITH_APPLICATION_PASSWORD",
        "OAUTH_ENABLED": "false"
      }
    }
  }
}

WP_API_URL needs the full adapter endpoint. If you give this proxy a bare domain, it can wander off toward the deprecated plugin’s old route. OAUTH_ENABLED is false here because the example uses an Application Password, and switching it on doesn’t install an OAuth server in WordPress, so it stays off unless the server you’re talking to already has one.

For a WordPress installation on the same machine, the adapter also offers a WP-CLI STDIO connection. That route needs the local installation path and a deliberately chosen --user, because WP-CLI otherwise runs with no user at all.

Discover the Available Abilities

The default server exposes 3 MCP tools:

• mcp-adapter-discover-abilities finds the exposed abilities.
• mcp-adapter-get-ability-info provides an ability’s schema and description.
• mcp-adapter-execute-ability runs it with the supplied arguments.

So your client will see these 3 tools, and not a separate top-level tool for every plugin operation. The working pattern is to discover an ability, read its schema, then execute it with the arguments that schema asks for.

When the action you need is missing, check the ability itself:

• The plugin must register it through the Abilities API.
• Its registration must include a valid category and the required schemas.
• It must opt into MCP exposure, or be selected by the custom server you’re using.
• Its permission callback must allow the connected WordPress user.

The ability-registration guide explains those requirements. Reinstalling the adapter won’t create an ability that the plugin never registered.

Set Up WP-MCP

WP-MCP should be used when the REST API already exposes your task and you don’t want to add anything to the site. A Node.js process on your own computer handles the MCP side and sends authenticated REST requests to WordPress, so the site sees nothing but ordinary REST calls.

I’d keep its default STDIO transport for a desktop or coding client that can launch a subprocess. The client starts the server when it needs it and stops it when it’s done, so there is no separate MCP listener sitting on a port for you to secure.

The computer running your client needs a supported Node.js installation with npm and npx. After creating an Application Password, add this configuration to a client that supports local MCP servers:

{
  "mcpServers": {
    "wp-mcp": {
      "command": "npx",
      "args": ["-y", "@wpgaurav/wp-mcp@0.1.8"],
      "env": {
        "WP_URL": "https://example.com",
        "WP_USERNAME": "mcp-user",
        "WP_APP_PASSWORD": "REPLACE_WITH_APPLICATION_PASSWORD",
        "WP_MCP_TRANSPORT": "stdio",
        "WP_MCP_DISCOVER": "false"
      }
    }
  }
}

This example pins the current package version and switches plugin discovery off for the first connection. The configuration source expects WP_URL to be the bare site root, the opposite of the official proxy’s full-endpoint WP_API_URL, and swapping the two is an easy mistake to make.

Once a read works, you can turn discovery on if you need plugin routes. The boundaries that matter are:

• Discovery generates tools from REST schemas. A generated tool still depends on that route’s permissions and payload requirements.
• Turning discovery off reduces the tool catalog. It doesn’t disable the core write or delete operations.
• An Application Password inherits its user’s WordPress capabilities. It isn’t an independently read-only token.
• WP-MCP sends the credential to WordPress over HTTPS. Your local configuration must stay private, and it shouldn’t be committed to a repository.
• Updates to existing posts go through REST immediately. A published post can change publicly, and WP-MCP doesn’t have Site Agent’s hash-and-autosave workflow.

The WP-MCP HTTP implementation also gives you a local HTTP connection for a client that can’t launch a subprocess. That listener defaults to 127.0.0.1 and has no incoming authentication of its own in the current code, so it should stay on your machine and never go out through a public tunnel.

For a plugin-specific example, the GT Link Manager API guide documents the link-management endpoints. You should read the endpoint schema and its permissions before enabling discovered operations that can change links.

Hosted WordPress MCP Servers

A hosted server removes some of the setup work, and in exchange the provider’s tool catalog and access rules become part of your workflow. You should also keep two kinds apart here: a relay that reaches your site on whichever host you already use, such as WPVibe, and an integration that only exists on one hosting platform, such as InstaMCP.

WordPress.com

WordPress.com MCP is a hosted, account-wide endpoint with browser OAuth sign-in. Its documented eligibility covers:

• Paid WordPress.com plans.
• New free sites during their first 30 days.
• Eligible self-hosted sites connected through Jetpack AI or Jetpack Complete.

The endpoint is:

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

To set it up:

1. Open your WordPress.com account’s Preferences > AI and MCP.
2. Enable the intended sites and read tools. The account-wide switch enables read and write groups by default, so adjust those before testing.
3. Add the hosted endpoint through your client’s remote MCP connection settings.
4. Complete the browser authorization and request site information.

The WordPress.com access controls let you restrict the connection by account and by site. One connection can reach every eligible site on the account, so you should name the target site in every task. Its managed content tools can create drafts and do other supported writes, and a hosted connection should never be assumed to be read-only.

WPVibe

WPVibe is a hosted relay for sites on your existing WordPress host. Its connection guide uses https://mcp.wpvibe.ai/mcp, a WPVibe sign-in and a WordPress authorization step.

Its setup has two levels:

• Core REST operations can work without the WPVibe plugin.
• Its free plugin adds file access, theme-draft operations and other deeper site features.

WPVibe is a bigger managed workflow than a small REST wrapper, with documented builder skills and approval gates. Its security model runs everything under the connected WordPress user’s capabilities, and its WP-CLI-style operations are allowlisted commands emulated in PHP rather than an unrestricted shell on the server.

Every tool request and result passes through the hosted relay. Its plans include a free daily call allowance with paid tiers above it, which matters if your work is made up of many small operations.

InstaMCP

InstaMCP is the managed option for a WordPress site hosted on InstaWP. Its setup guide describes enabling MCP in the site’s details and adding the generated site endpoint to your client.

The connection has these boundaries:

• MCP is included in supported InstaWP hosting plans.
• The generated URL contains a token and must be treated as a credential.
• The token’s scope and the WordPress role limit the operations.
• Power tools require separate enablement.
• InstaWP manages the site integration, including its plugin installation, so there’s no manual local bridge to maintain.

This hosted integration is separate from InstaWP’s open-source Node.js MCP package. Hosting is the deciding condition here, and I wouldn’t move an otherwise happy site to a new host just to get an MCP endpoint.

Site Agent vs Novamira and WPVibe

Novamira and WPVibe are the two I’d put next to Site Agent, because all three go past reading posts and let an agent touch files and code on the site. What separates them is the exact operations each one offers and the controls around those operations.

Novamira is a direct site-side developer plugin built around WordPress abilities and the official adapter. Its connection options include OAuth as well as Application Passwords, which can make it the better fit for a client that needs browser authorization.

Its security guidance also puts the developer-access boundary plainly:

• Abilities require administrator-level manage_options access and explicit enablement.
• PHP execution can act outside the narrower file-tool restrictions.
• Its PHP sandbox helps manage files and recover from some fatal errors. It isn’t a security boundary or a rollback of database changes.
• Staging and backups remain necessary for broad code execution.

Site Agent gives you named content operations with raw block access and the hash check described above. Its source-file implementation keeps the file tools inside approved plugin and theme paths and checks the expected hash before every write. PHP and WP-CLI can still reach well beyond those paths, so the file limits don’t contain all of the developer access, and the switches for those two groups are the ones to be careful with.

WPVibe’s documented feature set includes builder-specific skills and a managed approval workflow. Site Agent doesn’t promise those builder integrations just because it can read a file or run PHP.

My preference is Site Agent for direct work on a self-hosted WordPress installation where I want the controls in wp-admin. Novamira’s OAuth can decide the choice if your client requires OAuth sign-in. WPVibe suits someone who wants the relay and the managed workflow across many sites more than they want another plugin to maintain.

Verify Your WordPress MCP Setup

Before an agent gets any write access, I want its first successful request to confirm which site it is talking to and which operations it can see, and only then try a draft. The sequence below works on every server in this guide, even though the tool names differ from one to the next.

1. Read site information and confirm the exact URL and environment.
2. List a small set of existing posts.
3. Read 1 post’s stored content. Confirm that Gutenberg comments, shortcodes and block attributes are present where the task requires raw editing.
4. Ask the client to create 1 clearly named test post with status set to draft.
5. Read that draft back and confirm its ID, status and stored content.
6. Inspect the draft in WordPress before granting broader operations.

A useful draft test is:

Create a post titled "MCP connection test" with status "draft" and 1 plain
paragraph. Return its ID. Read it back and confirm the stored status and content.
Do not publish it or modify an existing post.

For real editing, what happens on the WordPress side of the save matters as much as the connection. WordPress can filter submitted HTML on the way in, and a server that can save plain text has proven nothing about your ACF blocks or your page builder’s markup. You should send the stored structure back the way you read it and check the result after every save.

Site Agent’s content operation preserves any field you leave out, but broad PHP or WP-CLI access can go around that workflow. Backups and a clear approval boundary still matter whenever a task can change executable code or live content.

Fix Common Connection Problems

Connection failures usually fall into authentication, endpoint or capability problems. The status code usually tells you which layer rejected the request, so start there.

Symptom	What to Check
401 or authentication failure	Login name, Application Password, Authorization header and whether a proxy strips that header
403 or permission denial	WordPress user capabilities, enabled tool groups and Site Agent’s per-password limits
404 or an HTML response	Exact MCP route, plugin activation, REST routing and any redirect to a login page
Adapter connects but an action is missing	Ability registration, exposure metadata and its permission callback
A raw HTTP call fails while the client works	MCP initialization, protocol headers and session handling; a bare browser visit isn’t a valid MCP test
Tools remain visible after permissions change	The client’s cached catalog; reconnect and inspect the current tools
A saved post loses markup	Raw block serialization, the WordPress save filters and the specific block or builder schema

For Site Agent, the connection test on the settings page checks initialization and tool listing in one go. For the other servers, the MCP client should do the handshake first, before you call a missing ability a network problem.

MCP is one piece of a larger change in WordPress, and the AI in WordPress guide covers the Abilities API and the rest of what core now ships for AI. The safe order is to start with the connection that fits your client, confirm a read, save 1 verified draft on staging and switch on more access only when the next task needs it.

Disclaimer: This site is reader-supported. If you buy through some links, I may earn a small commission at no extra cost to you. I only recommend tools I trust and would use myself. Your support helps keep gauravtiwari.org free and focused on real-world advice. Thanks. - Gaurav Tiwari