How to Connect an AI Agent to WordPress Safely (MCP, REST API and Permissions)

The safest way to connect an AI agent to WordPress today is WordPress’s own Abilities API (WordPress 6.9 and later) plus the official MCP Adapter plugin. The adapter exposes only the abilities you choose as tools that any MCP-compatible agent can call, such as Claude, Cursor or VS Code. The agent connects as a dedicated, low-privilege WordPress user with an Application Password, never as your admin account. If you only need a script or automation to read and write posts, the REST API with an Application Password also works. The permission rules are the same either way.

This guide explains the building blocks, walks through the setup, and covers the permission rules that keep an agent from becoming a security problem.

“AI agent for WordPress” can mean three different things

Search results mix these together, so it helps to pick yours first:

The third option is the powerful one. It’s also the one where permissions matter most, because the agent acts as a logged-in user.

The building blocks: MCP, the Abilities API and the MCP Adapter

Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools and data. An MCP server offers tools (actions the AI can call), resources (data it can read) and prompts (reusable templates). See modelcontextprotocol.io.

The WordPress Abilities API, available since WordPress 6.9, is a standard way to register “abilities”: named units of functionality with a JSON Schema for input and output, a category, a permission callback and an execute callback. The Abilities API handbook describes it as a central registry that plugins, themes and external systems like AI agents can discover. WordPress 6.9 ships three core abilities: core/get-site-info, core/get-user-info and core/get-environment-info.

The WordPress MCP Adapter is the official package that turns registered abilities into MCP tools and resources. In February 2026 the WordPress Developer Blog published a full introduction to the MCP Adapter. Once active, it registers a default server, mcp-adapter-default-server, with three tools: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info and mcp-adapter-execute-ability. The agent discovers what it is allowed to do, reads the details, then executes.

In short: WordPress MCP is the MCP Adapter exposing your site’s registered abilities to AI agents, each ability guarded by its own permission check and the connecting user’s capabilities.

MCP Adapter or the plain REST API?

For AI agents, the adapter is the better default. You decide what the agent can do one ability at a time, instead of handing it everything a role can do.

Step by step: connect an MCP client to WordPress

1. Check the basics

• WordPress 6.9 or later (the Abilities API requires it).
• HTTPS on the site. Application Passwords are sent with Basic Auth and are meant for requests over https.
• A staging copy to try this on first, and a fresh backup of production.

2. Install the MCP Adapter

The WordPress Developer Blog’s guide installs the adapter as a plugin from the Releases page of its GitHub repository. Activate it and the default MCP server and its three tools are registered. Your site’s MCP endpoint for HTTP clients is /wp-json/mcp/mcp-adapter-default-server.

3. Choose which abilities the agent can see

By default, an ability is only available through the default server if its registration includes meta.mcp.public = true. That opt-in is your main safety switch. Here’s a small read-only ability that lists recent drafts, exposed to MCP and limited to users who can edit posts:

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'content-review', array(
        'label'       => 'Content review',
        'description' => 'Read-only abilities for reviewing content.',
    ) );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'myplugin/list-drafts', array(
        'label'               => 'List drafts',
        'description'         => 'Returns the 20 most recent draft posts: ID, title, last modified.',
        'category'            => 'content-review',
        'input_schema'        => array(),
        'output_schema'       => array( 'type' => 'array', 'items' => array( 'type' => 'object' ) ),
        'execute_callback'    => function () {
            $drafts = get_posts( array( 'post_status' => 'draft', 'numberposts' => 20 ) );
            return array_map( function ( $post ) {
                return array( 'id' => $post->ID, 'title' => $post->post_title, 'modified' => $post->post_modified );
            }, $drafts );
        },
        'permission_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
        'meta'                => array( 'mcp' => array( 'public' => true ) ),
    ) );
} );

To expose the three core abilities, the same guide uses the wp_register_ability_args filter to add the mcp.public flag to them. They’re a good, harmless first test.

4. Create a dedicated user and an Application Password

Create a new WordPress user just for the agent, for example ai-agent, with the lowest role that covers the job. Author or Editor is enough for content work. Use a custom role if you need something in between. Then open that user’s profile (Users > Edit User), and under Application Passwords create one named after the client, such as “Claude Code – laptop”. Application Passwords have shipped with WordPress since 5.6, per the REST API authentication handbook.

An Application Password carries all the capabilities of its user. That’s why the dedicated user matters more than anything else in this guide.

5. Connect the AI client

There are two transports:

• Local sites (STDIO): the client runs WP-CLI directly, with wp mcp-adapter serve --server=mcp-adapter-default-server --user=<user> and a --path to your install. No password is involved.
• Remote sites (HTTP): the client runs the @automattic/mcp-wordpress-remote proxy through npx, which needs Node.js on your machine and three environment variables.

The HTTP configuration looks like this in Claude Desktop, Claude Code (.mcp.json) or Cursor. VS Code uses a servers key instead of mcpServers:

{
  "mcpServers": {
    "my-wordpress": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "ai-agent",
        "WP_API_PASSWORD": "<application password>"
      }
    }
  }
}

Don’t commit a file like this with a real password in it. Keep the value in a local environment file that’s excluded from version control, and have the client read it from there.

6. Start read-only, then test

Restart the client and ask it to list the abilities it can see. It should call the discover tool and return only what you exposed. Run a read-only ability, check the result, and only then add abilities that change content, one at a time, on staging first.

Permissions: the rules that keep this safe

MCP clients act as logged-in WordPress users, so treat them as part of your site’s attack surface. The MCP Adapter guide’s own advice, plus what I add on client sites:

• Least privilege. A dedicated user with the minimum role, and a permission_callback on every ability that checks the minimum capability. Never return true for anything destructive.
• Read-only over the internet. For HTTP connections, prefer read-only abilities: diagnostics, reports, content access. Keep write abilities to staging or tightly scoped tasks.
• One password per client. Name each Application Password after the device or tool, and revoke it the moment that device or tool is retired.
• Humans approve publishing. Let the agent create drafts. Publishing, deleting and settings changes stay with a person.
• Log usage. Know what was called and when, so you can spot anything odd.

The reason this matters: an agent’s password is a real login. If it leaks, the attacker gets whatever that user can do, which is exactly what a compromised admin account can do if you gave the agent admin rights.

How I use this in my own workflow

I use AI agents with WordPress in my own work, through exactly this stack: the MCP Adapter plugin on the site, an Application Password for the agent’s user, and @automattic/mcp-wordpress-remote as the bridge. A few habits have stuck:

• Credentials never touch the config or the chat. The MCP config calls a small loader script that reads a local, git-ignored environment file and passes the proxy only the variables that one connection needs.
• Staging first on client sites, a confirmed backup before anything site-wide, and the agent asks before any destructive change.
• Page-builder data needs care. On Elementor sites, layout data lives in post meta. After an agent updates it, clear Elementor’s cache (the REST route is DELETE /elementor/v1/cache), or the front end may keep showing the old version.

This is the core of the AI-powered workflows I build: agents that ship content, UI components and WordPress features, with people deciding what goes live.

Practical things to let an agent do

• Diagnostics: read environment info (WordPress and PHP versions, active plugins) before an update or a support request.
• Content drafts: create drafts from an approved brief, with categories and excerpts filled in, ready for human review.
• Content QA: list drafts missing a meta description, featured image or internal links.
• Automation agents: the same idea works in n8n. For example, an n8n agent for WhatsApp leads can use tools that read from or write to your site, under the same permission rules.

FAQ

Does WordPress have a built-in AI agent?

No. WordPress 6.9 includes the Abilities API, which lets AI agents and other tools discover and run site functionality, plus three core abilities. The MCP Adapter that connects those abilities to AI clients is a separate official package. The agent itself is the AI client you connect.

Is it safe to give an AI agent access to WordPress?

It can be, if the agent uses a dedicated low-privilege user, sees only the abilities you expose, works read-only over the internet where possible, and leaves publishing to a person. Never connect an agent with your own admin account.

Do I need the MCP Adapter, or is the REST API enough?

For scripts and automation tools, the REST API with an Application Password is enough. For AI clients, the MCP Adapter is better because the agent only sees the abilities you chose, each with its own permission check and description.

Which AI plugin is best for WordPress?

It depends on the job. A visitor chatbot, an in-editor writing assistant and an external agent that manages the site are different tools. For the third, start with the official Abilities API and MCP Adapter before adding third-party connectors.

Where this fits

Connecting an agent is easy. Making sure the site, users and integrations around it are in good shape is the real work. If you want a structured look at all of it, start with an audit of your site and stack, or ask me for a free audit of your WordPress stack.