Local WordPress MCP: connecting an AI agent to a development site

Does WordPress MCP work on a local site?

Yes, and for most developers a local site is the best place to start. A WordPress site running on your own computer — in Local, Studio, MAMP, DevKinsta, wp-env or Docker — becomes an MCP server the moment Cowboy MCP is activated, and any AI tool that runs on the same machine can connect to it with no public URL, no tunnel and no API key to copy. The endpoint is an ordinary WordPress REST route at /wp-json/cowboy-mcp/v1/endpoint, and on localhost that route is reachable by every program on your computer.

The only thing that changes between a local site and a live one is which AI apps can reach it. Tools that run on your machine — Claude Code, Cursor, VS Code, Codex, the Gemini CLI, Opencode, a self-hosted n8n — connect directly. Apps that run in a vendor's cloud — claude.ai, ChatGPT, Perplexity, Grok, the Gemini app, n8n Cloud — connect from the vendor's servers and therefore need a public HTTPS address they can see. Claude Desktop sits in between: it is a desktop app, but its connectors are cloud-side, so a local site reaches it through a small bridge described below. The connect hub lists every app compared, including which ones work locally.

Which AI tools connect to a local WordPress site?

The rule is simple: if the AI tool runs on your computer, it can talk to a site on your computer. Those tools sign in through the same one-click browser sign-in a live site uses — the Connections tab opens a consent page in your browser, you click Approve, and the tool holds a token. An API key works too, for scripts and headless use.

Tool	Reaches a local site?	How it connects
Claude Code	Yes	Two commands shown on the Connections tab; sign in in your browser
Cursor	Yes	"Add to Cursor" button; sign in in your browser
VS Code (GitHub Copilot)	Yes	"Install in VS Code" button; sign in in your browser
Codex CLI	Yes	One codex mcp add command; sign in in your browser
Gemini CLI	Yes	One gemini mcp add command, then /mcp auth
Opencode, Windsurf, Cline, Zed	Yes	One config block with the endpoint URL (Opencode signs in with OAuth; the others take an API key)
Claude Desktop	Yes, through a bridge	The mcp-remote helper runs on your computer and opens the same sign-in
n8n (self-hosted on this machine)	Yes	MCP Client Tool node with a Bearer key or OAuth2
claude.ai, ChatGPT, Perplexity, Grok, Gemini app, n8n Cloud	No	They connect from the vendor's cloud and need a public HTTPS site

The Connections tab in Settings → Cowboy MCP detects that a site is local and adjusts what it shows: the cloud-app buttons carry a note that they cannot reach the site, the terminal and editor panels show their commands as usual, and the Claude Desktop panel switches to the bridge configuration.

How does Claude Desktop reach a local site?

Claude Desktop's connectors are remote MCP servers that Anthropic's cloud signs in to, so a site on mysite.local is invisible to them. Claude Desktop can, however, start a local program and talk to it over standard input and output, and that is what the bridge does. The bridge is the open-source mcp-remote package, started on demand with npx: it runs on your computer, forwards Claude Desktop's requests to your local endpoint, and opens the same one-click sign-in page in your browser, so nothing is exposed to the internet and no tunnel is needed.

The Connections tab writes the ready-to-copy claude_desktop_config.json snippet for you when it detects a local site. Two details worth knowing: local sites usually run on a self-signed certificate that AI tools reject, so if the bridge reports a certificate error, use the plain http:// address the Connections tab offers — the connection never leaves your computer, so nothing is sent in the clear over a network. And if you want headless use rather than browser sign-in, the same snippet accepts an API key through an environment variable. The Claude Desktop guide walks through the bridge step by step.

Do I need ngrok or a tunnel?

Not for the tools above. A tunnel exists to give a cloud app a public address for a site that has none, and the terminal, editor and bridge paths never need one. Use a tunnel only when you specifically want claude.ai, ChatGPT, Perplexity, Grok or the Gemini app to work on a development copy — and treat it as a temporary test, because while the tunnel runs your whole dev site is reachable from the internet, not just the MCP endpoint.

If you do open a tunnel, the plugin's guardrails still apply: safe mode is on, every connection needs the one-click approval you grant in wp-admin, and the "New connections" window on the Connections tab closes itself after 30 minutes so a cloud app cannot register later without you. Close the tunnel when the test is done. For day-to-day work on a local site, the terminal and editor tools are the better fit anyway — they sit next to the code you are editing and the error log you are reading.

Why connect an AI agent to a local site first?

Three reasons, in order of how often they matter.

1. Rehearse before production. A local copy is where an agent can run a risky task — a bulk price change, a search-and-replace across every post, a plugin update across a dozen plugins — and you can watch exactly which tools it calls and what each one changes. When the plan is right, run the same prompt on the live site with a database checkpoint taken first; Cowboy MCP takes one automatically before plugin and theme updates and mutating WP-CLI commands.
2. Write and fix code safely. Local is where vibe coding a WordPress site belongs: the agent can edit theme and plugin files in wp-content, run WP-CLI, read the PHP error log and fix what it broke, and every PHP file is syntax-checked before it lands. A fatal on a local site costs you a reload; on production it costs you visitors.
3. Build the agent's muscle memory. Skills, prompts and checklists you develop on a local site — the kind on the agent skills page — transfer to production unchanged, because the endpoint, the tools and the guardrails are the same. The only variable is the URL.

Each change the agent makes on a local site is journaled too, so the undo journal and the Activity tab work exactly as they do on a live site. That makes a local copy a good place to learn what undo covers and what it does not — a cache flush or an outbound HTTP request is recorded as not undoable rather than pretended otherwise — before you rely on it where it counts.

How do I set it up?

1. Install the plugin on the local site. In the local site's wp-admin, go to Plugins → Add New, search for "Cowboy MCP", and click Install then Activate. It is free on the WordPress.org plugin directory (opens in new tab) and needs WordPress 6.2+ and PHP 8.0+. If the site's REST API is reachable in a browser at /wp-json/, the endpoint is reachable too.
2. Pick a tool that runs on your computer. Open Settings → Cowboy MCP → Connections, choose Claude Code, Cursor, VS Code, Codex or the Gemini CLI, and run the command or click the button it shows. Your browser opens the consent page on the local site; choose full, read-only or custom access and click Approve. For Claude Desktop, copy the bridge snippet instead.
3. Ask for something read-only first. "List the ten most recent posts and their status" proves the connection without changing anything. Then try a write with a dry run, and look at the Activity tab to see how the undo journal records it.

FAQ