# Cowboy MCP — full text for AI assistants > Cowboy MCP is a free, open-source WordPress plugin that turns your self-hosted WordPress site into an MCP (Model Context Protocol) server, so AI agents like Claude, ChatGPT, Gemini, Cursor, and Codex can manage the site in plain English — with per-change undo and database checkpoints. This file is the long-form companion to https://cowboymcp.com/llms.txt: the complete text of the pages that answer most questions about Cowboy MCP, in reading order. Each section starts with its canonical URL; cite that URL, not this file. Regenerated on every build; facts are current as of the newest date shown below. Plugin version 1.7.3, 203 tools. --- Canonical URL: https://cowboymcp.com/wordpress-mcp Title: WordPress MCP Server Guide: Plugins, Setup, Safety (2026) Last updated: 2026-10-12 # WordPress MCP: the complete guide ## What is a WordPress MCP server? A WordPress MCP server is a plugin or service that exposes your WordPress site to AI assistants through the Model Context Protocol, an open standard for connecting AI to external tools. Once connected, an assistant like Claude or ChatGPT can act on the site — publish posts, update WooCommerce products, run backups — instead of just writing text for you to paste. The Model Context Protocol (MCP) was introduced by Anthropic in 2024 and is now an open specification implemented by clients from many vendors. An MCP server publishes a set of tools — discrete actions like "create a post" or "update a product price" — and an MCP client, the AI app you already use, discovers those tools and calls them with your approval. On WordPress, that server can take several forms: a plugin on a self-hosted site, a built-in feature of a hosted platform, or an adapter maintained by the WordPress project itself. This guide covers how the connection works, what an agent can actually do with it, every option available in 2026, and how to set one up safely. ## How does MCP work with WordPress? An AI assistant connects to your site as an MCP client, over a transport called Streamable HTTP — ordinary HTTPS requests to one endpoint URL. The server answers with a list of tools it offers, each described in plain language. When you ask for something, the assistant picks a tool, calls it with the details filled in, and reads the result — a loop it repeats until the job is done. Concretely, with Cowboy MCP the flow looks like this: - Your AI app sends a request to a single URL on your site — https://your-site.com/wp-json/cowboy-mcp/v1/endpoint. - The plugin describes its 203 tools: each has a name, a plain-language description, and a defined set of inputs. - The assistant chooses a tool and calls it. The plugin runs the action inside WordPress — with its permission checks and safety rails — and streams the result back. How is that different from the WordPress REST API? The REST API is the raw interface: it exposes the site's data over HTTP, but every integration has to be programmed against specific routes in advance. MCP sits one level higher — it is self-describing, so an assistant that has never seen your site can discover what's possible and act. The two are complementary rather than rivals: Cowboy MCP registers its MCP endpoint as a REST route, so MCP traffic travels over infrastructure WordPress already ships with. ## What can an AI agent actually do on a WordPress site? With Cowboy MCP, an agent gets 203 tools that cover the whole site, not just content. It can draft and schedule posts, update plugins and themes, manage users, edit WooCommerce products and orders, run Wordfence security scans, trigger backups, read error logs, and repair database tables — real administrative work, executed directly on the site rather than described to you. Area | Tools | Examples | Core WordPress and other integrations | 111 | Posts, pages, media, users, plugins, themes, settings, WP-CLI, error logs, database repair, caching, forms-plugin detection, SEO meta (Yoast SEO, Rank Math, All in One SEO, SEOPress), database checkpoints and undo | WooCommerce | 40 | Products, orders, refunds, coupons, stock, shipping zones, tax rates, sales reports | Wordfence | 17 | Security scans, firewall management, blocked IPs, live traffic | ACF | 9 | Field groups, custom fields, repeaters, options pages | Elementor | 7 | Templates, page builds, widget content | Beaver Builder | 7 | Page layouts with a node-by-node dry-run preview, modules and their settings, global settings | SiteOrigin Page Builder | 12 | Layouts edited whole or row by row, prebuilt layouts, widgets, Page Builder settings | Each integration lights up automatically when its plugin is active — there is nothing to configure. Three real prompts, to make it concrete: - "Turn last week's webinar notes into a blog post and schedule it for Tuesday morning." - "Put everything in the Summer collection 20% off through Friday and email me the week's revenue." - "Scan the site and block every IP that failed login more than ten times today." ## What are your options for a WordPress MCP server? You have five realistic options in 2026: the official WordPress mcp-adapter plugin, WordPress.com's built-in MCP server on its hosted plans, broad AI plugins such as AI Engine that include an MCP server, plugins that route MCP traffic through a hosted relay service, and self-hosted plugins that serve MCP natively from your own server. They differ mainly in where the endpoint runs and who sits between your site and your AI. Option | What it is | Where the endpoint runs | WordPress MCP Adapter (official) | Free, vendor-neutral adapter that bridges the WordPress core Abilities API to MCP — in the WordPress.org directory since October 2026; exposes the abilities a site registers and has no tools of its own | Your server | WordPress.com built-in MCP | MCP server included with WordPress.com's paid hosted plans — available only on that platform | WordPress.com | AI Engine (Meow Apps) | Broad AI plugin — chatbots, content generation, and more — that includes an MCP server among its features | Your server | Hosted-relay plugins | Plugins that pass MCP traffic through the vendor's hosted relay service between your AI client and your site | Your server, via a third-party relay | Cowboy MCP | Native, self-hosted MCP endpoint inside a free GPL-2.0 plugin — no Node.js proxy, no relay, no external service | Your server | All of these are legitimate choices. If you want to follow the direction WordPress core itself is heading, the official adapter is the neutral pick. If your site already lives on WordPress.com, the built-in server is the shortest path. If you want a chat-assistant suite that happens to include MCP, AI Engine covers far more than site management. Cowboy MCP's focus is narrower and deeper: one self-contained endpoint, 203 tools, and a safety layer built for letting an agent loose on a live site. It is free, open source, and built in the open — the about page has the maker and press facts. For a head-to-head look at any one of these, see Cowboy MCP compared against the alternatives. ## Self-hosted or hosted — which should you pick? Pick self-hosted if you want your content and credentials to stay on your own server: the AI client talks directly to your site, and no third party sees the traffic. Pick hosted if you're already on a platform that includes MCP and would rather not manage a plugin. The tradeoff is control and privacy on one side, convenience on the other. The privacy question is concrete, not abstract. With a hosted or relayed setup, your requests — and often your content — pass through infrastructure someone else operates, which matters if you answer to GDPR, client contracts, or your own policies. With a self-hosted endpoint, the credentials live on your server and the audit trail stays local. On the other side of the ledger, a hosted platform handles uptime, TLS, and updates for you — real work you no longer own. Cowboy MCP sits at the self-hosted end by design: the endpoint is native to the plugin, so there is no Node.js proxy running beside WordPress, no hosted relay in the path, and no external service involved. Requests go from your AI client straight to your server, and every call is logged there. ## Do you need Node.js or coding skills? No — not for the standard path. With Cowboy MCP you install the plugin from the WordPress directory, follow the guided setup in Settings → Cowboy MCP, and connect Claude, ChatGPT, Perplexity, Grok, the Gemini app, or the Codex app with one-click sign-in. There is no Node.js proxy to run, no JSON file to edit, no API key to copy, and no code to write. Terminal tools and code editors connect with one command or one button and the same one-click sign-in. The no-terminal path uses an OAuth connector: click Add to Claude or Open ChatGPT, or open Perplexity, Grok or the Gemini app from the Connections tab (or add your site as a custom connector in the Codex app), then click Approve on your own site's consent screen. You choose what the app may do before it can do anything, and you can revoke it later in one click. It requires a public HTTPS site. The terminal path is one command plus the same one-click sign-in, so there is no key to copy, store, or rotate. Settings → Cowboy MCP shows the exact command for your site. For Claude Code: claude mcp add --transport http your-site https://your-site.com/wp-json/cowboy-mcp/v1/endpoint claude mcp login your-site The second line opens your browser to approve the connection on your site; local development sites work too. Codex, Gemini CLI, and Opencode follow the same pattern, and Cursor and VS Code install with one button. n8n has its own panel with the MCP Client Tool fields ready to copy. For scripts and CI, or for editors like Windsurf, Cline, and Zed, generate an API key instead (it's shown once and stored only as a one-way hash) and send it as a Bearer header. The same endpoint URL works in anything that speaks MCP over Streamable HTTP. ## Is it safe to let an AI agent manage WordPress? It can be, if the server enforces guardrails rather than trusting the model. Cowboy MCP layers six: safe mode confirms destructive actions, dry runs preview any change before it happens, an audit log records every call, a per-change undo journal reverses individual edits, database checkpoints restore your site's database tables, and rate limits cap a runaway agent at 120 requests per minute. Each guardrail has a specific job: - Safe mode — on by default; destructive tools wait for your explicit confirmation before running. - Dry run — every write tool can report exactly what it would change without changing anything. - Audit log — every tool call, error, and authentication event is recorded, filterable in wp-admin, and auto-pruned after 30 days. - Undo journal — each change is captured individually, so one bad edit rolls back without touching the rest. - Database checkpoints — one-click snapshots restore your site's database tables, and auto-checkpoint runs before risky operations like plugin updates. - Rate limits and hashed keys — 120 requests per minute per key by default; keys are stored only as one-way hashes — the plain key can't be recovered from your database — and can be revoked individually. Beyond those six, the most powerful operations stay behind power mode, which is off until a human administrator enables it in wp-admin, and sensitive options and dangerous database or WP-CLI commands are blocklisted outright. The security page walks through the whole model — including what can go wrong and what each guardrail does not cover. ## How do you set one up? Three steps, about five minutes. Install a WordPress MCP plugin, register the endpoint in your AI client, and approve the connection. With Cowboy MCP the plugin's guided setup walks you through each client's exact flow, and the two walkthroughs below cover the most common pairings — Claude and ChatGPT — step by step. - Install the plugin. In wp-admin, go to Plugins → Add New, search for "Cowboy MCP", and click Install then Activate. It's free on the WordPress.org plugin directory and needs WordPress 6.2+ and PHP 8.0+. - Connect your AI. Open Settings → Cowboy MCP and follow the guided setup — a button or one command, then one-click sign-in, for apps and terminal tools alike. For the full walkthroughs, see how to connect WordPress to Claude or how to connect WordPress to ChatGPT. - Ask for something real. Start with a read-only request — "which plugins have updates pending?" — then let it act. Safe mode checks with you before anything destructive runs. If any term in this guide is unfamiliar, the glossary defines them all in plain English. ## FAQ **Is MCP an Anthropic-only technology?** No. Anthropic introduced the Model Context Protocol in 2024, but it is an open standard with a public specification, and clients from many vendors implement it — ChatGPT, Cursor, Gemini, Zed, and VS Code included. Any compliant client can talk to any MCP server, whoever built either side. **Does a WordPress MCP server work with ChatGPT?** Yes. ChatGPT connects to remote MCP servers as custom connectors, and the Codex terminal tool registers them directly. With Cowboy MCP installed, you add your site as a connector in ChatGPT — or register the endpoint in Codex — and manage the site by chat. **What's the difference between MCP and the WordPress REST API?** The REST API exposes your site's raw data, and every integration must be programmed against specific routes in advance. MCP adds a self-describing layer on top: the server explains each tool in plain language, so an AI assistant can discover and call the right action on its own. Cowboy MCP serves its MCP endpoint as a REST route, so the two work together. **Is a WordPress MCP plugin free?** Often, yes. The official mcp-adapter is free, and Cowboy MCP is free and open source under GPL-2.0 — all 203 tools, no paid tier. Some commercial plugins sell premium tiers, and WordPress.com's built-in server requires a paid hosted plan, so check the pricing model before you commit. **Do I need Cowboy MCP if I install the official MCP Adapter?** They are not exclusive. The adapter, in the WordPress.org directory since October 2026, is infrastructure that turns registered Abilities into MCP calls and has no tools of its own, and the core content Abilities arriving in WordPress 7.2 cover posts and pages rather than WooCommerce, files, the database, plugins, or undo. If you want a working toolset with undo, install Cowboy MCP; with the adapter installed too, Cowboy's tools show up through it, since version 1.6.4 registers them as Abilities. --- Canonical URL: https://cowboymcp.com/security Title: Is It Safe to Let an AI Agent Manage Your WordPress Site? Last updated: 2026-10-13 # Is it safe to let an AI agent manage your WordPress site? ## What has to be true for it to be safe? Yes — provided the safety lives in the server, not in the model's good judgment. Letting an AI agent manage a WordPress site is safe when destructive actions require human confirmation, changes can be previewed and reversed, everything is recorded, and the most dangerous capabilities stay off until an administrator turns them on. Cowboy MCP is built on the assumption that the model will sometimes be wrong. This page takes the question seriously instead of using it as a setup for a pitch. It starts with what can actually go wrong, then walks through each guardrail — what it covers, how it works in the code, and just as importantly, what it does not cover. ## What can go wrong when an AI manages your site? The realistic failures are mundane, not cinematic. The agent misreads your intent and acts more broadly than you meant. You make a prompt mistake and the agent faithfully executes it at scale. An API key leaks and hands a stranger the same tools your agent has. Or a long session drifts and the agent edits the wrong thing. None of these need a vulnerability — just automation plus ambiguity. Each failure deserves its own weight. "Clean up the old posts" can mean three posts to you and thirty to the model. A bulk price update with a mistyped number is executed as faithfully as a correct one. A leaked key matters more here than with most plugins, because authenticated requests execute with administrator capabilities — that is what real site management requires. And an agent that reads untrusted content — comments, form submissions, scraped pages — can be nudged by instructions planted in that content, a risk shared by every AI agent, on WordPress or anywhere else. The guardrails below are designed around exactly these failures: confirmation and preview against misread intent, undo against mistakes that got through, hashed and revocable keys with rate limits against leaks, and a complete audit trail so nothing happens silently. ## How do safe mode and dry runs work? Safe mode is on by default: any tool flagged destructive — deletes, resets, bulk overwrites — refuses to run until the call is resent with an explicit confirm: true, and the refusal includes a preview of what would have happened. A dry run is available separately: every non-read-only tool accepts a dry_run parameter that reports the intended change without executing anything. Two honest limits. First, safe mode keys on each tool's destructive flag, so ordinary writes — creating a draft, updating a field — run without a confirmation prompt. That is deliberate: they are previewable, journaled, and most MCP clients ask you to approve every tool call on their side anyway. Second, for most tools the dry-run preview is a statement of intent — the tool, the target, and the exact parameters — not a simulated diff of the outcome. The plugin and theme install and update tools go further and resolve the real plan, including versions and download source, before you commit. WP-CLI gets its own gate: under safe mode, any command outside a short list of known-safe prefixes requires confirmation, whatever its destructive flag says. ## What gets logged, and can you audit it? Every tool call, error, and authentication event is written to an audit log in your own database — timestamp, which key made the call, the tool, its arguments, the result, and the client IP. You can filter it by tool, key, event, and date range on the Logs tab in wp-admin, and entries are pruned automatically after 30 days. Arguments are redacted before they are written: fields whose names look like passwords, tokens, or keys are masked, and bearer tokens are scrubbed out of free-text values. Failed authentication attempts are logged too, so a stranger probing your endpoint leaves a trail. The practical limit is retention — 30 days is the window, so if a dispute needs older history, export it before the prune. Everything stays on your server: the log lives in your database, and the only other copy is your server's own PHP error log, which is used if you opt into request logging or if a database write fails. ## Can you undo what the AI did? Usually — and the honest word is "usually". Every change made through a journaled tool is captured as a full before-state snapshot in an undo journal, so one bad edit rolls back from the Activity tab without touching anything else. For operations the journal cannot invert, one-click database checkpoints restore your site's database tables to an earlier point. The journal covers the changes agents actually make: posts and pages, options, files, terms, comments, media, users, plugin and theme switches, WooCommerce products, orders, and coupons, and ACF field values. Checkpoints back it up where the journal can't reach — one runs automatically before any mutating WP-CLI command and before plugin and theme updates, both on by default — and if that automatic checkpoint fails, the failure is written to the audit log but does not block the command. Updates also take a file backup and run a post-update health check that restores the previous version automatically if the site breaks. The limits, plainly: some actions have no inverse — a sent test email, a cache flush, an arbitrary WP-CLI command, a bulk stock update — and the journal records them as not-undoable rather than silently skipping them, so the ledger stays complete. Journal entries are kept for seven days by default. And checkpoints restore database tables, not your uploads or code files. ## How are API keys protected? A key is generated once, shown once, and stored only as a one-way hash — the plain key cannot be recovered from your database afterward, by you or by an attacker who dumps it. Each key can be revoked individually from the settings page, and requests are capped at 120 per minute per key by default, with a stricter per-IP throttle underneath. That per-IP throttle — 30 requests a minute — applies to every request including failed authentication, which bounds brute-force guessing. A truthful caveat from the code itself: the rate limiter is transient-based and approximate under heavy concurrency, so treat it as a brake on runaway agents, not a hard security boundary. The deeper truth is that a valid key acts with administrator capabilities inside the plugin's guardrails, so handle it like an admin password: give each client its own key — the Claude and ChatGPT guides show where — revoke on any suspicion, and read the audit log to see exactly what a key did. Who can hold a credential at all is the question 2026 put to every WordPress MCP plugin. Between August and September, four of them published authorization-bypass advisories with the same shape — a subscriber or a bearer-token holder reaching administrator tools because the tool handler never re-checked capabilities. Cowboy MCP has no role-based path into its endpoint: keys are issued only by an administrator in wp-admin, OAuth tokens exist only after an administrator approves a consent screen and are re-checked against that account on every request, and each call passes a per-credential scope check before the handler runs. The MCP plugin vulnerabilities guide lists the advisories, explains the pattern, and gives a checklist for vetting any plugin for it. ## What stays locked unless a human opens it? The most dangerous capabilities are off until an administrator opts in. Without power mode, the plugin blocks schema-destroying SQL (DROP, TRUNCATE, ALTER), refuses eval, shell, and database-reset commands in WP-CLI, confines file writes to wp-content, syntax-checks every PHP file before it is written and keeps mu-plugins (which recovery mode cannot pause) closed, protects critical options like the site URL and user roles from writes, and rejects outbound requests to private and internal network addresses. Power mode is a checkbox in wp-admin, and it cannot be switched on through the API — the plugin's own settings sit on a list of options that are never writable via MCP, so an agent cannot grant itself more power. Even with power mode on, some lines never move: the plugin's API keys and settings stay locked, queries touching password and session data are refused, credential fields stay redacted in logs and output, the last administrator account cannot be deleted, and safe-mode confirmation is unaffected. ## Why does self-hosted matter for privacy? Because the endpoint runs inside your own WordPress install, there is no relay in the path and no vendor database holding your credentials. Your AI client talks directly to your server, keys live there as hashes, and the audit trail stays local. The plugin sends no telemetry and phones home to no one. The only outbound connections are to WordPress.org, when your agent installs or updates plugins and themes, plus any HTTP requests you explicitly ask for — and those are validated first: http and https only, with private, loopback, and cloud-metadata addresses rejected. The contrast with relayed setups is factual, not rhetorical: when MCP traffic passes through hosted infrastructure, your requests and content transit systems someone else operates, which matters under GDPR and client contracts. The WordPress MCP guide compares the architectures in full, and self-hosted vs. hosted WordPress MCP lays out the tradeoff attribute by attribute. ## FAQ **Can an AI agent break my WordPress site?** It can make wrong changes — the design assumes it will. What it cannot easily do is break things irreversibly: destructive tools wait for your confirmation, schema-destroying SQL and database-reset commands are blocked unless an administrator enables power mode, every PHP file is syntax-checked before it is written and mu-plugins stays closed without power mode, journaled changes roll back individually, and database checkpoints restore your site's database tables. The realistic bad case is a wrong edit you undo, not a lost site. **What happens if my API key leaks?** Revoke it on the Connections tab in Settings → Cowboy MCP — revocation is per key and takes effect immediately. Until then, whoever holds it can call the same tools your agent can, at administrator level and within the same guardrails, so treat keys like admin passwords: one per client, never in shared documents. The audit log shows every call the key made, and the stored one-way hash means the key itself cannot be read out of your database. **Does safe mode ask before every change?** No — only for tools flagged destructive, like deletes and resets, and for WP-CLI commands outside a list of known-safe prefixes. Ordinary writes, such as creating a draft or updating a field, run without a confirmation prompt; they are still previewable with a dry run, recorded in the audit log, and captured in the undo journal. Most MCP clients also ask you to approve each tool call on their side. **Can I try it without letting the AI change anything?** Yes. Start with read-only requests — list plugins, summarize recent orders — which change nothing and need no confirmation. When you move to writes, ask for a dry run first, keep safe mode on, and take a database checkpoint before anything you would hate to redo. The first destructive action will stop and ask you to confirm before it runs. **My Logs tab shows auth_missing_header entries — is someone attacking my site?** Usually not. The entry means a request reached the MCP endpoint without a valid Authorization header, and the plugin refused it before any tool ran — which is the system working. A handful after you connect an app is normal: ChatGPT, Claude and the others make a first contact with no token to discover how to sign in. A steady stream from an app you have already approved means your server strips the Authorization header before WordPress sees it (common on CGI/FastCGI and some LiteSpeed hosts); the Connection Doctor's authenticated handshake check fails in the same case, and the fix is a .htaccess rule or a host setting that passes the header to PHP. A stream from unknown IPs that never signs in is a scanner probing the URL; it gets nothing, and you can rate-limit or block it at the firewall. --- Canonical URL: https://cowboymcp.com/guides/undo-ai-changes-wordpress Title: Undo AI Changes in WordPress: Rollback for AI Agents Last updated: 2026-10-05 # Undo AI changes in WordPress: how rollback works for AI agents ## Can you undo what an AI agent did to your WordPress site? Yes — in most cases, and from two directions. Cowboy MCP keeps a per-change undo journal that records the before-state of every write an agent makes, so a single wrong edit rolls back on its own, and it takes one-click database checkpoints for the operations no journal can invert. Both live on the Activity tab in wp-admin, and both are callable by the agent itself. This page is about mechanics: what is captured, how an undo is applied, where a checkpoint takes over, and what cannot be reversed. The wider guardrails are on the security page and the operating habits in the safe-operations playbook. All of it ships in the free plugin on WordPress.org , which turns a site into a WordPress MCP server with 203 tools. ## How does per-change undo work? Every journaled change is captured when it is dispatched, not reconstructed later. The undo journal is a table in your own database where each mutating tool call stores a full snapshot of the object it is about to touch — the post row with its meta and terms, the option value, the file bytes — plus a hash of the state it left behind. Undo writes that snapshot back wholesale; it never replays a diff. The capture wraps the handler: the dispatcher snapshots the target first and commits the entry only if the tool succeeds, recording the tool, the action (create, update, delete), a readable label, the key that made the call, the MCP session, and any batch. A failed call leaves no entry. Secrets are redacted whenever the journal is read, but the stored blob is faithful, so an undo restores the true value. Three behaviours make it trustworthy. Conflict detection: before restoring, the engine re-snapshots the object and compares it with the hash recorded after the change; if anything else — a later agent call, an editor in wp-admin — touched it since, the undo stops with a conflict error instead of clobbering newer work, and you resend with force: true once you have looked. Redo: every undo is journaled as a new entry pointing at the original, so an undo can be undone (the few exceptions, such as re-creating a deleted attachment, are recorded as not undoable). Batch undo: a multi-tool run shares one batch id and reverts newest-first, stopping at the first failure. The Activity tab lists every entry with Undo and Undo batch buttons, filters it by connection, status, or text, links each undo to the change it reverted, and shows conflicts inline with a Force undo option; the wp_list_changes tool gives an agent the same ledger, filterable by object, tool, batch, session, status, and date. Entries are kept for seven days by default (the Undo Retention setting); a daily prune removes expired rows with the backup zips and trashed media they own. A before-state over 16 MB compressed is recorded as not undoable, so the gap is visible. ## When do you need a database checkpoint instead? When the change is the whole site rather than one object, the journal is the wrong tool. A database checkpoint is a prefix-scoped SQL dump of every site table — written in pure PHP, gzipped into a protected folder under uploads — that can be swapped back in atomically to return the database to that moment. Take one before anything multi-step, and let the plugin take them automatically where undo cannot reach. Two triggers are automatic and on by default: before any WP-CLI command not recognised as read-only (a short allowlist of verbs such as list, get, and search; unknown verbs count as mutating), and before plugin and theme updates, so a migration run by an update can be rewound even though the journal only backs up files. Both fail open — a checkpoint that cannot be written is audit-logged and the command still runs. Manual checkpoints come from the Activity tab or wp_create_checkpoint; the newest five are kept by default. Restore is built to be boring. It takes a pre-restore safety checkpoint first and aborts if it cannot; imports the dump into temporary tables; verifies each table's row count against the count recorded at checkpoint time; then replaces the live tables in a single RENAME TABLE swap, so a failure at any step leaves the originals untouched. The plugin's own API keys, settings, and OAuth records are re-applied afterwards, so a restore can never lock you out of the connection that ran it, and the restore is journaled as not undoable, pointing at the safety checkpoint that reverses it. The limits: a checkpoint restores database tables — not uploads, theme or plugin files, or code. It rewinds everything since that moment, including changes made outside MCP (new orders, comments, sign-ups), which is why the tool warns before running. And it lives on the same server under wp-content/uploads: a rollback point, not an off-site backup. ## What can and can't be undone? The line is whether a before-state exists to restore. A change is undoable when the tool that made it has a registered capture strategy — the large majority of the plugin's write tools — and not undoable when the action has no inverse, leaves nothing to snapshot, or happened outside MCP; either way the journal records it, so the ledger stays complete. The table is derived from the plugin's capture registry. Change | Undo? | How it is reversed — or why not | Posts, pages, custom post types, block edits, patterns, block-theme templates and global styles, SEO meta, Elementor templates, Beaver Builder and SiteOrigin layouts | Yes | Full post row, meta, and terms restored; a deleted post keeps its original ID; a theme-file template edit is undone by removing the database override | Options and WooCommerce settings | Yes | Previous value restored, or the option removed if it did not exist | Users and roles | Yes | Row and meta restored with the original ID; content reassigned during a delete is not moved back; login sessions untouched | Terms, comments, order notes, classic menus | Yes | Restored; a deleted menu returns with a new ID, items and locations intact | Media | Yes | Uploads removed on undo; alt-text and metadata edits roll back; a deleted attachment returns from a trash-aside folder with every size and the original file | Files in wp-content (wp_write_file, wp_delete_file) | Yes | Previous bytes written back atomically; a file the agent created is removed; 16 MB compressed cap per entry | Plugin and theme activation, theme switch | Yes | Toggled back | Plugin and theme install, update, delete | Files only | Previous package restored from a per-change backup zip; an update's database migrations are the auto-checkpoint's job; undo never removes an active plugin or theme | WooCommerce products, variations, orders, refunds, customers, coupons | Yes | Object data restored; a deleted object returns with a new ID | ACF field values and repeater rows; Wordfence settings and firewall mode | Yes | Previous values restored | Search-and-replace | Yes | Captured rows re-applied to the exact posts touched | WP-CLI commands | No | Cannot be inverted; an automatic checkpoint precedes any command that is not read-only | Sent test emails, outbound HTTP requests, cache flush or preload, transient clean-up, thumbnail regeneration, table repair | No | Nothing to recall, or derived data; recorded as not undoable | Bulk stock updates, tax-rate creation, Wordfence scans, IP and country blocks, scan-issue changes | No | Not journaled per object; recorded as not undoable so the gap is visible | A checkpoint restore | No | Restore the pre-restore safety checkpoint taken first | Anything changed outside MCP | — | Not in the journal; a checkpoint rewinds it with everything else since | ## How do you undo from your AI client? You do not need wp-admin to roll back; the same machinery is on the agent's side. The rollback tools — wp_list_changes, wp_undo_change, and the four checkpoint tools — are ordinary MCP tools, so you can ask Claude, ChatGPT, Cursor, or Claude Code to list, undo, and restore in plain English, and safe mode asks for confirmation before an undo or restore runs. Prompts you can paste: - "List the last 10 changes made through MCP, newest first, with their change IDs." - "Undo change 42." — if the object was edited since, you get the conflict message and can say "force it" once you have checked. - "Undo everything from that batch." - "Take a checkpoint labelled 'before menu restructure', then rebuild the main menu." - "List the checkpoints and restore the one from before the plugin update." — the response includes the id of the safety checkpoint taken first. A read-only key cannot undo, because undoing is a write; a custom-scoped key needs the rollback tools in its list. A human always can: Settings → Cowboy MCP → Activity has Undo, Undo batch, Create checkpoint now, and Restore buttons. ## How do dry run and safe mode reduce the need to undo? The cheapest rollback is the one you never make. A dry run reports what a write tool would do — tool, target, parameters — without touching anything, and safe mode holds every tool flagged destructive, including undo and checkpoint restore themselves, until the call is resent with explicit confirmation. Together they catch misread intent before the journal has to earn its keep. Dry run is intercepted before any handler code runs, so it is safe on every non-read-only tool; for most tools it states intent rather than simulating the outcome, while the installer tools resolve the real plan, versions included. Safe mode is on by default and keys on each tool's destructive flag, so ordinary writes still flow — and every one of them is journaled. The habits that make this pay off are in the playbook. ## How does this compare with other WordPress MCP plugins? Reversibility is where WordPress MCP servers differ most. Most WordPress MCP plugins answer "what if the agent is wrong" with an approval gate — you confirm each tool call — and a growing number advertise change tracking or rollback, some within a fixed window such as 72 hours; hosted services rely on staging copies or site snapshots. Cowboy MCP's answer is before-state journaling with conflict detection and redo, plus checkpoints, with retention you set. When you read a rollback claim, ask: does it capture the before-state or just log the call; does it notice when something else changed the object since; can it revert files and plugin packages, or only database rows; does it cover WooCommerce and page-builder data; and how long is the window. The comparison pages go through named alternatives attribute by attribute; this page stays on mechanics. ## FAQ **How long are undo entries kept?** Seven days by default, set by the Undo Retention option in Settings → Cowboy MCP. A daily prune removes expired rows along with the backup zips and trashed media files they own. Checkpoints are governed separately: the newest five are kept by default (configurable), and the automatic pre-restore safety checkpoints expire after the same retention window. **Does undo cover WooCommerce orders?** Yes. Products, variations, orders, refunds, customers, and coupons are journaled with their full object data, so an edit rolls back and a deletion is re-created, though with a new ID. Bulk stock updates and tax-rate creation are recorded as not undoable. A checkpoint restore also reverts orders placed after it, so prefer per-change undo on a live store. **Can an AI agent undo its own changes?** Yes. wp_undo_change and wp_restore_checkpoint are ordinary MCP tools, so the agent that made a change can reverse it when you ask — subject to safe mode confirmation, the conflict check, and the key's scope (a read-only key cannot undo). The undo is itself journaled, so it can be redone, and every change also appears on the Activity tab for you to undo yourself. **Are database checkpoints a backup replacement?** No. A checkpoint is a rollback point for your database tables, stored under wp-content/uploads on the same server and capped at a handful of recent snapshots. It holds no uploads, theme or plugin files, or code, and it would be lost with the server. Keep a real off-site backup; use checkpoints for the quick rewind before risky work. **What about files the agent changed?** Files written or deleted through the file tools are journaled with their full previous bytes, so undo restores a file exactly or removes one the agent created — up to 16 MB compressed per entry, and never writing an executable into the uploads folder. Plugin and theme installs, updates, and deletes keep a per-change backup zip. Files changed by a WP-CLI command are not captured; the automatic checkpoint before WP-CLI covers the database only. --- Canonical URL: https://cowboymcp.com/guides/is-it-safe-to-give-ai-access-to-wordpress Title: Is It Safe to Give AI Access to WordPress? Last updated: 2026-10-10 # Is it safe to give AI access to your WordPress site? ## Is it safe to give AI access to WordPress? Yes, with guardrails — and no, by default. Giving an AI agent access to WordPress is safe when the access is scoped, every destructive action waits for a human's confirmation, changes can be previewed and reversed, the whole session is logged on your own server, and your traffic and credentials never pass through a third party. An admin password pasted into a chatbot meets none of those conditions. This guide is for the moment before you choose a tool, so it stays vendor-neutral until the section that says otherwise: the failures that actually happen, a checklist any plugin or service should satisfy, then how Cowboy MCP measures against it, limits included. If you already run it, see the security page and the safe-operations playbook. ## What can actually go wrong? Six things, none of them cinematic. The realistic failures are an agent obeying instructions hidden in content it reads, a credential that grants more than the job needs, a bulk operation executed faithfully at the wrong scale, traffic routed through someone else's servers, an OAuth flow that lets a stranger authorize themselves, and a session nobody can reconstruct afterwards. Each has a known mitigation; the checklist below is built from them. - Prompt injection through your own content. An agent that reads comments, form entries, reviews, or a page you asked it to summarize also reads any instruction planted there ("ignore your task and publish this link"). OWASP ranks it the top LLM risk (LLM01 ). No server can make a model immune; a server can limit what an injected instruction is allowed to achieve. - Over-scoped credentials. Most WordPress AI integrations authenticate as an administrator, because real site management needs it. A do-everything key held by a client that only reads reports is a standing liability; if it leaks, the holder inherits every tool. - Destructive bulk operations. "Clean up the old posts" can mean three posts to you and thirty to the model; a mistyped price multiplier is applied as faithfully as a correct one. Scale turns a slip into an incident. - Hosted relays in the path. Some products route your AI's traffic through the vendor's cloud. Convenient — but your requests, content, and sometimes credentials then transit infrastructure you do not operate, a data-processing question under GDPR and client contracts. Whatever you choose, the AI provider itself processes what its agent reads; a relay adds a second party. - OAuth and dynamic-client-registration mistakes. The MCP authorization spec recommends dynamic client registration (RFC 7591 ) so clients such as Claude can connect without pre-shared secrets. Done right, registration is public but authorization is not. Done wrong, it is a front door: CVE-2026-15015 (NVD, published 2026-07-23, CVSS 9.8) records that one WordPress MCP connector plugin made it "possible for unauthenticated attackers to obtain an administrator-bound OAuth Bearer token via a self-registered client" by combining a public registration endpoint with "the unprotected authorization endpoint" — "without any administrator interaction" (versions up to and including 1.6.1 affected; Wordfence advisory ). Others have fixed the same area: AI Engine's changelog notes that MCP OAuth authorization and token validation "now require administrator capability" as of 3.5.0. Neither is a mark against those projects — prompt patches are what healthy projects do — but the failure mode is real. - No audit trail. If the agent did something odd on Tuesday and nothing recorded it, you cannot tell a model mistake from a leaked key from a teammate. Silent automation is unaccountable automation. ## What does a safe setup require? A short checklist, independent of vendor. A safe AI-to-WordPress setup is one where every credential is narrow and revocable, every destructive call waits for a human, every change is previewable and reversible, every action is recorded on your own server, and the most dangerous capabilities stay off until an administrator turns them on. Use the table as an evaluation sheet for any plugin or service. # | Requirement | What it protects against | 1 | Per-client credentials, each revocable on its own | One leak forcing you to revoke everyone; no way to tell clients apart | 2 | Read-only or tool-limited scope per credential | Over-broad keys; injected instructions reaching write tools | 3 | Explicit confirmation for destructive actions | Misread intent executed at scale | 4 | Preview / dry run before writes | Bulk mistakes; unverified assumptions | 5 | Per-change undo plus whole-database checkpoints | Mistakes that got through anyway | 6 | Audit log you can read without the vendor | Unaccountable sessions; leaked-key forensics | 7 | Rate limits per credential and per IP | Runaway loops; brute-force guessing | 8 | Secrets stored as one-way hashes, never echoed back | Database dumps; key recovery | 9 | No third-party relay between client and site | Data leaving your server; vendor-held credentials | 10 | Escalation only by an administrator in wp-admin, never via the API | Agents, or injected prompts, granting themselves power | 11 | OAuth gated by admin consent, PKCE, and user-bound tokens | Self-authorized strangers (the CVE above) | 12 | Host, WAF, and HTTPS compatibility check | Silent failures; keys sent in the clear | ## How does Cowboy MCP meet that checklist? Item by item, with the limits stated. Cowboy MCP is a self-hosted MCP server that runs inside your WordPress install, so every guardrail below is enforced by PHP on your own server, not by the model's judgment or a vendor's cloud. Where a guardrail has an edge, the edge is named; the security page goes deeper on each one. Item | How Cowboy MCP does it | Limits | 1. Revocable credentials | One API key per client — labeled, shown once, revoked individually on the Connections tab in Settings → Cowboy MCP, where OAuth connections sit in the same table with when each was created and last used. | A valid key acts with administrator capabilities inside the guardrails — treat it like an admin password. | 2. Scope | Every key and OAuth client carries a scope — full, read-only, or a hand-picked tool list — checked on every call; discovery shows in-scope tools only. | A custom scope that includes WP-CLI or file writes is escalation-equivalent by design; don't grant those to a credential you mean to confine. | 3. Confirmation | Safe mode, on by default: destructive tools refuse to run until resent with confirm: true; WP-CLI commands outside a known-safe list do the same. | Ordinary writes (a draft, a field update) do not prompt — they are previewable and journaled instead. | 4. Preview | Every non-read-only tool accepts a dry run reporting tool, target, and parameters without executing. | For most tools the preview states intent rather than simulating a diff; installers and updaters resolve the real plan. | 5. Undo and checkpoints | Journaled changes capture a before-state and roll back individually; database checkpoints restore every table and run automatically before mutating WP-CLI commands and plugin or theme updates. See how undo works. | Journal kept seven days by default; actions with no inverse (a sent email, a cache flush, arbitrary WP-CLI) are recorded as not undoable; checkpoints restore tables, not uploads or code. | 6. Audit log | Every call, error, and auth event is written to a table in your own database — key, tool, arguments, result, IP — filterable in wp-admin, credential-looking fields redacted first. | Pruned after 30 days; export before then for longer history. | 7. Rate limits | 120 requests a minute per key by default, plus a 30-per-minute per-IP throttle that also counts failed authentication. | Transient-based and approximate under heavy concurrency — a brake, not a hard boundary. | 8. Hashed secrets | Keys stored as one-way hashes, OAuth tokens as SHA-256 digests; read-only resources refuse secret-looking options, user-meta output masks credential fields, and the log is redacted. | Redaction is pattern-based, and the WP-CLI escape hatch can still read third-party options — scope the credentials that hold it. | 9. No relay | The endpoint is a REST route on your site and your client connects to it directly — no accounts, no telemetry, no phone-home. Outbound calls go to WordPress.org for installs and to URLs you explicitly request, private and internal addresses rejected. | Your AI provider still processes whatever the agent reads — inherent to using an AI, and no plugin changes it. | 10. Admin-only escalation | Power mode, which lifts the SQL, WP-CLI, file-path, and outbound-request guardrails, is a wp-admin checkbox. The plugin's own settings and keys sit on a never-writable list, so no API call and no injected instruction can enable it. | It really does lift guardrails. Keep it off on production; on staging, on for one job, then off. | 11. OAuth | Off by default. New clients can register only while an administrator has opened a 30-minute window (Claude Code and Codex skip registration with a client ID metadata document), and authorization cannot complete without a logged-in administrator approving a consent screen on your own site; the redirect must match the registered one, PKCE S256 is mandatory, and tokens are bound to your site and the approving admin, failing closed if that account loses its role. | The Claude and ChatGPT apps need a public HTTPS hostname; terminal tools and editors sign in on the same computer, so local sites work. While the window is open, registration is reachable by anyone — the consent step is the gate. | 12. Compatibility check | A built-in Connection Doctor tests configuration, loopback, HTTPS, and OAuth readiness and reports likely causes and fixes; it understands local sites. | Plain HTTP is permitted for local development; on a public host the Doctor warns rather than blocks. | ## Which AI client is safest to start with? The one you already use, holding a key that cannot write. The safest first connection is a read-only credential on a site that is not your production store, through a client that asks you before each tool call. The client matters less than the scope, because the server enforces the scope no matter who is calling. A practical order: a local development site (Local, Studio, MAMP, DevKinsta) with Claude Code, Cursor, or Codex on the same machine is the lowest-stakes sandbox — no public URL, no tunnel, and a read-only grant on the sign-in screen; the Claude guide shows the setup. On a live site, the Claude desktop and web apps use the OAuth connector: you approve a consent screen on your own site as an administrator, the token is bound to your account, and you revoke it from the settings page. Cloud-side clients such as claude.ai and ChatGPT connect from the vendor's servers, so for them the site needs a public HTTPS hostname; terminal tools and editors sign in from your own machine. Most MCP clients also ask you to approve each tool call — a second layer you control. Widen the scope only once the agent's read answers match reality. ## How do you tell if a WordPress AI plugin is safe? Ask the vendor seven questions before you install anything. A safe WordPress AI plugin can answer, in writing, where your traffic goes, what is reachable without authentication, how narrowly a credential can be scoped, whether changes can be previewed and undone, where the audit log lives, how its OAuth flow is gated, and how it handles vulnerability reports. Vague answers are themselves an answer. - Does any traffic leave my server other than to the AI provider I chose? If there is a relay, who operates it and what does it store? - Is authentication on by default, and is any endpoint reachable without it? - Can I issue a read-only or tool-limited credential, and revoke one without revoking all? - Can I preview a change before it runs and undo it afterwards — and for how long? - Is there an audit log in my own database, and what is redacted from it? - If it supports OAuth: does dynamic client registration lead to an administrator consent step, is PKCE required, and are tokens bound to a user and to my site? - What is the disclosure policy, and what does the record show? Search the plugin slug on NVD, Wordfence Intelligence, or WPScan. A fixed advisory with a quick patch is a better sign than a project with no data at all. Cowboy MCP's answers to the first six are the rows above; for the seventh, the plugin is open source on WordPress.org and GitHub, so every gate described here can be read in the code. The self-hosted vs hosted comparison puts the same questions to hosted architectures. ## FAQ **Can the AI read private data on my site?** Yes, if you let it. An authenticated agent acts with administrator capabilities, so a full-scope credential can read private posts, drafts, user emails, and most options — that is what site management requires. What it should never see are secrets: Cowboy MCP stores API keys as one-way hashes, refuses to serve options whose names look like keys, tokens, or passwords through its read-only resources, and masks credential fields in user data and the audit log. When reading is all the job needs, issue a read-only credential. **Can an AI agent delete my whole site?** Not easily, and not silently. With safe mode on, deletes and other destructive tools stop and ask for confirmation; schema-destroying SQL and database-reset WP-CLI commands are blocked unless an administrator enables power mode in wp-admin; the last administrator account cannot be deleted; journaled changes roll back individually; and database checkpoints restore every table. The realistic bad case is a wrong edit you undo, not a lost site — but keep your normal backups, because checkpoints do not restore files. **Does the AI see my API keys or passwords?** No. Keys are shown once when generated and stored only as a one-way hash that cannot be recovered from the database; OAuth tokens are stored as SHA-256 digests. The plugin's own settings and keys cannot be written through the API even in power mode; queries that touch password or session data are refused; and credential-looking fields are redacted before they reach the log. **Does this work on WordPress multisite?** Cowboy MCP is configured per site, not per network: each site has its own settings page, keys, undo journal, and audit log, and a key issued on one site manages that site. It was not designed as a network-level administration tool — there is no network settings screen — so if you run a multisite network, start on a staging copy and treat each site's credential as separate. **Do I need HTTPS?** For anything on the public internet, yes. A Bearer key sent over plain HTTP is readable by anyone on the path, and the OAuth connector will not run without a public HTTPS hostname. The exception is local development — a site on localhost or a .local or .test domain, used by a client on the same machine — where plain HTTP is normal and the Connection Doctor reports it as a pass with local context. On a public host the Doctor warns about plain HTTP; fix the certificate before issuing keys. --- Canonical URL: https://cowboymcp.com/guides/wordpress-mcp-security-vulnerabilities Title: WordPress MCP Plugin Vulnerabilities: The 2026 Pattern Last updated: 2026-10-10 # WordPress MCP plugin vulnerabilities: the 2026 pattern and how to check any plugin ## What happened to WordPress MCP plugins in 2026? Four plugins, two weeks, one bug. Between 19 August and 3 September 2026, four WordPress MCP plugins published authorization-bypass advisories with the same shape: a low-privilege user — a subscriber, or the holder of an OAuth bearer token — could call administrator-level MCP tools because the tool handler never re-checked the caller's capabilities. None was an exotic exploit. Each was a missing permission check at a new entry point. The table lists them as the advisories describe them. Every project shipped or is shipping a patch; a quick fix is what a healthy project does, and nothing here is an argument against any of them. Plugin | Affected | Advisory | Severity | Published | Fixed in | AI Engine | 3.6.0 and earlier | CVE-2026-75796 — a multisite sub-site administrator could reach network-admin operations through the MCP User Tools | CVSS 7.2 | August 2026 | 3.6.1 | Royal MCP | before 1.4.26 | Subscriber+ insufficient authorization in MCP tools, reported by Patchstack | CVSS 8.1 | 24 August 2026 | 1.4.26 | Agentimus (AI SEO, llms.txt & MCP) | 1.51.0 and earlier | CVE-2026-84779 — subscriber-level broken access control | CVSS 8.1 | 3 September 2026 | see advisory | MountDev AI MCP Connector | 1.6.5 and earlier | CVE-2026-85306 — missing authorization | CVSS 6.5 | 3 September 2026 | see advisory | Three of the four had been here before. AI Engine's earlier CVE-2026-8719 (CVSS 8.8) let a subscriber holding an OAuth token call administrator MCP tools, fixed in 3.4.9. Royal MCP's August advisory was its third authorization flaw of the year, after CVE-2026-40775 in June. MountDev's followed CVE-2026-15015 (CVSS 9.8) in July, where an unauthenticated visitor could self-register an OAuth client and obtain an administrator-bound token. A repeat is not proof of carelessness, but it tells you where to look before you install. This guide is a buyer's checklist, not a scorecard: why the bug recurs, how to check any plugin for it, what to do if you run an affected version, and — in the one section about our own plugin — how Cowboy MCP gates its tools, limits included. For the broader question, start with is it safe to give AI access to WordPress? ## Why does the same bug keep appearing? Because an MCP tool is a new front door on a house that only guards the old ones. WordPress enforces permissions at the places it knows about — wp-admin screens, REST controllers, AJAX handlers — but an MCP tool is a plugin-defined function reached through the plugin's own endpoint, so the only capability check it gets is the one the plugin author writes. If the endpoint authenticates the caller and then trusts every tool equally, any account that can authenticate becomes an administrator for the duration of the call. Three habits make that mistake easy: - Authentication is mistaken for authorization. A valid session cookie, application password, or bearer token tells you who is calling, not what they may do. A subscriber is authenticated; a subscriber must not create administrators. Most of the 2026 advisories are exactly this gap, at the tool level. - OAuth tokens become identities without roles. A bearer token from an OAuth connector is often stored with a client ID but not the approving user's capabilities, and rarely re-checked on each call. When the token is minted for a low-privilege account — or, as in CVE-2026-15015, for nobody at all — the handler cannot tell. The MCP specification's 2026-07-28 revision deprecates dynamic client registration in favour of client ID metadata documents (CIMD), largely because a public registration endpoint beside a weak authorization step kept failing. - Tools have no declared blast radius. When every tool looks alike to the server, "list posts" and "delete user" pass the same gate. The protocol's readOnlyHint and destructiveHint annotations exist to fix that, and both Anthropic's and OpenAI's connector directories now require them on every tool. WordPress is heading the same way: WordPress 7.2, due 9 December 2026, splits core content abilities into separate query, create, update, and delete abilities so annotations can mark the destructive ones. None of this replaces a capability check, but it gives a server something to enforce. The common thread: the check has to live in the tool dispatcher, on every call, against the actual caller — not at login, not at token issue, not in the tool list. ## How do you check whether an MCP plugin re-checks permissions? You can vet most plugins in an afternoon without reading all of their code. To check whether a WordPress MCP plugin re-checks permissions, search its advisory record, find the function that dispatches tool calls and confirm it consults capabilities or a per-credential scope on every call, then prove it with a subscriber account on a staging site. - Search the record. Put the slug into NVD , Wordfence Intelligence , WPScan , and Patchstack . A fixed advisory with a fast patch is a good sign; a repeat in the same area is the thing to ask about. - Ask who can authenticate at all. Can a subscriber, customer, or contributor obtain a credential the endpoint accepts? If yes, every tool must check capabilities. If credentials can only be issued by an administrator in wp-admin, the question becomes how narrowly each one can be scoped. - Find the dispatcher. Every MCP plugin has one function that turns a tools/call request into a PHP call. Look for current_user_can, a scope or allow-list check, or a lookup of the tool's annotations before the handler runs. If it goes straight from "token is valid" to call_user_func, the plugin is relying on each handler to check itself — so spot-check the ones that create users, write files, run SQL, or change options. - Check how OAuth tokens are bound. A token should record the approving user and be re-validated against that user's current role on every request, so removing an administrator role revokes their agent too. Consent should require an administrator, PKCE should be mandatory, and the redirect URI must match the registered one. - Read the annotations. List the tools and confirm every write tool declares readOnlyHint: false and every delete, reset, or bulk overwrite declares destructiveHint: true. A plugin that omits them cannot offer a read-only credential that means anything. - Prove it on staging. Create a subscriber, obtain whatever credential a subscriber can get, and call an administrator tool — list users, update an option. The correct answer is a permission error. Repeat with a read-only credential and a write tool. - Check the plugin's own protections. Can an agent change the plugin's settings, widen its own scope, or mint a new key through the API? Those should be write-protected from the endpoint even for an administrator credential, or an injected instruction can escalate itself. The safety guide turns the same questions into a twelve-row evaluation sheet, and the comparison hub records which plugins declare annotations and OAuth support. ## What should you do if you run one of the affected plugins? Update, then assume the window was used. If you run an affected version, update to the fixed release immediately, revoke and reissue every OAuth token and application password the plugin accepted, and review users, options, and recent changes for anything a low-privilege account could not normally have done. Patching closes the door; it does not tell you whether anyone walked through it. - Update first. If the fix has not reached the directory, disable the plugin or its endpoint until it does — the endpoint is reachable from the internet by design. - Revoke credentials. Tokens minted before the fix were minted under the flawed check; reissue from a clean state. - Audit the accounts. Look for new administrators, role changes, and edited email addresses; on multisite, check network users too. Open subscriber registration is the usual foothold. - Diff the site. Compare options, active plugins, and recently modified files against a pre-disclosure backup, and read the plugin's audit log if it keeps one. - Watch the second advisory. Where a project has repeat findings in one area, treat its next release as urgent. ## How does Cowboy MCP gate its tools? By credential, not by WordPress role — and the checks run in the dispatcher, on every call. Cowboy MCP has no role-based path into its endpoint: every request carries either an API key that only an administrator can issue in wp-admin, or an OAuth token that only exists because an administrator approved a consent screen, and each call then passes a per-credential scope check before anything else happens. The points below are verified against the plugin source at 1.7.3, limits included. - Who can authenticate. API keys are created on the settings page, which requires the manage_options capability; a subscriber or customer has no way to obtain one. Browser sign-in (the OAuth connector) is off by default. When on, new clients can register only while an administrator has opened a 30-minute New connections window, authorization cannot complete without a logged-in administrator approving a consent screen on your own site, PKCE S256 is mandatory, and the redirect must match the registered one. Since 1.7.2, clients that publish a client ID metadata document — Claude Code and Codex today — skip registration entirely: the plugin fetches the document only after an administrator is logged in on the consent screen, only from hosts on the same allowlist as redirects, and takes the client's name and redirect URIs from it. Limit: other clients still use dynamic client registration behind the consent gate. - Tokens stay bound to an administrator. Each OAuth token records the approving user, and every validation re-checks that the user still exists and still holds manage_options; demote or delete the account and the token is revoked on the spot. Tokens are stored as SHA-256 digests; API keys are stored with WordPress's one-way password hash and compared against every key on each request, so the visible prefix can never act as a shortcut. - Scope is checked on every call. Each key and OAuth connection carries a scope — full, read-only, or a hand-picked tool list — and the dispatcher checks it after resolving the tool and before validating arguments, running a dry run, or applying safe mode, so an out-of-scope tool never leaks a preview. Discovery lists only in-scope tools, and the scope settings sit on a list of options that can never be written through the API, so a credential cannot widen itself. Per-credential scoping shipped in 1.6.2. Limit: a full-scope credential acts with administrator capabilities inside the guardrails — treat it like an administrator password. - Annotations are a boundary, not decoration. All 203 tools declare readOnlyHint and destructiveHint, and abilities bridged in through the Abilities API inherit theirs. Read-only scope is enforced from readOnlyHint; safe mode, on by default, stops any tool with destructiveHint until the call is resent with confirm: true, and WP-CLI commands outside a short known-safe list get the same treatment. Every non-read-only tool accepts a dry run. - Capability checks inside handlers, where WordPress expects them. Tools that install, update, activate, or delete plugins and themes, manage users, upload or delete media, edit menus, and write SEO meta additionally call current_user_can for the matching capability before acting. Granting an administrator role, setting a password, or changing a privileged user's email requires power mode; a credential can never change its own role, password, or email, and the last administrator can be neither deleted nor demoted. Limit: because the request already runs as an administrator, these are belt-and-braces; the scope check is the gate. - The dangerous stuff stays locked. Without power mode the plugin blocks schema-destroying SQL (DROP, TRUNCATE, ALTER), refuses eval, shell, and database-reset commands in WP-CLI — after tokenizing the command the way the shell would, so quoting tricks do not slip past — refuses writes into mu-plugins/ (since 1.6.5), syntax-checks every PHP file before it lands, and rejects outbound requests to private addresses. Secret-looking options are refused to read-only resources and masked in output. Power mode is a wp-admin checkbox, and the plugin's own settings and keys stay hard-protected from API writes even when it is on. - Everything is recorded and reversible. Every call, error, and authentication event — including failed attempts and scope denials — goes to an audit log in your own database, credential-looking fields redacted first, pruned after 30 days. Journaled changes capture a before-state and roll back individually from the undo journal; database checkpoints run automatically before mutating WP-CLI commands and plugin or theme updates. Requests are capped at 120 a minute per credential by default, with a stricter per-IP throttle that also counts failed authentication. Limit: the journal keeps seven days by default, checkpoints restore tables rather than files, and the rate limiter is approximate under heavy concurrency. That covers checklist steps 2 through 5 and 7. The security page walks through each guardrail with its edge cases, how undo works covers what happens when a change gets through anyway, and the plugin is open source on WordPress.org and GitHub, so every gate here can be read in the code rather than taken on trust. ## FAQ **Has Cowboy MCP had a security vulnerability?** None published as of September 2026. Search the slug on NVD, Wordfence Intelligence, WPScan, and Patchstack rather than taking our word for it, and read the changelog: the project ships hardening proactively — tokenized WP-CLI blocklist matching and per-credential scoping in 1.6.2, power-mode gating for mu-plugins writes and PHP syntax checks in 1.6.5. A clean record is a snapshot, not a guarantee; the plugin is open source, and reports are welcome through the WordPress.org plugin security process. **How do I check whether an MCP plugin re-checks permissions?** Find the function that dispatches tools/call requests and look for a capability or scope check between "the token is valid" and the handler running — a current_user_can call, a per-credential allow-list, or a lookup of the tool's annotations. Then prove it on staging: create a subscriber, obtain whatever credential a subscriber can get, and call an administrator tool such as listing users. The correct answer is a permission error. Repeat with a read-only credential and a write tool. **Is an OAuth bearer token the same as an admin login?** Only if the plugin makes it so. A well-built connector records which user approved the token, requires that user to be an administrator at consent time, and re-checks their role on every request so the token dies when the role does. A weak one issues a token to any authenticated account, or to nobody, and then treats every token the same — several 2026 advisories were exactly that gap. Cowboy MCP binds each token to the approving administrator and fails closed if that account loses the role. **Do readOnlyHint and destructiveHint make a plugin safer?** Only when the server enforces them. As metadata they help a client decide whether to ask you before a call; as a gate they let a read-only credential refuse every write tool and safe mode stop every destructive one. A plugin can declare them and still trust every caller equally, so ask whether the annotations drive anything server-side. In Cowboy MCP, read-only scope and safe mode both key on them, which is why every tool declares both. **Should I turn off my MCP plugin until it is patched?** If you run an affected version and the fixed release is not yet available, yes — deactivate the plugin or disable its endpoint, because the endpoint is reachable from the internet by design. Once updated, revoke and reissue the credentials the plugin accepted, review users and options for changes a low-privilege account could not normally make, and read the audit log if the plugin keeps one. Patching closes the door; it does not tell you whether anyone used it. **Does self-hosting make this class of bug more or less likely?** Neither; it changes who can fix it and who sees the traffic. A self-hosted plugin puts the capability check in PHP you can read and update yourself, and keeps requests, credentials, and logs on your server. A hosted relay moves the check to infrastructure you cannot inspect and adds a second party to the data path. Either can get authorization wrong. The check that matters is the one in the tool dispatcher, and you can only audit it where you can read the code. --- Canonical URL: https://cowboymcp.com/connect Title: Connect WordPress to Any AI App: Claude, ChatGPT, Gemini & More Last updated: 2026-10-13 # Connect WordPress to any AI app ## Which AI apps can manage a WordPress site? Any app that speaks the Model Context Protocol can, once your site runs an MCP server. Cowboy MCP is one free plugin that connects a self-hosted WordPress site to Claude, ChatGPT, Gemini, Grok, Perplexity, Cursor, VS Code, Claude Code, Codex and n8n, each with the same one-click sign-in and the same 203 tools behind it. The table below is the part that differs per app: the plan you need, where the setting lives, how the sign-in works, and whether the app can reach a site that runs on your own computer. Every row was checked by connecting a real site on the date shown. Vendors move menus and plan gates without notice, so each row links to the full guide, which carries the current screenshots and troubleshooting. App | Plan needed | Where to click | Sign-in | Local site? | Verified | Claude (claude.ai) | Any Claude plan; Free allows one custom connector. Team and Enterprise: an owner adds it first | Connections tab → Add to Claude | One click, approve on your site | No — connects from Anthropic's servers | 2026-10-06 | Claude Desktop | Same as claude.ai | Connections tab → Add to Claude, or Settings → Connectors → Add custom connector | One click, approve on your site | Yes — through the small mcp-remote bridge | 2026-10-06 | Claude Code | A Claude plan that includes Claude Code (Pro or Max), or API billing | Connections tab → Claude Code panel → run two lines | One command, browser sign-in | Yes | 2026-10-07 | ChatGPT | Plus, Pro, Business, Enterprise or Edu, on the web, with Developer mode on. Business and Enterprise: an admin allows Developer mode first | Connections tab → Open ChatGPT, then Plugins → + → Add custom MCP server | OAuth, approve on your site | No — connects from OpenAI's servers | 2026-10-12 | Codex CLI and app | A ChatGPT plan that includes Codex (Plus, Pro, Business, Enterprise or Edu), or an API key | Connections tab → Codex panel → one codex mcp add command | One command, browser sign-in | Yes | 2026-10-07 | Perplexity | Pro, Max or Enterprise. Free has no custom connectors. Enterprise: an admin allows member connectors first | Connections tab → Open Perplexity, then Customize → Connectors → + Custom connector | OAuth, approve on your site | No — connects from Perplexity's servers | 2026-10-12 | Grok | Any, including the free plan. Business and Enterprise: an admin provisions it | Connections tab → Open Grok, then grok.com/connectors → New Connector → Custom | OAuth, approve on your site | No — connects from xAI's servers | 2026-10-12 | Gemini app | A personal Google account in the US, 18+, Gemini in English. No paid plan listed; work and school accounts have no Custom apps yet | Connections tab → Open Gemini, then Settings → Connected Apps → Custom apps | OAuth, approve on your site | No — connects from Google's servers | 2026-10-12 | Gemini CLI | A Google account; the free tier works | Connections tab → Gemini CLI panel → one gemini mcp add command, then /mcp auth | One command, browser sign-in | Yes | 2026-10-07 | Cursor | Any Cursor plan | Connections tab → Add to Cursor | One click, browser sign-in | Yes | 2026-10-07 | VS Code (GitHub Copilot) | Any Copilot plan, including Free. Business and Enterprise: an admin enables the MCP servers policy | Connections tab → Install in VS Code | One click, browser sign-in | Yes | 2026-10-07 | n8n | Any n8n Cloud plan, or self-hosted n8n (Community Edition included) | Connections tab → n8n panel; add an MCP Client Tool node | OAuth2 (n8n registers itself) or a Bearer API key | Self-hosted n8n: yes. n8n Cloud: no | 2026-10-10 | "Verified" is the date the row was last checked end to end on a live connection. "Local site?" means a site on Local, Studio, MAMP, DevKinsta, wp-env or Docker with no public address — see the local WordPress MCP guide for the full picture. ## What do all twelve have in common? The setup differs; the connection does not. Every app reaches the same Streamable HTTP endpoint on your own site, /wp-json/cowboy-mcp/v1/endpoint, signs in through a consent screen that you approve as an administrator, and gets exactly the access you grant — full, read-only, or a custom list of tools. Nothing is granted until you click Approve, there is no API key to copy for any of the one-click paths, and no relay or vendor service sits between the app and your server. Three things follow from that. First, you can connect several apps to one site at once and see each of them, with when it last connected, on the Connections tab. Second, the safety layer is the same whichever app is talking: safe mode holds destructive tools until the agent confirms, every write can be previewed as a dry run, every change lands in a per-change undo journal, and one-click database checkpoints roll the whole site back. Third, if a connection fails, the Connection Doctor on the same tab tests HTTPS, the REST API, OAuth discovery and the common host blockers and names the fix, whatever the app. ## Which app should you pick? Pick the app you already use; the plugin does not care. If you want to type instructions and have the site change, use a chat app — Claude, ChatGPT, Gemini, Grok or Perplexity; if you build the theme or plugin, use the tool in your editor or terminal — Cursor, VS Code, Claude Code or Codex; if you want work to happen on a schedule without you, use n8n. Two practical constraints decide the rest. A site that runs on your own computer with no public address can be reached by the terminal and editor tools, by Claude Desktop through its local bridge, and by a self-hosted n8n, but not by the cloud apps, which connect from the vendor's servers and need public HTTPS. And plan gates vary: Grok's free plan works, Claude's Free plan allows one connector, ChatGPT and Perplexity need a paid plan, and the Gemini app is limited by account type rather than price. The guides linked in the table cover each in detail. ## What about Windsurf, Cline, Zed and other MCP clients? They work too. Cowboy MCP is a standard Streamable HTTP MCP server, so any client that can take a URL and an Authorization: Bearer header connects — Windsurf, Cline, Zed, Opencode, LibreChat, Goose, Raycast and your own agent included. Opencode signs in with the same browser flow; the others take an API key generated on the Connections tab, which you can scope to read-only or to a hand-picked list of tools. The plugin readme has the one-block config for each editor. ## FAQ **Which AI apps can connect to WordPress?** With Cowboy MCP installed, Claude (claude.ai and Claude Desktop), Claude Code, ChatGPT, Codex, Perplexity, Grok, the Gemini app and Gemini CLI, Cursor, VS Code with GitHub Copilot and n8n all connect with one-click browser sign-in and no API key to copy. Windsurf, Cline, Zed, Opencode, LibreChat and any other MCP client connect with a scoped API key. All of them use the same endpoint on your own site and the same tools. **Which AI apps work with a WordPress site on localhost?** The ones that run on your computer: Claude Code, Codex, Gemini CLI, Cursor, VS Code and a self-hosted n8n sign in through your browser with no public URL, and Claude Desktop reaches a local site through the small mcp-remote bridge. The cloud apps — claude.ai, ChatGPT, Perplexity, Grok, the Gemini app and n8n Cloud — connect from the vendor's servers and need a public HTTPS address. **Which AI apps connect to WordPress on a free plan?** Grok's free plan supports custom connectors, verified on 12 October 2026. Claude's Free plan allows one custom connector. The Gemini app lists no paid-plan requirement but needs a personal US Google account. Gemini CLI's free tier works, VS Code works on Copilot Free, and self-hosted n8n is free. ChatGPT needs Plus or higher and Perplexity needs Pro or higher; Claude Code and Codex need a plan that includes them or API billing. **Can I connect more than one AI app to the same site?** Yes. Each app gets its own connection with its own scope, and the Connections tab lists every one with when it was created and last used. You can revoke any of them individually, and every app's actions land in the same audit log and undo journal. **Do I need an API key to connect?** Not for the twelve apps in the table: each signs in through a consent page on your own site that you approve as an administrator, and nothing is granted until you click Approve. API keys remain for scripts, CI and clients that have no browser sign-in, such as Windsurf, Cline and Zed, and can be scoped to read-only or a custom list of tools. --- Canonical URL: https://cowboymcp.com/guides/wordpress-7-2-ai-mcp-adapter Title: WordPress 7.2 for AI: Abilities, Secrets API & the MCP Adapter Last updated: 2026-10-13 # WordPress 7.2 for AI: what changes for site owners ## What does WordPress 7.2 change for AI? WordPress 7.2 is the first release where core itself starts describing what an AI agent may do on a site. Three pieces are moving together: the Abilities API that shipped in 6.9 gains its first core-registered content abilities, a Secrets API for storing provider keys is heading into core, and the official MCP Adapter — the bridge that exposes those abilities to AI apps — is now a one-click install from the WordPress.org directory. None of the three is a finished AI feature on its own, and the release is still in beta, so this guide separates what is confirmed from what is planned, and says plainly what still needs a plugin. The schedule, from the official 7.2 release page : Beta 1 on 20 October 2026, further betas weekly through 10 November, release candidates from 17 November, and the final release on 8 December 2026. Features that are not ready by Beta 1 normally slip to a later release rather than shipping half-done, so treat anything below marked "planned" as exactly that until Beta 1 lands. ## What are the core content abilities? An ability is a named, described, permission-checked function that a plugin or core registers so that software — an AI agent included — can discover and call it. The Core AI team's plan for 7.2 is four content abilities split CRUD-style: core/content-query, core/content-create, core/content-update and core/content-delete, each annotated so a client can tell a read from a destructive write before it runs. The split is deliberate: a query can be marked read-only and a delete marked destructive, which lets an MCP client ask for confirmation on the right calls. The pattern is already testable. The canonical AI plugin version 1.4.0 (5 October 2026) renamed its core/read-content ability to core/content-query, keeping the old name as a deprecated alias, and lists the create, update and delete abilities as its next work; the team said in August that the "current goal is for this abilities pattern to become part of WordPress Core in 7.2" (AI team summary, 20 August ). Whether the four land in core at Beta 1 or stay in the AI plugin a little longer is the thing to watch on 20 October. What they cover is posts, pages and other content types. What they do not cover is everything else a site owner asks an agent to do: WooCommerce products and orders, media, plugins and themes, users, settings, the database, caches, security scans, and any form of undo. ## What is the Secrets API? The Secrets API is a managed store for API keys and other credentials that plugins would otherwise keep as plain text in the options table. The Core AI team aligned on moving it into WordPress 7.2 after it had been available in the AI plugin, so that provider keys for OpenAI, Anthropic, Google and the like are stored and read through one audited path. It mostly matters to the AI plugin and to developers who build on the PHP AI Client. For an MCP connection it changes little. MCP clients authenticate to your site with an OAuth connector or an API key, not with a provider key stored in WordPress, so the Secrets API neither replaces nor affects how Claude, ChatGPT or Cursor sign in. It is good hygiene for the keys that flow the other way — your site calling an AI model — and Cowboy MCP, which stores no provider keys at all, is unaffected by it. ## What does the MCP Adapter on WordPress.org mean? The adapter is the official bridge from abilities to the Model Context Protocol: it reads whatever abilities a site has registered and marked public, and serves them to AI apps as MCP tools from an endpoint on the site. Version 0.7.0 joined the WordPress.org plugin directory on 2 October 2026 under the WordPress.org author account, so it now installs like any plugin, updates itself, and can be declared as a dependency instead of being bundled. It requires WordPress 6.9 and adds support for the MCP specification's 2026-07-28 revision while keeping older clients connecting (announcement, 7 October ). Two things to keep straight. The adapter's own listing says it "does not provide any AI features itself": with no abilities registered there is nothing to call, so on a plain 7.1 site today it exposes the three discovery meta-tools and whatever other plugins have registered. And the project still describes itself as experimental, with a stable 1.0 as the goal. The AI team has also drafted a way for the AI plugin to switch MCP on with one toggle that installs the adapter; as of 13 October that is a draft, not a shipped setting (AI team summary, 2 September ). For a fuller side-by-side, including the Node.js proxy question and authentication, see Cowboy MCP vs the WordPress MCP Adapter. ## What changes for a site owner in practice? If you run a site and want an AI app to help run it, 7.2 makes the plumbing official without making the job done. After 7.2, a stock WordPress site with the adapter installed will let an AI app query, create, update and delete content through core-blessed abilities — and that is the extent of it, until plugins register abilities for everything else. Three consequences follow. - The framework is the adapter; the server is still a plugin. The adapter turns registered abilities into tools. Something has to register the abilities — core for content, and plugins for WooCommerce, media, maintenance, diagnostics and the rest. A site that wants an agent to update plugins, read the error log, put a collection on sale or run a Wordfence scan still needs a plugin that provides those tools. - Safety is not in the pipe. Confirmation before destructive calls, previews, undo and logging are left to the abilities and the client. The CRUD split helps a client ask before a delete; it does not give the site a way back after one. If an agent will touch a live site, the undo and checkpoint story has to come from somewhere else. - Sign-in gets no easier by itself. The adapter authenticates with application passwords natively, and with OAuth through an optional Node.js proxy. The browser-based one-click sign-in that Claude, ChatGPT, Perplexity, Grok and the Gemini app expect is a plugin feature today. ## How does Cowboy MCP fit with WordPress 7.2? Cowboy MCP sits one layer above the framework, and since version 1.6.4 it plugs into it from both sides. Every allowed Cowboy tool is registered as a cowboy-mcp/* ability, so the adapter, wp ability run and the core abilities REST route can call Cowboy's 203 tools — with safe mode, dry runs, the audit log and the undo journal still applied — and, in the other direction, abilities that core and other plugins register appear to your agent as Cowboy tools. Both directions have a switch under Settings. That means 7.2 is additive for a Cowboy site rather than a fork in the road. When the four core content abilities arrive, they show up as tools alongside Cowboy's own, with the caveat that abilities from other sources run their own permission checks and are not undoable. If you prefer to connect through the official adapter, Cowboy's tools are there too, and nothing you set up is wasted. And the plugin still runs on WordPress 6.2 and PHP 8.0 with no Composer or Node.js, so sites that will not be on 7.2 for a while lose nothing. The question to ask in December is the same as today: do you want a working toolset with undo, or a framework to build one on? You can have both. ## FAQ **Does WordPress 7.2 include an MCP server?** No. WordPress 7.2 adds core-registered content abilities and is bringing the Secrets API into core, but the MCP endpoint itself comes from the official MCP Adapter, a separate plugin on WordPress.org since 2 October 2026 that requires WordPress 6.9 or newer. The adapter exposes whatever abilities a site registers and provides no AI features or tools of its own. **When is WordPress 7.2 released?** The official schedule lists Beta 1 on 20 October 2026, Beta 2, 3 and 4 on 27 October, 3 November and 10 November, release candidates on 17 and 24 November and 1 December, and the final release on 8 December 2026. Features that are not ready by Beta 1 usually move to a later release. **What are the WordPress 7.2 core content abilities?** Four planned abilities split CRUD-style — core/content-query, core/content-create, core/content-update and core/content-delete — each annotated as read-only or destructive so an MCP client can tell a query from a delete. They cover posts, pages and other content types, and are already testable in the canonical AI plugin, which renamed core/read-content to core/content-query in version 1.4.0. They do not cover WooCommerce, media, plugins, users, the database or undo. **Do I still need an MCP plugin after WordPress 7.2?** If you want an AI agent to do more than query, create, update and delete content — manage WooCommerce, update plugins safely, read logs, run security scans — or you want confirmation, dry runs, undo and checkpoints, then yes. The adapter is the framework; the tools and the safety layer come from plugins. Cowboy MCP registers its tools as abilities, so it works through the adapter as well as directly. **Does the Secrets API affect how Claude or ChatGPT connect to my site?** No. The Secrets API stores provider keys that your site uses to call AI models, mainly for the AI plugin and developers on the PHP AI Client. MCP apps such as Claude, ChatGPT and Cursor authenticate to your site with an OAuth sign-in or an API key, which the Secrets API does not touch. --- Canonical URL: https://cowboymcp.com/compare Title: WordPress MCP Plugins Compared (October 2026) Last updated: 2026-10-13 # WordPress MCP plugins compared ## Which WordPress MCP plugins exist in 2026? As of 5 October 2026, fourteen plugins in the WordPress.org directory ship a working MCP server for WordPress, and the three biggest AI plugins in the directory — AI Engine, Angie, and the official AI plugin — sit beside them rather than among them, because MCP is either one module of a larger product or not shipped at all. The table lists every one of them with live numbers from the WordPress.org plugin API and the facts each vendor states in its own listing. Nothing in it is an editorial score: installs, ratings, and dates are the directory's; tool counts are the vendors' own claims; and the undo, endpoint, OAuth, and Abilities API columns summarise the listing text on the fetch date, with Cowboy MCP (this site) held to exactly the same wording. Two things help when reading it. Active installs are WordPress.org's rounded buckets, so "10,000+" means somewhere between ten and twenty thousand. And the category is young: the oldest entry was added in December 2025 and thirteen of the fourteen arrived in 2026 — the official MCP Adapter only on 2 October, so the install column measures momentum at least as much as maturity. WordPress.org MCP plugins compared — directory data and listing-stated facts, 2026-10-05 Plugin | Active installs | Rating (n) | Added | Model / price | Tools (vendor claim) | Undo / rollback | Where the endpoint runs | OAuth | Abilities API | Live Preview | WPVibe | 50,000+ | 100 (97) | 2026-04-20 | Free plugin; the hosted relay service is freemium — the free plan includes every tool with a daily allowance of WordPress actions, and optional paid plans raise the allowance | — | Theme-file backup on publish and trash for deletes; no per-change undo | WPVibe cloud relay (Cloudflare-hosted) forwarding to your site's REST API | Relay sign-in by magic link; no on-site OAuth server | Consumes abilities registered by other plugins | No | MCP Adapter | 40,000+ | — (0) | 2026-10-02 | Free; the official WordPress.org plugin (AI Building Blocks for WordPress), in the directory since 2 October 2026; requires WordPress 6.9+ | — | None stated | Your site — built-in HTTP transport (plus STDIO) | Not stated — clients authenticate as a WordPress user | Built on it — the official Abilities-to-MCP bridge | No | Royal MCP | 10,000+ | 100 (7) | 2026-01-14 | Free (GPL) core; paid Royal MCP Pro tier (launched September 2026, per-site and agency licences) | 200+ (90 core + 136 integration) | Undo tokens reverse the last delete or reorder within 72 hours (mcp_undo_last_operation) | Your site — /wp-json/royal-mcp/v1/mcp | Yes — OAuth 2.0 with dynamic client registration, or API-key header | Consumes — surfaces abilities registered by other plugins alongside its own tools | Yes | Easy MCP AI | 10,000+ | 100 (11) | 2026-03-25 | Free; listing states no paid tiers and no usage limits; acquired by Themeisle (September 2026) | 280+ | Change history with before/after snapshots and diffs; no undo tool stated | Your site — /wp-json/easy-mcp-ai/v1/mcp | Yes — OAuth 2.0/2.1 with PKCE and dynamic client registration, or Bearer token | Consumes — exposes the abilities you select from other plugins | No | Enable Abilities for MCP | 4,000+ | 100 (12) | 2026-03-24 | Free; requires WordPress 6.9+ and the MCP Adapter plugin | 112 abilities in 21 categories | None stated | Your site, served by the official MCP Adapter | Yes — embedded OAuth 2.1 server (since 2.1), or Application Password / Bearer token | Built on it | No | StifLi Flex MCP | 800+ | 100 (4) | 2025-12-08 | Free (optional Copilot/Chat on your own AI key) | 122+ built-in (200+ with integrations) | Before/after snapshot change log with one-click rollback, redo, and session rollback; no database checkpoints | Your site | Yes — OAuth 2.1 with PKCE and dynamic client registration, or Application Password | Consumes — imports abilities registered by other plugins | No | WSP MCP – AI Agents Connector | 2,000+ | 100 (5) | 2026-07-13 | Free | 190+ | None stated; audit log in your own database (90-day retention since 2.7) | Your site — native endpoint (Streamable HTTP) | Yes — built-in OAuth 2.1 server (since 2.8, off until an admin enables it), or plugin key / Application Password | No — the adapter/Abilities path was removed in 2.2 | No | miniOrange Secure MCP Server | 5,000+ | 100 (7) | 2026-06-04 | Free; listing states all features included with no restrictions | 300+ | None stated; audit trail and post-revision restore tools | Your site — /wp-json/mosmcp/v1/mcp | Yes — self-hosted OAuth 2.1 with PKCE and dynamic client registration, or API key | Built on it ("Abilities API native") | No | NIBWP | 300+ | 100 (2) | 2026-06-19 | Free core; paid NibWP Pro adds plugin integrations and skills | — | None stated | Your site, bundled official MCP Adapter | No — WordPress Application Passwords | Built on it | No | AtlasMCP | 200+ | — (0) | 2026-01-02 | Free core; paid Pro with a 7-day trial | — | None stated; Pro adds a backups manager for its error-fix flow | Your site — /wp-json/awfah_mcp/mcp, bundled MCP Adapter | Yes — OAuth 2.1 with PKCE and dynamic client registration, or JWT / Application Password | Built on it; consumes other plugins’ abilities in the free version | Yes | Agent Abilities for MCP | 500+ | 90 (2) | 2026-07-02 | Free; listing states no paid tier | 179 governed abilities (85 core + 94 integrations) | None stated; deletes go to trash; audit log | Your site, served by the official MCP Adapter | Yes — OAuth, or Application Password | Built on it | Yes | Cowboy MCP (this site) | 600+ | 100 (4) | 2026-07-03 | Free; no Pro tier | 203 | Per-change undo journal, one-click database checkpoints, audit log | Your site — /wp-json/cowboy-mcp/v1/endpoint | Yes — OAuth 2.1 (optional), or API key | Both ways since 1.6.4 — registers its tools as abilities and consumes other plugins’ abilities | Yes | Invizo MCP | 100+ | 100 (1) | 2026-06-19 | Free; no paid tier stated in listing | — | None stated; dry-run previews and confirm flags for destructive operations | Your site — /wp-json/mcp/invizo, bundled official MCP Adapter | No — WordPress Application Passwords (administrator-only) | Built on it | No | AICOM – AI Commander | 60+ | 100 (1) | 2026-04-21 | Free; no paid tier stated in listing | 87+ | Automatic snapshot before every update, trash, delete, or edit; one-call restore of the previous version or one-click restore of a whole session | Your site — /wp-json/aicom/v1/mcp (fallback /?aicom=1); also an OpenAPI schema | No — scoped API keys stored as bcrypt hashes (Bearer) | Not stated | No | Context: the three biggest AI plugins in the directory — adjacent, not standalone MCP servers | AI Engine | 90,000+ | 98 (869) | 2022-12-27 | Free core; paid Pro — MCP is one module of a chatbot/AI framework | — | Approval dialog before changes in its Workspace; no undo stated | Your site | Yes — OAuth for desktop clients, or bearer token | Consumes — an MCP setting turns registered abilities into MCP tools | No | Angie – Agentic AI | 100,000+ | 62 (18) | 2025-09-17 | Free tier with daily renewing credits; in-admin agent by Elementor | — | Test Mode preview and manual approval to production; snippet revisions | In-admin agent backed by a cloud service; an 'Angie MCP' connection for external MCP clients arrived in the 1.1.x releases (August 2026) | n/a | Both — registers its tools as abilities (1.1.12) and discovers abilities other plugins register | No | AI (WordPress canonical plugin) | 50,000+ | 92 (9) | 2025-12-02 | Free canonical plugin; MCP is listed under "Developer Tools Coming Soon" — no MCP server today; the official MCP Adapter is a separate directory plugin since October 2026 | — | n/a | n/a — no MCP server | n/a | Built on it (Abilities Explorer) | Yes | Data: WordPress.org plugin API, fetched 5 October 2026 (active installs, rating, number of ratings, date added, and Live Preview from the directory; everything else from each plugin's own listing text on that date). The machine-readable version, including 30-day downloads, last-updated dates, and tested-up-to versions, is at /data/wordpress-mcp-plugins.json. ## What about MCP options outside the WordPress.org directory? Several of the most-discussed WordPress MCP servers are not in the directory at all — they ship from GitHub, from a vendor's own site, or as part of a hosting platform — so a directory-only view would miss the most-starred community projects, the paid builder-focused servers, and every hosted option. The figures are vendor claims from the linked primary sources, not directory data, checked on 5 October 2026. The official WordPress MCP Adapter used to sit here; it joined the directory on 2 October 2026 and now appears in the first table. WordPress MCP options outside the WordPress.org directory, 2026-10-05 Option | Where you get it | Model / price | Tools (vendor claim) | Undo / rollback | Notes | Source | Novamira | GitHub release ZIP, installed by hand | Free core under AGPL-3.0; paid Pro add-on from €49 a year (Personal) to €149 a year (Agency) | 38 abilities | No undo journal or checkpoints; README guidance is dev/staging with backups | Self-hosted; built on the Abilities API and the bundled official MCP Adapter; execute-php, WP-CLI, and file abilities; OAuth sign-in | README | WordPress.com MCP | Built into WordPress.com | Included on every paid WordPress.com plan | see tools reference | None stated | Hosted platform; OAuth 2.1; the same Automattic family covers WooCommerce and Pressable | tools reference | InstaWP InstaMCP | Built into InstaWP hosting | Sandbox plan and above | 43 | None stated for MCP itself (staging sites recommended) | Hosted platform; one dashboard toggle; connection URL with an embedded token | product page | EMCP Tools | GitHub (free) + Freemius (Pro) | Free up to 196 MCP tools; paid Pro unlocks all 277, annual or lifetime licences | 196 free / 277 Pro | Snapshots before brand-kit changes with rollback; a change ledger (vendor claim) | Self-hosted; Elementor-focused plus WordPress core; OAuth 2.1 sign-in | emcptools.com | Respira | Direct from respira.press | Paid per-site tiers from €71 a year (1 site) to €451 a year (25 sites), with a 7-day full trial | 210+ (catalog of 320+) | SafeEdit preview/approve and TimeSnap rollback (vendor claim) | Self-hosted; 17 page builders; the MCP server is open source on GitHub | GitHub | NibWP Pro | Direct from nibwp.com | Paid upgrade to the free NIBWP directory plugin — €49 a year per site, or €79 with all skills | 190+ across 66 integrations | None stated | Self-hosted; adds schema-typed integrations (WooCommerce, Elementor, Bricks, ACF, Yoast, Rank Math…) and builder skills | nibwp.com | The self-hosted vs hosted comparison explains what separates the platform rows from the plugin rows: who sits in the data path, whether a Node.js process is involved, and what happens to local and staging sites. ## How should you choose? The right WordPress MCP plugin depends on what you need the agent to be trusted with, and the directory now holds a credible option for each of five distinct needs. Grouping by need is fairer than ranking, because these plugins optimise for different things. - Production safety and reversibility. If the agent will touch a live site, look for a stated way back. Cowboy MCP journals every change and takes one-click database checkpoints; StifLi Flex MCP records a before-and-after snapshot per change with one-click undo, redo, and whole-session rollback; Royal MCP issues undo tokens that reverse the last delete or reorder within 72 hours; AICOM snapshots a post, term, or Elementor template before every write and can restore a whole session. Outside the directory, EMCP Tools and Respira both advertise snapshots with rollback. - Free with no metering. If you want no paid tier and no daily cap, Easy MCP AI has the largest free toolset, Agent Abilities for MCP ships everything off by default at no cost, and Cowboy MCP is free with no Pro tier — and WSP MCP, miniOrange, and Enable Abilities for MCP say the same in their listings. WPVibe's plugin is free but its relay meters actions per day on the free plan; Royal MCP, NIBWP, and AtlasMCP keep part of the product behind a paid tier. - Hosted convenience. If you would rather not run an endpoint, WPVibe's relay gives one-click authorisation for any self-hosted site, WordPress.com includes MCP on every paid plan, and InstaWP's InstaMCP is a dashboard toggle on its platform. The trade is a third party in the data path, which the self-hosted vs hosted page weighs in detail. - Raw power on staging. If the job is building rather than operating, Novamira hands the agent PHP execution, WP-CLI, and file access and tells you to use it on dev and staging copies with backups; Angie's opt-in Super Admin Mode opens the file system, database, and PHP layer from inside wp-admin; Cowboy MCP's Power mode lifts its WP-CLI and file guardrails while keeping the checkpoints and undo journal in place. - Official and Abilities-first. If staying closest to core matters most, the MCP Adapter — published by WordPress.org and in the directory since 2 October 2026 — is the official bridge, and Enable Abilities for MCP, Agent Abilities for MCP, NIBWP, AtlasMCP, and miniOrange all build on the Abilities API; Easy MCP AI, StifLi, Royal MCP, and WPVibe consume abilities that other plugins register. Cowboy MCP, since 1.6.4, does both: it keeps its own typed tool registry for guardrails and undo, registers every allowed tool as a cowboy-mcp/* ability, and consumes the abilities other plugins register. ## How does Cowboy MCP compare head-to-head? Cowboy MCP's own position in the table is easy to state: it sits in the lower half of the table by installs, added to the directory in July 2026; it is free with no Pro tier; the endpoint stays on your site with OAuth optional; it ships 203 typed tools; and it is one of the few plugins in the category with a per-change undo journal and database checkpoints. Since 1.6.4 it also bridges to the Abilities API in both directions — its tools are registered as abilities, and other plugins’ abilities appear as tools — while keeping its own registry. For the detailed trade-offs against individual rivals, this site publishes nine comparisons, each with a dated, sourced table: - Cowboy MCP vs WPVibe — native endpoint or hosted relay, and what metering means day to day. - Cowboy MCP vs Easy MCP AI — two free, self-hosted endpoints: change history against per-change undo and checkpoints. - Cowboy MCP vs Royal MCP — free with no Pro tier against a free core with a paid tier, and what each can undo. - Cowboy MCP vs AI Engine — a focused MCP plugin against a broad AI framework whose MCP server is one module. - Cowboy MCP vs InstaWP MCP — any self-hosted site against a platform-integrated toggle. - Cowboy MCP vs the WordPress MCP Adapter — tools against abilities, and the Node.js proxy question. - Cowboy MCP vs Novamira — guardrails and undo against direct PHP execution on staging. - Cowboy MCP vs StifLi Flex MCP — the two directory plugins that both lead with undo. - Self-hosted vs hosted WordPress MCP — the four architectures and who is in your data path. ## How is this data collected? Every number in the first table comes from two public WordPress.org endpoints, and every qualitative cell is a paraphrase of the plugin's own listing, so anyone can re-run the collection and check the result. The directory numbers come from the plugin information API (active installs, rating, number of ratings, date added, last updated, tested-up-to) and the 30-day download totals from the download-stats API, summed over the trailing thirty days; Live Preview is read from the public listing page. The model, tool-count, undo, endpoint, OAuth, and Abilities API columns are taken from each listing's description, FAQ, and changelog on the fetch date, and where a listing does not state something the cell says so rather than guessing. Tool counts are labelled vendor claims because they are not independently counted and vendors count differently — some count abilities, some count tools, some add a plus. Cowboy MCP's figure is the count published on this site. The result is published as a dataset at /data/wordpress-mcp-plugins.json, with a generated date, the source endpoints, and one record per plugin holding the raw numbers and the same listing-sourced fields as the table, so it can be loaded into a spreadsheet or cited directly. The page and the file are refreshed monthly, and the date at the top of the page changes when they are. If you find an error, or a vendor ships a change between refreshes, open an issue on the Cowboy MCP GitHub repository with a link to the primary source and the row will be corrected. ## FAQ **Is there an official WordPress MCP plugin?** Yes, since 2 October 2026. The MCP Adapter, published by WordPress.org as part of the AI Building Blocks for WordPress initiative, is now a directory plugin; it turns the abilities a site registers into MCP tools, resources, and prompts, but provides no AI features of its own, so it needs abilities from core or another plugin to be useful. WordPress core itself still ships no MCP endpoint, and the canonical AI plugin lists MCP under its coming-soon developer tools; WordPress 7.2 (due 8 December 2026) adds core content abilities for querying, creating, updating, and deleting content. Several directory plugins build on the adapter and the Abilities API, including Enable Abilities for MCP, Agent Abilities for MCP, NIBWP, AtlasMCP, and miniOrange. **Which WordPress MCP plugins are free?** Nine directory plugins state in their listings that they are free with no paid tier mentioned: Cowboy MCP, Easy MCP AI, Enable Abilities for MCP, StifLi Flex MCP, WSP MCP, miniOrange Secure MCP Server, Agent Abilities for MCP, AICOM, and Invizo MCP. The official MCP Adapter has no paid tier either. Royal MCP, NIBWP, AtlasMCP, and AI Engine are free at the core with a paid Pro tier, and WPVibe's plugin is free but its relay service meters actions per day on the free plan. Outside the directory, Novamira's core is free, while WordPress.com MCP, InstaWP, Respira, EMCP Pro, and NibWP Pro are paid. **Which WordPress MCP plugins work on localhost?** Any plugin whose endpoint runs on your own site works on a local install with clients that run on the same machine — Claude Code, Cursor, Codex, and Gemini CLI — because they connect over plain HTTP — with an API key, an application password, or an OAuth sign-in in a browser on the same machine — and need no public URL, and Claude Desktop can reach a local endpoint through the small mcp-remote bridge. Relay and platform options cannot: WPVibe needs a URL its cloud can reach, and WordPress.com and InstaWP MCP exist only on those platforms. **Which WordPress MCP plugins need a public HTTPS site?** Anything that connects from a vendor's servers rather than from your machine. The claude.ai and ChatGPT custom connectors authorise over OAuth from Anthropic's and OpenAI's backends, so every plugin with an on-site OAuth server needs a public HTTPS address for that path, and several listings warn that hosting firewalls or Cloudflare's AI-bot blocking can break it. WPVibe's relay likewise needs a reachable site, and the hosted platforms are public by nature. Terminal clients, and Claude Desktop through a local bridge, are the exception. **Do I still need an MCP plugin now that the official MCP Adapter is in the directory?** Usually, and you can run both. The adapter is infrastructure: it exposes only the abilities a site registers and opts in, and leaves confirmation, undo, and logging to the abilities and the client. If you need a working toolset with a way back, install a directory plugin alongside it; Cowboy MCP has registered its tools as public abilities since 1.6.4, so with the adapter active those tools appear through it as well, and nothing you set up is wasted. **How often is this comparison updated?** Monthly. The numbers are re-fetched from the WordPress.org plugin API, the qualitative columns are re-checked against each listing at the same time, and the page's last-updated date and the generated field in the JSON file record the fetch date. If a vendor changes pricing, adds undo, or ships OAuth between refreshes, open an issue on the Cowboy MCP GitHub repository with a link to the source and the row will be corrected. --- Canonical URL: https://cowboymcp.com/compare/self-hosted-vs-hosted-wordpress-mcp Title: Self-Hosted vs Hosted WordPress MCP — Which to Choose? Last updated: 2026-09-09 # 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 and Royal MCP . A local-proxy setup pairs a plugin with a Node.js process on your own machine — the official WordPress mcp-adapter with the mcp-wordpress-remote proxy . A hosted relay keeps the plugin on your site but routes traffic through the vendor's cloud — WPVibe . A hosted platform builds MCP into managed hosting with no plugin for you to manage — WordPress.com and InstaWP . ## 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 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 , 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 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 — 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 one-click 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 , and Royal MCP 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 , so it depends on an active subscription. The WPVibe relay 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: 9 September 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 ) | 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 ) | 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 , Royal MCP ; local proxy — WordPress mcp-adapter with mcp-wordpress-remote , and Novamira, which builds on the same adapter and connects either directly or through mcp-remote; hosted relay — WPVibe ; hosted platform — WordPress.com and InstaWP . ## 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 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 203 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. --- Canonical URL: https://cowboymcp.com/about Title: About Cowboy MCP — the Free WordPress MCP Server Plugin Last updated: 2026-10-05 # About Cowboy MCP Cowboy MCP is a free, open-source WordPress plugin that turns your self-hosted WordPress site into an MCP (Model Context Protocol) server, so AI agents like Claude, ChatGPT, Gemini, Cursor, and Codex can manage the site in plain English — with per-change undo and database checkpoints. Instead of clicking through wp-admin, you describe the work in plain English — publish a post, update products, run a security scan, fix a broken page — and your agent carries it out directly on your site. It's built for people who run real WordPress sites — store owners, agencies, and developers — who'd rather delegate site work than do it by hand. Everything runs on your own server, with no accounts, no proxy, and no telemetry. ## What is Cowboy MCP? Cowboy MCP is a WordPress plugin that acts as an MCP server — a standard endpoint that AI agents connect to. Once installed on your self-hosted site, it exposes 203 tools an agent can call to manage content, run WooCommerce, administer the site, and fix problems. It's free, GPL-licensed, and runs entirely inside your own WordPress install. Property | Value | Category | WordPress plugin · MCP server | Version | 1.7.3 | Tools | 203 | License | GPL-2.0 | Price | Free — no paid tier | Requirements | WordPress 6.2+ · PHP 8.0+ | Distribution | WordPress.org | ## Who makes it? Cowboy MCP is built by Andrew Ivanov, a WordPress developer who builds WordPress and MCP tooling. They authored the plugin and publish it on the WordPress.org plugin directory under the contributor handle februality. You can browse the project source and other projects from the WordPress.org profile or GitHub account. ## How is it built? Cowboy MCP runs entirely inside WordPress as a native REST endpoint — there's no Node proxy, no hosted relay, and no telemetry. Your AI client connects straight to your server, and nothing about your site leaves it. Safety is layered in: safe mode confirms destructive actions, any change previews as a dry run, an audit log records every call, and a per-change undo journal plus database checkpoints roll changes back. See the full security and safety model for how each safeguard works. ## Where else can you find it? Cowboy MCP lives on the WordPress.org plugin directory, which handles installation and updates. The source code is on GitHub, and the server is listed in the Glama MCP directory. These are the canonical places to install it, read the code, file an issue, or verify what it does — all linked below. - WordPress.org plugin page — install and update - GitHub repository — source code and issues - Glama MCP directory — MCP server listing ## Press facts Writing about Cowboy MCP? Here are the essentials, ready to copy. - Name: Cowboy MCP - What it is: Cowboy MCP is a free, open-source WordPress plugin that turns your self-hosted WordPress site into an MCP (Model Context Protocol) server, so AI agents like Claude, ChatGPT, Gemini, Cursor, and Codex can manage the site in plain English — with per-change undo and database checkpoints. - Maker: Andrew Ivanov - License: GPL-2.0, free with no paid tier - Logo: https://cowboymcp.com/android-chrome-512x512.png - Website: https://cowboymcp.com - Contact: questions and press requests via the WordPress.org support forum --- More: https://cowboymcp.com/guides (all guides) · https://cowboymcp.com/compare (every head-to-head) · https://cowboymcp.com/skills (agent skills) · https://cowboymcp.com/news (release notes) · https://cowboymcp.com/news/feed.xml (Atom feed).