Connect Claude Code or Cursor to your webhooks over MCP

Everything Build with AI can do inside your dashboard is also published as WordPress Abilities. Any tool that speaks the Model Context Protocol — Claude Code, Cursor and others — can therefore discover and drive the same toolset from outside WordPress, once something is installed to serve them over MCP — either the WordPress MCP Adapter itself, or Enable Abilities for MCP, which bundles it: list the do_action hooks your site actually fires, read why a delivery failed, create a webhook and fire a test at it. Nothing is proxied through us; the AI talks to your site directly, and your site decides what it is allowed to do.

If the endpoint will not respond

Check https://your-site.com/wp-json/ in a browser first. If it redirects or 404s, your permalinks are set to Plain — change that under Settings → Permalinks and save, or path-based REST URLs never resolve and no MCP client can reach the server. This is the most common cause of a connection that looks broken for no reason.

What a connected tool is allowed to do

Reads are always available: your webhooks, triggers, trigger schemas, delivery logs and snippet list. Writing is on by default and can be switched off in Settings, which holds connected tools to read-only without affecting Build with AI. Deleting a webhook, taking one live, firing a test delivery and provisioning an application password are refused unless the call carries "confirmed": true, so no agent performs them on its own initiative. Secrets are never returned: stored credentials come back as names and masked hints only.

Application Passwords or API tokens?

The MCP endpoint authenticates as a WordPress user, so it needs an Application Password. The plugin’s own scoped API tokens work on the Abilities REST route (/wp-json/wp-abilities/v1/abilities/<name>/run) instead, which is the better fit for scripts: a read token can call the read abilities and nothing else, and an agent token can build but can never reveal a stored secret.

Why you only see three tools

The MCP Adapter does not publish each ability as its own MCP tool. Its server exposes a fixed trio — discover-abilities, get-ability-info and execute-ability — and an AI reaches any registered ability through execute-ability. The practical consequence is that your AI tool cannot offer separate per-tool approval for, say, reading a log versus deleting a webhook: to it they are one tool called with different arguments. That is why Webhook Actions enforces its own confirmation on destructive abilities rather than relying on the client to do it.

Ability names use dashes

Inside Build with AI an ability is create_webhook. On the Abilities and MCP surface the same ability is flowsystems-webhook-actions/create-webhook — WordPress core rejects underscores in ability names, so they are converted at the boundary. Use the dashed form in anything you call from outside WordPress.

What about Claude on the web?

The setup above is for tools that can send a static header. Claude.ai custom connectors instead need a full OAuth 2.1 sign-in, which the MCP Adapter does not provide — that route needs a second plugin for the OAuth layer, and a host that lets WordPress answer /.well-known/ paths. It does work: see [Connect Claude on the web](/docs/connect-claude-ai/).

/ Setup

1. 1
   Get an MCP server running

   WordPress 6.9 and newer ship the Abilities API, which is where Webhook Actions publishes its toolset. Something still has to serve those abilities over MCP, and there are two ways to get that. The official WordPress MCP Adapter is the direct route, but it is not in the plugin directory yet, so it has to be built from source with Composer. The easier route is to install Enable Abilities for MCP from Plugins → Add Plugin and switch on "claude.ai OAuth Custom Connector" under Settings → WP Abilities → Connection: it carries its own copy of the adapter, and that switch starts both servers — including the one this guide uses. Either way you end up with the same endpoint.

2. 2
   Create an Application Password

   In WordPress go to Users → Profile, scroll to Application Passwords, name one after the tool you are connecting, and click Add Application Password. Copy the password WordPress shows you — it is displayed once, and the spaces in it are fine to keep. Create it on an administrator account: the abilities check the same capability the plugin’s own screens do. Each one can be revoked individually later without disturbing the others.

   Click to expand

3. 3
   Add the server to your AI tool

   Point the tool at your site’s MCP endpoint and give it the Application Password as HTTP Basic credentials. In Claude Code that is a single claude mcp add command; in Cursor it is an entry in mcp.json. Both are shown below. If you took the Enable Abilities route, its Connection tab prints the exact URL and will assemble the credentials for you from your username and Application Password.

4. 4
   Check the connection

   Run `/mcp` in Claude Code, or ask the tool what it can do. You will see three tools rather than a long list — discover-abilities, get-ability-info and execute-ability. That is how the MCP Adapter works: it exposes those three, and everything Webhook Actions offers is reached through them. Ask it to discover the available abilities and you should get all of ours back by name.

5. 5
   Put it to work

   Try "show me which hooks this site fires when an order completes, then wire that to my n8n endpoint and test it". The AI reads your real trigger list rather than guessing, and a test delivery tells it whether the endpoint actually accepted the payload.

/ Examples

Claude Code — add the server

# username:application-password, base64-encoded
CREDS=$(printf '%s' "admin:abcd EFGH ijkl MNOP qrst UVWX" | base64 -w0)

claude mcp add --transport http webhook-actions \
  https://example.com/wp-json/mcp/mcp-adapter-default-server \
  --header "Authorization: Basic $CREDS"

Cursor — mcp.json

{
  "mcpServers": {
    "webhook-actions": {
      "url": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
      "headers": {
        "Authorization": "Basic <base64 of username:application-password>"
      }
    }
  }
}

Confirming a destructive call

// Deleting, enabling or test-firing a webhook is refused until it is
// confirmed, so an agent cannot do any of them by accident:
{ "code": "fswa_confirmation_required", "data": { "status": 428 } }

// The same call, once a human has approved it:
{ "input": { "id": 12, "confirmed": true } }

/ Related