WordPress MCP Adapter: Connect Claude Code and Cursor to Your Site

The WordPress MCP Adapter lets AI tools like Claude Code and Cursor find and run actions on your WordPress site. It takes the abilities you register with the Abilities API and shares them over the Model Context Protocol (MCP).

Here’s the full setup: install the adapter, expose one ability, find the default endpoint, log in with an Application Password, and run a few safety checks.

Already wired an AI tool to a WordPress site? Skip to the end and tell me how it went. I’d like to compare notes.

At a glance

• Needs: WordPress 6.9 or newer and PHP 7.4 or newer. WordPress 6.9 includes the Abilities API in core.
• Plugin: the official MCP Adapter from the WordPress GitHub organization. The latest release when I wrote this guide was 0.6.1.
• Opt in: an ability shows up on the default MCP server when its meta has mcp.public set to true. A broader public flag in meta works too.
• Default endpoint: /wp-json/mcp/mcp-adapter-default-server
• Login: a WordPress user and an Application Password.
• Try it on a local site first. An AI tool gets the same rights as the user you connect it with.

What MCP is, in plain terms

MCP is an open standard that gives AI apps a shared way to connect to outside tools and data. An MCP server lists the tools it offers. An MCP client, like Claude Code or Cursor, reads that list and can call those tools when you ask it to.

WordPress already has its own way to describe actions, called the Abilities API. I covered it in my first Abilities API integration post. Each ability has a name, an input schema, an output schema, a permission check, and a callback. The MCP Adapter takes those abilities and puts them in a form an MCP client can read.

Here’s how one request moves through the stack:

1. You ask Claude Code or Cursor a question.
2. The client calls the adapter’s server on your site.
3. The adapter looks up the matching ability.
4. WordPress runs that ability’s permission check for the connected user, before any code executes.
5. The result travels back to the client as structured data.

WordPress MCP Adapter diagram: a WordPress site in the center, connected to a terminal and a code editor, with lock, key, and shield icons for login and permissions

!WordPress MCP Adapter diagram: a WordPress site in the center, connected to a terminal and a code editor, with lock, key, and shield icons for login and permissions

WordPress MCP Adapter diagram: a WordPress site in the center, connected to a terminal and a code editor, with lock, key, and shield icons for login and permissions

The WordPress MCP Adapter sits between your site and AI tools like Claude Code and Cursor.

Step 1: Install the WordPress MCP Adapter

The adapter isn’t in core yet, so you add it yourself. You can install it as a plugin, or bundle it inside your own plugin as a Composer package. For a first test, I’d go with the plugin because it’s simpler.

The Composer route makes sense once you ship a plugin that depends on the adapter. Running composer require wordpress/mcp-adapter installs it alongside your own code, so the adapter travels with your plugin.

To install the plugin:

1. Download the latest release from the WordPress/mcp-adapter repository.
2. On a local or staging site, upload it as a plugin.
3. Activate it, and check that your site runs WordPress 6.9 or newer.

Heads up: the adapter is still under version 1.0, so names and commands may change from one release to the next. Before you copy anything below, read the README for the version you installed.

Step 2: Mark an ability as public for MCP

Registering an ability won’t share it with AI tools by itself. You have to opt in by adding 'mcp' => array( 'public' => true ) inside the ability’s meta array.

That flag shares the ability over MCP and nothing else. The adapter README also describes a broader public flag in meta, which the default server honors too.

Here’s a small example that only reads data. It returns the site name and tagline, and it only runs for users who can edit posts.

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'my-site', array(
        'label'       => 'My Site',
        'description' => 'Abilities for this site.',
    ) );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-site/get-site-info', array(
        'label'               => 'Get site info',
        'description'         => 'Returns the site name and tagline.',
        'category'            => 'my-site',
        'output_schema'       => array(
            'type'       => 'object',
            'properties' => array(
                'name'    => array( 'type' => 'string' ),
                'tagline' => array( 'type' => 'string' ),
            ),
        ),
        'execute_callback'    => function () {
            return array(
                'name'    => get_bloginfo( 'name' ),
                'tagline' => get_bloginfo( 'description' ),
            );
        },
        'permission_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
        'meta'                => array(
            'annotations' => array( 'readonly' => true ),
            'mcp'         => array( 'public' => true ),
        ),
    ) );
} );

The readonly annotation tells clients this ability doesn’t change anything. The permission callback runs on every call, even when the request comes from an AI tool.

Step 3: Know the default server endpoint

Once the plugin is on, the adapter sets up a default MCP server. You’ll find it at this path on your site:

https://your-site.local/wp-json/mcp/mcp-adapter-default-server

This server doesn’t list each public ability as its own tool. It offers three general tools:

• One finds the public abilities.
• One gets details about a single ability.
• One runs an ability.

The README calls them mcp-adapter/discover-abilities, mcp-adapter/get-ability-info, and mcp-adapter/execute-ability. So the client finds your ability first, then calls it.

If you’d rather list each ability as its own tool, you can register a custom server. It’s a good thing to try once the default server is working.

Step 4: Create an Application Password

Application Passwords come built into WordPress. They let an outside app log in through the REST API without your main password, and you can revoke each one on its own.

1. Open the profile page for the user the AI tool will use.
2. Scroll down to Application Passwords. Type a name like “Cursor local” and click Add.
3. Copy the password right away. WordPress only shows it once.

Tip: make a separate user for this and give it the lowest role that still passes your permission checks. Don’t connect an AI tool as an admin unless you have a good reason.

Step 5: Connect Cursor and Claude Code

For an HTTP connection, the adapter docs suggest a small proxy package called @automattic/mcp-wordpress-remote. It runs through npx on your computer and takes care of the login for you.

The two connection types suit different setups:

• STDIO runs the server through WP-CLI on the same machine as the site. It needs no password and works well for local development.
• HTTP goes through the REST API with an Application Password. Use it for staging sites and anything you can’t reach from a terminal.

Cursor

Add this to .cursor/mcp.json in your project, then restart Cursor:

{
  "mcpServers": {
    "wordpress-local": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://your-site.local/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "mcp-user",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}

Claude Code

If WP-CLI works on your local site, you can skip HTTP and use STDIO. This command runs the server through WP-CLI as the user you pick:

claude mcp add wordpress-local -- wp --path=/path/to/site mcp-adapter serve --server=mcp-adapter-default-server --user=mcp-user

You can also give Claude Code the same npx setup that Cursor uses.

Once you’re connected, ask the tool to list the abilities on your site. You should see my-site/get-site-info in the list.

Safety checks before you go further

• Start with read-only abilities. Share abilities that only fetch data before you add any that create, edit, or delete.
• Keep permission callbacks strict. Never return true for everyone. The callback is what really keeps people out.
• Keep passwords out of git. If .cursor/mcp.json holds a password, add it to .gitignore.
• Look before you approve. Both tools ask before they run a tool call. Read the input before you say yes.
• Test a failed permission check. Get one read-only ability working, then see what happens when the check says no. That test teaches you more about safety than a success does.
• Revoke the password when you’re done. Delete the Application Password once you stop testing.
• Stay local until you trust it. Don’t point an AI tool at a client’s live site on day one.

FAQ

Is the WordPress MCP Adapter part of WordPress core?

No. WordPress 6.9 includes the Abilities API in core, but the MCP Adapter is a separate plugin you install from GitHub. It’s still under version 1.0, so expect changes between releases.

Do I need WP-CLI to connect Claude Code?

No. WP-CLI gives you a STDIO connection on a local site. Without it, you can use the HTTP endpoint with the npx proxy and an Application Password, the same way Cursor connects.

Can an AI tool change my site through MCP?

Only through abilities you’ve marked as public, and only when the connected user passes each ability’s permission callback. Start with read-only abilities and a user with a low role.

Why doesn’t my ability show up in Cursor or Claude Code?

Check three things first:

• The ability’s meta needs the mcp public flag.
• The adapter plugin has to be active.
• The site has to run WordPress 6.9 or newer.

Then ask the tool to list the abilities again.

Your turn

I’m still early with this setup, and I’d like to hear how yours went.

• Have you connected Claude Code or Cursor to a WordPress site yet? Did you go with STDIO or HTTP?
• Which ability would you expose first on a real site?
• Did a permission check ever block something you expected to work?

Tell me in the comments, including the parts that broke. I read every reply.

Keep reading

I explain how I split work between these tools in my AI workflow for WordPress development. I also wrote about where AI speeds up my WordPress work, and where it doesn’t.

---

Originally published on matthummel.com.

Comments

[Auten]

Notes from wiring Claude Code to a site like this, since you asked:

• Application Passwords only show up on HTTPS by default. On a plain-http local site WordPress hides them unless the environment type is local (define( 'WP_ENVIRONMENT_TYPE', 'local' );), which is usually the first "where is the button?" moment.
• Claude Code takes the endpoint as an HTTP server with a Basic auth header: claude mcp add --transport http wp https://your-site.local/wp-json/mcp/mcp-adapter-default-server --header "Authorization: Basic <base64 of user:app-password>". If every call comes back 401 although the password is right, the host is probably stripping the Authorization header (Apache with CGI/FastCGI). SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 in .htaccess fixes it.
• Because the default server exposes only discover / get-info / execute, the client's tool list says nothing about what your site can do. The model has to call discover first, so the ability label and description are effectively your prompt. Short, verb-first descriptions ("Returns the site name and tagline") get picked far more reliably than vague ones.
• Connect it as a dedicated user with a custom role that has only the caps your abilities check, not your admin account. Then a confused model can't do more than the permission callbacks allow, and you can revoke that one Application Password without touching anything else.

For the wp-admin screens no ability covers yet (third-party plugin settings pages, mostly), a screen-control MCP can fill the gap; that's what we build at Auten. But abilities like yours are the better path wherever they exist: typed input, a permission check per call, nothing to break when a page layout changes.

[DEV SUPPORTS]

You need to verify your account.

tr.ee/dev-to