Self-hosted vs hosted WordPress MCP: which should you choose?
What is the difference between self-hosted and hosted WordPress MCP?
A self-hosted WordPress MCP server runs the endpoint inside your own WordPress install, so your AI client talks straight to your server; a hosted model puts that endpoint on infrastructure you do not operate — a managed platform or a relay service — that sits between the client and your site. The dividing line is where the MCP server lives and who is in the data path.
In practice, four architectures sit on the spectrum from fully self-hosted to fully hosted. A native endpoint serves MCP over Streamable HTTP from your own PHP — Cowboy MCP, plus others like IATO MCP (opens in new tab) and Royal MCP (opens in new tab). A local-proxy setup pairs a plugin with a Node.js process on your own machine — the official WordPress mcp-adapter (opens in new tab) with the mcp-wordpress-remote proxy (opens in new tab). A hosted relay keeps the plugin on your site but routes traffic through the vendor's cloud — WPVibe (opens in new tab). A hosted platform builds MCP into managed hosting with no plugin for you to manage — WordPress.com (opens in new tab) and InstaWP (opens in new tab).
Where does your data go in each model?
The data path is the ordered list of systems a request crosses between your AI assistant and your database, and every extra system on it is another party that can see, log, or be compelled to produce your traffic. A native endpoint is two nodes: your client and your server. A local proxy adds a hop, but on hardware you own. A relay or platform adds a party you do not operate at all.
That difference is architectural, not a verdict. With a native self-hosted endpoint the request goes from your AI client straight to your server, so credentials and content never leave your infrastructure. With the WPVibe relay (opens in new tab) the client connects to the vendor's cloud, which proxies authenticated calls to your site — the vendor documents that WordPress credentials are encrypted at rest and stored on its Cloudflare-hosted servers. With a hosted platform such as WordPress.com (opens in new tab), the endpoint is the platform. When traffic transits systems someone else runs, that fact matters under GDPR, client contracts, and internal policy — the reasoning is set out on the security page.
Do you need Node.js or a proxy process?
Whether you need a separate process depends on the architecture, and only one class requires it. A native self-hosted endpoint needs nothing extra: WordPress already answers HTTPS, so the plugin serves MCP over the site's existing web stack with no separate process. A local-proxy setup is the exception — it runs a background program beside your AI client, and a relay or platform moves that work off your machine entirely and onto the vendor's.
The official mcp-adapter (opens in new tab) illustrates the nuance. The adapter itself implements HTTP transport natively on your server, but its documented path for many clients is the mcp-wordpress-remote proxy (opens in new tab) — a local Node.js process (Node.js 22 or newer) that translates the client's stdio messages into HTTP requests to your site. Cowboy MCP takes the native route: the endpoint is built into the plugin, so there is no proxy to install, no JSON config to edit, and no terminal step for the standard browser sign-in, as the WordPress MCP guide walks through.
What does each model cost and depend on?
What each model costs depends on where its work runs. Native self-hosted plugins are frequently free and open source — Cowboy MCP, IATO MCP (opens in new tab), and Royal MCP (opens in new tab) all ship free and open source with no paid tier — but you depend on your own host for uptime, TLS, and updates, which WordPress hosting already provides.
Hosted and relay models trade money or limits for that convenience. WordPress.com's built-in MCP server is available on its paid plans (opens in new tab), so it depends on an active subscription. The WPVibe relay (opens in new tab) is freemium — a free tier meters a daily allowance of WordPress actions — and depends on the vendor's cloud staying online, since your client reaches your site through it. The local-proxy path is free to run but depends on you keeping a Node.js process installed and current.
How do the four architectures compare?
The table lines up all four models against the attributes that actually differ: where the server runs, the transport, authentication, whether a proxy is required, the data path, host compatibility, dev-site support, and price. Representative products for each class are listed beneath it, each linked to its own documentation so you can verify the claims.
Last verified: July 2026.
| Attribute | Self-hosted (native endpoint) | Self-hosted + local proxy | Hosted relay | Hosted platform |
|---|---|---|---|---|
| Where the server runs | Your own server, inside WordPress/PHP | Your server, plus a Node.js proxy on your machine | Your server, reached through the vendor's cloud | The managed platform, which is also your host |
| Transport | Streamable HTTP | stdio locally, then HTTP to your site | HTTPS to the relay, then REST to your site | Streamable HTTP (WordPress.com); InstaWP serves SSE (docs (opens in new tab)) |
| Authentication | API key or bearer token, or a native OAuth connector | Application password, JWT, or OAuth via the proxy | One-click authorization via WordPress application passwords; credentials stored on vendor servers | OAuth 2.1 (WordPress.com); InstaWP uses a tokenized URL (docs (opens in new tab)) |
| Node.js / proxy needed | No | Yes — Node.js 22 or newer | No local process; a hosted relay sits in the path | No |
| Data path | Client to your server | Client to local proxy to your server | Client to vendor relay to your server | Client to the platform |
| Works with any WP host? | Yes, any self-hosted site | Yes, any self-hosted site | Yes, any site the relay can reach | No — that platform only |
| Offline / dev-site support | Yes | Yes — ideal for local development | No — the relay needs a reachable URL | No |
| Price model | Often free and open source | Free and open source | Freemium, with a usage allowance | Paid hosting plan |
Representative implementations: native — Cowboy MCP, IATO MCP (opens in new tab), Royal MCP (opens in new tab); local proxy — WordPress mcp-adapter (opens in new tab) with mcp-wordpress-remote (opens in new tab); hosted relay — WPVibe (opens in new tab); hosted platform — WordPress.com (opens in new tab) and InstaWP (opens in new tab).
When is hosted the better choice?
Hosted wins when you would rather not run or maintain anything yourself. A managed platform handles uptime, TLS, and updates, there is no plugin to install or keep current, and the MCP server is wired into the platform's own tooling. If your site already lives on WordPress.com, its built-in server on a paid plan (opens in new tab) is the shortest path — a single OAuth 2.1 sign-in with no key to copy and no endpoint to expose.
A hosted relay hits a similar note for self-hosted sites: one-click authorization, credential handling and token rotation managed for you, and no need to configure a public endpoint or run a local process. If you manage many client sites and want a uniform, zero-install connection flow, that convenience is real. The honest tradeoff is dependency — a paid plan or a vendor's cloud becomes part of your critical path, and a third party joins your data path — but for teams that value managed convenience over end-to-end control, hosted is a legitimate, sometimes better, pick.
When is self-hosted the better choice?
Self-hosted wins when control and privacy matter more than offloading operations. A native self-hosted endpoint keeps every request between your AI client and your own server, so credentials and content never transit a party you do not operate. It runs on any host — production, staging, or a local development site with no public URL — because nothing has to reach in from outside. And free, GPL-licensed plugins carry no per-seat fee or metered action cap.
Self-hosted also gives you the deepest reach into the site. Cowboy MCP exposes 137 tools across content, WooCommerce, security, and maintenance, all behind guardrails built for letting an agent act on a live site — safe mode, dry runs, a per-change undo journal, and database checkpoints, detailed on the security page. The native route does this without a Node.js proxy or a relay in the path. If you answer to GDPR or client contracts, cannot move to a specific managed platform, or simply want the audit trail to stay on your server, self-hosted is the stronger fit — and the WordPress MCP guide covers setup end to end.
FAQ
Is a relay less private than a direct connection?
It adds a third party to the data path, which is a trust and compliance consideration rather than an automatic exploit. Your requests, and often your stored credentials, pass through infrastructure the vendor operates before reaching your site, so you rely on that vendor's security and are subject to where it processes data. A reputable relay may encrypt credentials at rest, as WPVibe documents. A native self-hosted endpoint removes the third party entirely: the only systems in the path are your AI client and your own server.
Can I switch between self-hosted and hosted models later?
Yes. MCP is an open standard and clients connect over Streamable HTTP, so moving between models is mostly a matter of changing the endpoint URL and re-authenticating. Your content lives in WordPress either way, so you can start on a hosted platform or relay and later install a self-hosted plugin, or the reverse, without migrating your data. The main things that change are the connection URL and the authentication method your client uses.
Does self-hosted mean a harder setup?
Not necessarily. A native self-hosted plugin can be a directory install plus a browser sign-in or a pasted API key, with no Node.js and no config file to edit. The harder self-hosted route is the local-proxy path, which needs a Node.js process running beside your AI client. Hosted platforms are the simplest to connect but limit you to that platform, so simplest setup and most control point in opposite directions.