Connecting AI Assistants to WordPress Safely: MCP Setup and Guardrails

An AI assistant that can read and edit a WordPress site is genuinely useful. It can audit two hundred posts in minutes, fix metadata in bulk, restructure categories and draft content directly into the editor. It can also delete a page, publish a draft early or change a setting nobody noticed — quickly and confidently. The difference between those outcomes is almost entirely in the setup.

This post explains how AI assistants connect to WordPress through the Model Context Protocol (MCP), the two main ways to set it up, and the guardrails we use before any agent works on a site. It is part of our AI for WordPress series.

What MCP is, in one paragraph

MCP is an open standard that lets AI applications discover and use tools in a consistent way. A WordPress site, or a small server sitting in front of it, describes the actions it offers — list posts, update a post, upload media — and an AI client such as Claude, Cursor or Codex can call those actions on your behalf. The AI does not get a login screen; it gets a defined set of tools with whatever permissions the connection carries.

Option 1: the official MCP Adapter plugin

The WordPress MCP Adapter is the official package from the WordPress AI team, and since early October 2026 it installs directly from the WordPress.org plugin directory. It turns the site itself into an MCP server, built on the Abilities API: every ability registered by core or a plugin can be offered to an AI client as a tool. It needs WordPress 6.9 or newer.

The important design choice is that nothing is exposed by default. An ability has to be explicitly marked as public for MCP before an agent can see it. That makes it a good fit for agencies building custom functionality: you decide exactly which actions an agent may run, and the site’s own permission checks still apply.

The WordPress 7.0 release added more core abilities, which makes this route more useful over time. Our post on what WordPress 7.0’s AI features mean for agencies covers the Abilities API in more detail.

Option 2: an MCP server that uses the REST API

The other common approach is an MCP server that runs outside WordPress — on your computer or a small server — and talks to the site through the standard REST API, authenticated with an application password. Nothing needs installing on the site, which makes it quick to use across many client sites, and what the agent can do is limited by the WordPress user the application password belongs to.

This is the setup we used to audit and fix internal links across our own blog, written up in how we fixed 10 orphaned posts with AI-assisted internal linking. It worked well for content operations; for anything touching custom business logic, the Abilities-based adapter is the cleaner long-term route.

	Official MCP Adapter	REST-based MCP server
Where it runs	Inside WordPress, as a plugin	Outside WordPress
What the agent can do	Only abilities you mark public	Whatever the REST API allows for that user
Setup per site	Install plugin, choose abilities	Create user and application password
Best for	Custom workflows, long-term client features	Content operations across many sites
Main risk	Exposing an ability too broadly	Giving the user too high a role

The guardrails we would not skip

1. A dedicated user with the lowest role that works

Never connect an agent as the client’s main administrator. Create a separate user, named so it is obvious in logs, and give it the lowest role that can do the job — usually Editor for content work. Our guide to customising WordPress user roles shows how to create a tighter custom role if Editor is too broad.

2. Application passwords, not real credentials

WordPress application passwords can be created per user, named per tool and revoked individually without affecting anyone’s login. Use one per agent connection, and revoke it when the job is done.

3. Expose the minimum

With the MCP Adapter, mark only the abilities the task needs as public. With a REST-based server, prefer tools that can be limited to reading where the job allows it. An audit needs read access; it does not need delete.

4. Staging first for anything structural

Bulk edits, category changes, settings and anything involving code belong on staging before production, exactly like a code deployment. Our staging to production workflow applies unchanged.

5. One test change, then the batch

Ask the agent for its plan, approve it, let it make one change, inspect the result, then run the rest. Prefer targeted edits — replace this exact sentence — over rewriting whole posts, so nothing else can change by accident.

6. Revisions on, and a written log

Revisions are the undo button for content changes. Keep a short log of what was changed, where and why, so a person who was not in the session can review it. An activity log plugin adds a second record.

7. Treat site content as data, not instructions

Agents read post content, comments and form submissions. Some of that text is written by strangers. A good assistant treats it as information, never as instructions, but the safest setup assumes something may try: limit permissions so a manipulated agent cannot do much harm. If a client site has ever been compromised, read our malware response playbook before connecting anything.

Good first jobs for an agent

• Internal link audits and orphaned post fixes.
• Finding posts with missing excerpts, featured images, alt text or SEO descriptions.
• Category and tag clean-ups with a reviewed mapping.
• Content inventories and reports for a redesign.
• Drafting posts into the editor as drafts, never published directly.

Leave plugin installs, user management, settings and anything payment-related to people until your process is proven.

Frequently asked questions

Can an AI assistant break my site?

It can do anything the connected user and exposed tools allow. That is why the role and tool choices matter more than the AI model you use.

Do I need the MCP Adapter to use AI with WordPress?

No. A REST-based MCP server works without installing anything on the site. The adapter is better when you want tightly defined, custom actions.

Should agents publish content directly?

We recommend drafts or scheduled posts that a person reviews. Direct publishing removes the last human check.

How do I remove access afterwards?

Revoke the application password from the user’s profile, and remove or demote the dedicated user if it is no longer needed.

Want this set up across your client sites?

We set up AI connections, custom abilities and safe content-operations workflows for agencies, white label. It fits naturally into a maintenance and support plan, or tell us what you want an agent to do and we will scope the guardrails with you.