Connect Claude on the web to your webhooks
Add your site to claude.ai as a custom connector, so you can ask Claude about your webhooks and have it build them — from the browser, with no terminal.
Claude Code and Cursor connect with a single header, but claude.ai needs a full OAuth 2.1 sign-in before it will talk to a server. The WordPress MCP Adapter does not provide one, so this route uses Enable Abilities for MCP instead — a plugin directory install that ships both an embedded OAuth 2.1 server and its own copy of the adapter, so it is the only thing you need to add. Once connected, Claude signs in as a WordPress user and gets that user’s permissions: it can read your triggers, webhooks and delivery logs, and build automations for you, in an ordinary browser conversation. This is a more involved setup than the terminal route, and one step of it depends on your host — read the last section before you start.
What you need before you start
A publicly reachable HTTPS site — this is a browser-to-server OAuth flow, so localhost and sites behind a VPN or HTTP basic-auth wall cannot complete it. Permalinks must be set to something other than Plain, or /wp-json/ URLs do not resolve and no MCP client can reach the server. You also need a paid Claude plan, because custom connectors are not available on the free tier. If either is a problem, [Claude Code or Cursor](/docs/connect-claude-code-and-cursor/) will connect to a local site with nothing more than an application password.
Why Claude only sees three tools
The MCP Adapter does not publish each ability as its own tool. It exposes a fixed trio — discover-abilities, get-ability-info and execute-ability — and everything runs through the last one. So Claude cannot offer separate approval for reading a log versus deleting a webhook: to it they are one tool with different arguments. That is why Webhook Actions enforces its own confirmation on destructive actions instead of relying on the client, and why setting execute-ability to "ask each time" is worth the extra clicks.
What a connected Claude is allowed to do
Reads are always available: webhooks, triggers, trigger schemas, delivery logs and your snippet list. Building 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 all require an explicit confirmation, so Claude cannot do them on its own initiative. Secrets never travel: vault credentials are returned as names and masked hints, and a webhook’s stored authorization header is redacted before it leaves your site.
If sign-in fails at the last step
Two things account for almost every failure, and both are your host rather than the plugins. First, many servers block or intercept /.well-known/ paths — a common nginx rule denies anything containing a dot-directory, which silently swallows OAuth discovery. It needs an explicit exception that lets WordPress answer those URLs. Second, some firewalls block the request Claude makes to register itself, usually by filtering on its user agent. If discovery succeeds but the connection still fails, that is the one to ask your host about. On managed hosting where you cannot change either, use [Claude Code or Cursor](/docs/connect-claude-code-and-cursor/) instead — that route needs neither OAuth nor .well-known.
A note on the extra plugin
Enable Abilities for MCP is a third-party plugin, not ours, and the OAuth layer inside it comes from the wp-media/mcp-oauth library. We document it because it is what genuinely works today, not because Webhook Actions depends on it — our abilities are published through WordPress core’s Abilities API, and any MCP server can drive them. The copy of the MCP Adapter it bundles is a version behind the standalone one; if you would rather run the current adapter, install that plugin as well and the newer code takes over.
/ Setup
- Install Enable Abilities for MCP and turn OAuth on
From Plugins → Add Plugin, search "Enable Abilities for MCP", install and activate. Then go to Settings → WP Abilities → Connection and switch on "claude.ai OAuth Custom Connector". That one switch is what starts the MCP server — the plugin carries its own copy of the WordPress MCP Adapter, so you do not need to install that separately for this route. The same panel shows the exact URL to paste into Claude, with a Copy button; use that rather than typing it. The plugin also registers 91 content-management abilities of its own under the Abilities tab: leave them on if you want them, or switch them off so Claude sees only your webhook tools.
- Check the URLs actually answer
Two quick checks in a browser. Open https://your-site.com/.well-known/oauth-authorization-server — you should get a short block of JSON, not a 403 or a 404 page. Then open https://your-site.com/wp-json/ and confirm it returns JSON too; if it redirects or 404s, switch Settings → Permalinks off "Plain" and save. Both have to work before Claude can connect, and both fail in ways that look like a broken plugin rather than a server setting.
- Add the connector in Claude
In claude.ai go to Settings → Connectors → Add custom connector. Give it a name and paste the URL you copied in the previous step — it looks like https://your-site.com/wp-json/mcp/mcp-oauth-server
- Accept the detected settings
Claude inspects the server and pre-selects the right options, each marked Detected: Authentication "Always required", OAuth client "Use Anthropic’s hosted client metadata", and under Advanced, Transport "Streamable HTTP". Leave all three alone and leave the extra headers empty — the sign-in provides everything. Picking "register one automatically" instead will fail: this server offers no registration endpoint.
- Sign in as an administrator
Claude sends you to your own site to log in and approve the connection. Sign in as an administrator: the connection inherits that user’s permissions, and the Webhook Actions abilities require the same capability as the plugin’s own screens. Approving as a lower-privileged user connects successfully but finds no tools, which looks like a broken server.
- Set the tool permissions
Claude lists three tools: two read-only ones and execute-ability under "Write/delete tools". Leave the read-only pair on Always allow, and set execute-ability to Needs approval — every action, from reading a log to deleting a webhook, goes through that one tool, so it is the only place you can keep a hand on the wheel.
- Ask it something
Try "what webhooks do I have set up?" or "show me which hooks this site fires when an order completes, then wire that to my n8n endpoint and test it". Claude reads your real configuration rather than guessing.
/ Related