How to Connect Claude (and ChatGPT) to WordPress: the MCP Adapter and Abilities API

Short answer: install the WordPress MCP Adapter, register an Ability for each task you want an AI to perform, expose it to the adapter’s default MCP server, create an Application Password, and point Claude at your site’s MCP endpoint. On WordPress 6.9 and newer the Abilities API is already in core, so the adapter has something to connect to out of the box. Below is the full setup, with the exact code and a live example from my own site.

I have run a custom MCP server against my own WordPress install for a while now, so I can manage projects, media, and content from a chat window. In February 2026 WordPress shipped the official way to do this for any site. This guide walks through that official path, shows you a working ability, and points out where I would still write something custom for real client work.

The short version

1. Run WordPress 6.9+ over HTTPS.
2. Install the MCP Adapter (Composer package or standalone plugin).
3. Register an ability category, then an ability, in PHP.
4. Mark the ability mcp.public so the default MCP server exposes it.
5. Create a least-privilege Application Password.
6. Add your site to Claude as an MCP server and invoke the ability to confirm it works.

If you are on WordPress.com rather than a self-hosted site, the path is shorter and uses a hosted endpoint with browser sign-in. I cover that near the end.

What the Abilities API and MCP Adapter actually are

Two separate pieces do the work here, and it helps to keep them straight.

The Abilities API is the part that lives in WordPress core. It landed in WordPress 6.9 (the server-side PHP version), and WordPress 7.0 “Armstrong” (released 20 May 2026) added a matching client-side JavaScript version plus a native AI Client and a Connectors hub. An “ability” is a named, self-describing unit of work: a label, a description, an input and output schema, a function that runs it, and a permission check that decides who is allowed to call it. Think of it as a clean, machine-readable contract for one thing your site can do.

The MCP Adapter is a separate package from the WordPress project. It reads the abilities you have registered and exposes them over the Model Context Protocol, the open standard that AI clients like Claude Desktop, Claude Code, Cursor, and VS Code speak. The adapter is the bridge. The Abilities API is the thing being bridged.

One thing worth saying plainly: the MCP Adapter is not bundled inside WordPress core. What shipped natively in 7.0 was the AI Client, the Connectors management screen, and the client-side Abilities package. The adapter stays a layer you add on top, by Composer or as a plugin.

What you need before you start

• WordPress 6.9 or newer, so the Abilities API is present in core.
• HTTPS, because Application Passwords travel on every request.
• Admin access to install a package or plugin and to create an Application Password.
• An MCP client. I use Claude Code and Claude Desktop in this guide.

Step 1: install the MCP Adapter

You have two options. To embed the adapter inside your own plugin, pull it in with Composer:

composer require wordpress/mcp-adapter

If you would rather run it on its own, grab the latest release from the WordPress/mcp-adapter GitHub repository and activate it like any plugin. Distribution is through Composer and GitHub releases, so install from there rather than searching the plugin directory. The package is GPL-2.0-or-later and runs on PHP 7.4 or 8.x.

• MCP Adapter source and install docs: github.com/WordPress/mcp-adapter
• Download the plugin build: github.com/WordPress/mcp-adapter/releases
• The Abilities API it builds on: github.com/WordPress/abilities-api

The adapter moves quickly through its 0.x releases. Pin a version you have tested, and check the class names against the version you actually installed before you copy any namespaces, since a few moved between releases.

Step 2: register an ability

Abilities are grouped into categories, and a category has to exist before any ability references it. Register the category on the wp_abilities_api_categories_init hook:

add_action( 'wp_abilities_api_categories_init', 'my_plugin_register_categories' );
function my_plugin_register_categories() {
    wp_register_ability_category( 'data-retrieval', array(
        'label'       => __( 'Data Retrieval', 'my-plugin' ),
        'description' => __( 'Abilities that read and return data from the site.', 'my-plugin' ),
    ) );
}

Now register the ability itself on the wp_abilities_api_init hook. The name has to be namespaced, lowercase, with exactly one slash, like my-plugin/get-site-info:

add_action( 'wp_abilities_api_init', 'my_plugin_register_site_info_ability' );
function my_plugin_register_site_info_ability() {
    wp_register_ability( 'my-plugin/get-site-info', array(
        'label'         => __( 'Get Site Information', 'my-plugin' ),
        'description'   => __( 'Returns the site name, tagline, and URL.', 'my-plugin' ),
        'category'      => 'data-retrieval',
        'output_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'name'        => array( 'type' => 'string', 'description' => 'Site name' ),
                'description' => array( 'type' => 'string', 'description' => 'Site tagline' ),
                'url'         => array( 'type' => 'string', 'format' => 'uri', 'description' => 'Site URL' ),
            ),
        ),
        'execute_callback' => function () {
            return array(
                'name'        => get_bloginfo( 'name' ),
                'description' => get_bloginfo( 'description' ),
                'url'         => home_url(),
            );
        },
        'permission_callback' => '__return_true',
        'meta' => array(
            'annotations' => array(
                'readonly'    => true,
                'destructive' => false,
            ),
            // Expose this ability to the default MCP server:
            'mcp' => array( 'public' => true ),
        ),
    ) );
}

__return_true is fine for a genuinely public read like this one. The moment an ability changes or exposes anything that matters, replace it with a real current_user_can() check. More on that below, because it is the part people skip.

Step 3: expose the ability to MCP

There are two ways to get an ability in front of an MCP client.

The simple way is the meta.mcp.public => true flag you saw above. That hands the ability to the adapter’s default server, reachable at:

/wp-json/mcp/mcp-adapter-default-server

Public abilities are not registered as individual tools. Instead the default server gives the client three built-in tools to work through: discover-abilities, get-ability-info, and execute-ability. The client lists what is available, reads an ability’s schema, then runs it.

The custom way is your own server, registered on the mcp_adapter_init hook, where you list abilities explicitly and they become tools without needing the public flag:

use WPMCPTransportHttpTransport;
use WPMCPInfrastructureErrorHandlingErrorLogMcpErrorHandler;
use WPMCPInfrastructureObservabilityNullMcpObservabilityHandler;

add_action( 'mcp_adapter_init', function ( $adapter ) {
    $adapter->create_server(
        'custom-mcp-server',                 // server id
        'custom-mcp-server',                 // REST namespace
        'mcp',                               // route
        'Custom MCP Server',                 // name
        'My custom MCP server',              // description
        'v1.0.0',                            // version
        array( HttpTransport::class ),       // transports
        ErrorLogMcpErrorHandler::class,      // error handler
        NullMcpObservabilityHandler::class,  // observability handler
        array( 'my-plugin/get-site-info' ),  // abilities exposed as tools
        array(),                             // resources
        array()                              // prompts
    );
} );
// Reachable at /wp-json/custom-mcp-server/mcp

Treat that argument order as illustrative, not gospel. It is reconstructed from the README and the positional signature has shifted across 0.x releases, so confirm it against the create_server() definition in the version you installed. For most people the default server and the public flag are all you need.

The adapter speaks JSON-RPC 2.0 over streamable HTTP, layered on the REST API you already have. There is also a STDIO transport for local development through WP-CLI.

Step 4: create an Application Password

The HTTP transport authenticates with a WordPress Application Password, and each ability’s permission_callback decides what that user is actually allowed to do.

In WP Admin, go to Users, your profile, Application Passwords. Give it a clear name like “Claude MCP”, click Add New, and copy the value once. Keep the spaces WordPress puts in it. Use an account with only the capabilities the work needs rather than a full administrator where you can.

Step 5: connect Claude

The most documented path for a self-hosted site uses the official remote proxy. In Claude Desktop’s claude_desktop_config.json (or Claude Code’s .mcp.json), add:

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

WP_API_PASSWORD is the raw Application Password, spaces and all. Restart the client, or run /mcp in Claude Code, and your site should show up with its abilities. Ask Claude to run one and watch the round trip complete.

ChatGPT is a different story for self-hosted sites. Its connector model expects a hosted, OAuth-style endpoint, so the clean documented path for ChatGPT is the WordPress.com server below rather than a direct connection to your own adapter.

A real example from my own site

This is not theory for me. Right now waqasdev.com runs Rank Math, which registers its own abilities (I cover what that plugin does in my technical-SEO checklist for WordPress), and an MCP client connected to my site sees them through the adapter’s discovery tools:

{
  "abilities": [
    {
      "name": "rank-math/audit-site-seo",
      "label": "Audit site SEO",
      "description": "Runs Rank Math's site-wide SEO audit and returns a structured score plus per-test findings with fix hints."
    },
    {
      "name": "rank-math/fix-site-seo",
      "label": "Fix site SEO",
      "description": "Applies an automatic fix for a single failing Rank Math SEO test."
    }
  ]
}

Ask get-ability-info about the first one and you get the full contract back, including the schema and the safety annotations:

{
  "name": "rank-math/audit-site-seo",
  "input_schema": {
    "type": "object",
    "properties": {
      "refresh": { "type": "boolean", "default": true },
      "url": { "type": "string", "format": "uri" }
    }
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "score": { "type": "integer", "minimum": 0, "maximum": 100 },
      "grade": { "type": "string", "enum": ["good", "average", "bad"] },
      "findings": { "type": "array" }
    }
  },
  "meta": {
    "annotations": { "readonly": true, "destructive": false, "idempotent": true },
    "show_in_rest": true,
    "mcp": { "public": true }
  }
}

That meta block is the whole idea in miniature. The ability tells the AI it is read-only, safe, and repeatable, and the AI can plan around that. The “fix” ability would be flagged differently, and a good client treats it with more care.

Where I would still write something custom

The official adapter is the right starting point, and it is where I would put most teams. I still keep my own MCP server for a few reasons, and they are worth knowing before you decide.

A hand-written server lets me shape one tool that does exactly the multi-step job I want, like “create a project, attach the gallery, set the featured image, and clear the previous featured flag,” in a single call. That is friendlier for an AI than stitching together five generic abilities. It also lets me wrap fragile data in a safety net the generic path does not give me for free, which brings me to the part that matters most.

The safety net people forget

The first question to ask about any ability is not “can the AI reach it” but “what happens when it gets the input wrong.” Two habits keep this calm.

First, gate every ability that writes anything with a real permission_callback. __return_true belongs only on public reads. For anything that changes the site, check a capability the user genuinely has.

Second, snapshot before you write. On my own site, anything that edits a page’s builder data copies the previous version into a timestamped backup first, so a bad edit is one restore away rather than a recovery job. The Abilities API gives you meta.annotations to mark an ability destructive, which is a signal to the AI. A backup is the part that protects you when the signal gets ignored.

If you want a gentler first automation that never touches your existing data, my walkthrough of routing contact-form submissions to WhatsApp with n8n is an easier place to start than handing an AI write access.

Connecting WordPress.com instead

If your site is on WordPress.com, you skip the adapter, the Application Password, and the proxy. WordPress.com runs a managed MCP server at a hosted endpoint with browser sign-in. In Claude Code:

claude mcp add --transport http wpcom-mcp https://public-api.wordpress.com/wpcom/v2/mcp/v1
# then run /mcp to complete sign-in in your browser

This is also the documented route for ChatGPT, using the same hosted endpoint with ChatGPT’s developer connector settings.

Frequently asked questions

Do I need WordPress 7.0 for this?

No. The server-side Abilities API the adapter relies on is in WordPress 6.9. WordPress 7.0 added the client-side JavaScript version, a native AI Client, and the Connectors hub, but 6.9 is enough to connect Claude through the adapter.

Is it safe to let an AI touch my site?

It is as safe as you scope it. Every ability runs behind a permission check and the Application Password account’s capabilities. Keep that account least-privilege, mark write actions clearly, and back up before anything mutating runs.

Can ChatGPT connect to my self-hosted WordPress site?

The clean, documented path for ChatGPT is the WordPress.com hosted endpoint with its OAuth sign-in. For a self-hosted site, Claude through the official proxy is the better-supported route today.

Do I have to write code?

To expose your own custom actions, yes, a little PHP. But plugins are starting to register their own abilities, as Rank Math already does, so some useful tools show up the moment the adapter is active.

What is the difference between the Abilities REST API and the MCP endpoint?

They are two surfaces over the same abilities. The Abilities REST API lives at /wp-json/wp-abilities/v1/ for normal HTTP calls. The MCP Adapter exposes a JSON-RPC endpoint at /wp-json/mcp/... for AI clients. Use whichever fits the caller.

Want this set up on your site?

I build and wire AI access into WordPress sites for a living, from a single safe ability to a full set of tools an assistant can run day to day, with the permission checks and backups that keep it boring in the best way. If you want an AI that can actually do things on your site, see waqasdev.com/automation or email [email protected] and tell me what you would hand off first.