Agent Abilities for MCP - Connect Claude and ChatGPT with Permission Controls and Audit Log

More help: Documentation | Connecting a client | Security and disclosure | Support forum Install and activate the plugin, then open the Agent Abilities for MCP screen and turn on the abilities you want, since everything starts off. Copy your site's MCP endpoint from the Connection tab and add it to your AI client. The simplest path is OAuth: paste the endpoint and approve the connection once in the browser. If your client cannot use OAuth, point a dedicated low-privilege user at an Application Password instead. Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and Gemini CLI all connect today, some directly and some through the mcp-remote bridge that runs on your own machine.

Install the plugin, enable the abilities you want on the Abilities tab, then copy your MCP endpoint from the Connection tab and add it to Claude as a custom connector. Approve the sign-in once in the browser. The claude.ai web app and Claude Desktop use that same flow; Claude Code connects from the command line.

No. The agent authenticates as whatever WordPress user you bind it to. Point it at the dedicated low-privilege user the plugin can create for you, and it can only do what that user can do. Each of this plugin's abilities also re-checks the user's capability before it runs, so a connection can never call one of them if its user is not allowed to use it.

Agent Abilities for MCP gives you three layers for its own tools. Every ability is off until you enable it. The agent connects as a real WordPress user you choose, so it can only do what that user's role already allows. Every call re-checks that user's capability before it runs, and a call that fails the check is denied and recorded.

Yes. Beyond the site-wide list of enabled abilities, you can add a per-role allowlist, a per-connection allowlist, or both, on the Connections screen. Either one only narrows what was already enabled: an ability still has to clear the global list, then the matching role's list, then the matching connection's list, before an agent can call it. There is no finer-grained scoping below role and OAuth connection - an Application Password inherits its user's whole role, with no separate per-password limit. Leave the screen alone and nothing changes; every existing connection keeps working exactly as it did before.

Open the Activity Log tab. You can filter by user, connection, tool, plugin, date and text. Each row shows the connection name, the source IP address and how long the tool ran. A summary at the top covers the last 7 days, and a Live view keeps the first page current while you watch (it needs a date range when a text search or a user filter is applied). Export CSV downloads exactly the rows the filters show. The IP is the address the request came from, so behind a proxy or CDN it is the proxy's address. Duration is the time spent inside the tool, not what the agent experienced. A denied call never runs, so it has no duration.

Yes. Agent Abilities for MCP writes every call to one of its abilities to an audit log in your own database, denied attempts included. Each entry records the acting user, the ability name, the argument keys, and a short note of what the call touched: small identifying values only, such as ids, meta key names, slugs, and status values. For a failed call to another plugin's bridged ability, it also records that plugin's error code, never its message. Free-text argument content, a post body or an email address, is never stored. Each entry also records the source IP address and the time the tool took, and a denied call records why it was refused. That reason is in the log, not in the message the agent sees. You can clear the log from the admin screen.

Yes, when the connection is scoped, which is what this plugin is built around. The agent connects as a real, least-privilege WordPress user you choose, never an admin-equivalent key. Every ability is off until you enable it, each call to its tools re-checks the user's capability before it runs, and every one of those calls is logged, denied attempts included. Tools another plugin publishes to the Adapter's default server are outside these checks; the FAQ on the default server explains. The plugin itself never holds an admin-equivalent key.

Only the abilities you have enabled, and only within the bound user's capabilities. The catalog is reads and guarded writes over posts, pages, terms, comments, media, post meta, and site structure, plus revision history and a search that spans every post type at once. There is no ability to change options arbitrarily, change roles, or run code. The one ability that fetches a remote URL is a media upload: it only accepts https, refuses a target that resolves to a private, loopback, or link-local address, never follows a redirect, and stays off until you enable it like every other ability. An agent can only write post meta for keys an administrator has explicitly allowlisted, and protected, underscore-prefixed, and authentication keys can never be allowlisted. Deletes move content to Trash where the ability supports it, and the permanent ones are off by default and capability-gated.

No, it will refuse the write instead. Elementor, Divi, Beaver Builder, and Avada all store their layout somewhere other than the normal post content, so an unguarded edit could report success while changing nothing you can see, or corrupt the builder's own markup. The plugin checks page-builder ownership before any content write and refuses the call with an error naming the builder that owns the page, so you find out immediately rather than discovering it later. Edit that page in its own builder instead. This is a refusal guard, not an integration with any of these builders, and OptimizePress is not covered yet.

Agent Abilities for MCP ships everything off, binds the agent to one WordPress user you pick, re-checks that user's capability on every call to its tools, and logs every one of those calls including denials. You add reach as you build trust, not all at once. It trades raw tool count for control you can audit.

Yes. Agent Abilities for MCP is free on WordPress.org, with no paid tier, no API key to buy, and no usage limits added by the plugin.

Yes, for a set of supported plugins. When one is active, Agent Abilities for MCP adds abilities for it under the same rules as the core: detected automatically, off until you turn them on, capability-gated, and logged. Out of the box it covers WooCommerce, Advanced Custom Fields, and SEO (Yoast, Rank Math, and All in One SEO). The WooCommerce and ACF abilities can read and write real customer and order data, including personal data such as names, emails, and addresses, so they sit behind a clear notice in the admin and stay off until you switch them on. Beyond these built-in integrations, the plugin can also bridge abilities that any of your other plugins register through the WordPress Abilities API. More integrations are planned.

Yes. WordPress 6.9 lets any plugin register abilities, and Agent Abilities for MCP can bridge the ones declared by your other active plugins. Open Other plugins in the admin, where they are grouped by the plugin that registered them and start off. Turn one on and it becomes a governed MCP tool under the same rules as everything else: scoped to the bound user, capability-checked on every call, rate-limited, and logged. You can enable or disable a whole plugin's set at once, and nothing is bridged until you choose it.

Yes, when WooCommerce is active. The plugin adds WooCommerce abilities for reading and writing products, orders, and customers, so an AI agent can help run your store through this MCP server for WooCommerce. Those abilities reach real customer and order data, including personal data such as names, emails, and addresses, so they stay off until you enable them and sit behind a clear notice in the admin, under the same least-privilege and audit-logging rules as everything else.

Yes, when the matching plugin is active. With The Events Calendar active, an agent can read and manage events, venues, and organizers; with Event Tickets active, it can read tickets and attendees, though no ticket-purchase write is exposed. With GeoDirectory active, it can read and manage business and place listings, but that integration stays off even when the plugin is active - you turn it on yourself on the Integrations tab, unlike most other integrations, which are simply off until enabled. All of these abilities follow the same rules as everything else: off until you switch them on, capability-gated, and logged.

It is built on both. WordPress 6.9 ships the Abilities API, and the official MCP Adapter comes bundled with this plugin; Agent Abilities for MCP registers a curated, governed set of abilities on top of them rather than inventing its own protocol or transport. So there is no bespoke server to trust, and the plugin inherits the standard's behavior. What it adds is the governance layer: the off-by-default catalog, the capability gating, the safety controls, and the audit log.

Most MCP plugins for WordPress compete on how many tools they can expose. Agent Abilities for MCP competes on control. Everything is off until you enable it, the agent acts as a real least-privilege WordPress user rather than an admin-equivalent key, every call to its tools re-checks that user's capability before it runs, and every one of those calls is logged, denials included. It builds on the official WordPress Abilities API and MCP Adapter instead of a hand-rolled server, so there is no custom transport to trust. It trades raw tool count for reach you can audit and widen as you build trust.

The REST API exposes raw endpoints. MCP describes your site's abilities as discoverable tools an AI agent can reason about and call, and this plugin wraps each one in a governance layer: off by default, capability-gated on every call to this plugin's tools, and logged. It is the same underlying WordPress, governed so an agent can drive it within the limits you set.

WordPress 6.9 or newer, which is where the Abilities API and the official MCP Adapter the plugin builds on are available. PHP 7.4 or newer is required.

Any MCP client that can reach your site's endpoint. With OAuth you paste the endpoint URL into the client and approve the connection once in the browser; clients like Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and Gemini CLI connect this way, some directly and some through the mcp-remote bridge that runs on your own machine. You can also connect with an Application Password instead of OAuth, though the hosted cloud apps use OAuth only. ChatGPT connects too, once you turn on developer mode and add your site as a custom connector, and so does Manus. The hosted Gemini app is not supported yet.

Yes. In ChatGPT, turn on developer mode, then add your site as a custom connector using your MCP endpoint URL and approve the connection once over OAuth. This needs a ChatGPT plan that allows custom connectors. Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and Gemini CLI also work, some directly and some through the mcp-remote bridge that runs on your own machine.

No. Your WordPress site is the MCP server, so the endpoint is already public over HTTPS on the site itself, not on your computer. Connecting a hosted client like ChatGPT or Claude to a remote WordPress install means pasting that endpoint URL into the client and approving one OAuth sign-in in the browser. No tunnel, no reverse proxy, no local bridge process to keep running. A bridge is only needed for a client that can't open a remote MCP connection on its own, covered above.

Only the parts you allow. ChatGPT reaches your site through a custom connector you add yourself, it acts as the WordPress user that approved the connection, and it sees nothing beyond the abilities you switched on. Every write through this plugin's endpoint is capability-checked before it runs and recorded in the audit log, and you can stop all writes at once with read-only mode.

Yes. Install the plugin on each site and add each site's endpoint to your AI client as its own connector. The agent can then work across your sites from one place, and each site keeps its own user, its own allowed tools and its own audit log.

Connect it as a WordPress user with a smaller role. An Editor can write, edit and publish any post; an Author only their own; a Contributor can write but not publish. The plugin can create a dedicated low-privilege user for you, and you can narrow the tools further for one role or one connection.

Yes. Turn on Force draft on create in Settings. Anything the agent creates, and any request to publish, is saved as a draft instead. Edits to a post that is already published still go live, so if you want every change reviewed, connect the agent as a Contributor, who cannot edit published posts at all. The Needs review card on the Dashboard lists those drafts so you can preview, publish or discard them.

Open the Connection tab and click Check my connection (the Connection Doctor). It runs the checks from your own server and names the fix, for example a host that strips the Authorization header. The other usual causes are a CDN or firewall blocking the /mcp path and a local site with a self-signed certificate, and both have their own answers below.

Yes. Site Brief on the Settings tab takes a few lines about your site, up to 1,500 characters. The plugin sends it to every agent that connects when its session starts. Whether the agent follows it depends on the client. Only you can change it.

The Needs review card on the Dashboard lists the drafts and pending posts an agent starts, with Preview, Open in editor, Publish and Discard buttons. Discard moves the post to the Trash, and is unavailable when the Trash is off. Turn on Force draft on create in Settings to hold new posts, and requests to publish, as drafts so they land there.

Yes. Switch on read-only mode and no write tool registers, whatever else is ticked, including write abilities you bridged from other plugins. The agent can still search and read. Your selections are kept for when you switch it back off. Tools another plugin publishes straight to the Adapter's default server are not covered; the next answer explains.

No. The official MCP Adapter is bundled with this plugin, and if you also run the standalone Adapter plugin, the two work together. The Adapter has a built-in default server that other plugins can publish tools to. Settings has a choice for it: Automatic (the default), Always on or Always off. Automatic starts the server only when another active plugin publishes tools there, so a site that updates from an earlier version gets the default server if one does, and the Activity Log notes the first time. WordPress core's own public abilities do not count as a publisher, so if you ran the standalone Adapter only to reach those, choose Always on. This plugin's own tools are never on that server, whatever you choose. They are served only by its governed endpoint. The tools that are on the default server are not governed by this plugin: its read-only mode, allowlists, IP allowlist, rate limit and audit log do not apply to them. Choose Always off if you want none of it.

Windows MCP clients can't launch the npx shim by name. Wrap it in cmd: set "command" to "cmd" and put "/c", "npx" at the front of "args". The Connection tab has a Windows tab that generates this for you.

Local stacks like DDEV, Local, and Valet serve a self-signed certificate that Node rejects, so the proxy never reaches WordPress. For local testing only, add "NODE_TLS_REJECT_UNAUTHORIZED": "0" to the "env" block (the Connection tab adds it automatically when it detects a local site). Don't ship that setting to production. A public site has a trusted certificate and doesn't need it.

When OAuth is enabled, clients find your site by fetching two documents under /.well-known/: /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server. WordPress serves both, but the request has to actually reach WordPress. Some servers deny anything that starts with a dot before PHP runs, and that blocks discovery. On nginx the usual cause is a dotfile deny rule (location ~ /. { deny all; }). Add a more specific block ahead of it so /.well-known/ falls through to WordPress: location ^~ /.well-known/ { try_files $uri $uri/ /index.php?$args; } The ^~ prefix tells nginx to prefer this block over the dotfile deny. Other hidden files stay denied. Apache usually works as-is, because the WordPress .htaccess sends anything that isn't a real file to index.php, /.well-known/ included. If a host or security plugin is blocking dotfiles, look for that rule (often in the vhost or a hardening snippet, not WordPress itself) and let /.well-known/ through. To check, request https://your-site/.well-known/oauth-protected-resource. A working setup returns a JSON document instead of a 403 or 404.

A CDN or firewall in front of WordPress can stop the agent before its request reaches your site. The common culprit is Cloudflare's AI bot blocking (and Super Bot Fight Mode): the agent finishes signing in, but its MCP request is blocked at the edge because it comes from the AI client's servers with an AI User-Agent. The sign-in shows up in the Activity Log, and no ability calls follow it. To confirm, open your CDN's firewall or security event log and look for a blocked request to the plugin's MCP endpoint (its path ends in /mcp) from the AI client's IP range, around the time you tried to connect. The entry names the rule that blocked it. The fix is to let that endpoint through. In the Cloudflare dashboard open Security Settings and use "Configure AI bot policies" to allow the AI client's traffic: set the policy that matches the block you see in your security events to Allow. Cloudflare has deprecated the older "Block AI bots" switch (September 15, 2026), so if you still use it, turn it off. If you cannot allow the traffic across the whole zone, add a custom rule with the Skip action for the /mcp path that skips Super Bot Fight Mode rules, so the rest of your site stays covered (Cloudflare does not let a Skip rule skip Bot Fight Mode on the Free plan). Other CDNs and security plugins have the same kind of allowlist or exception. On WP Engine, check Global Edge Security first if your site uses it: in the User Portal open the environment's Insights menu, go to Traffic and Security, then the Settings tab, and look at Edge traffic rules. A rule for a bot category blocks that traffic before it reaches WordPress, so remove the one that covers your AI client. WP Engine also rate-limits some AI bots across its platform, and you cannot turn that off yourself. If the agent's calls fail with HTTP 429 errors on WP Engine, contact WP Engine support and ask them to review the limit for your site.

Yes, but it is off by default. Under Settings, Notifications, choose an admin notice only, an email right away (plus the notice) or one daily email (plus the notice), then tick the events you want to hear about: an app being authorized to connect, an Application Password created for a user who can edit posts or for the agent user, a high-risk tool, a permanent delete or a destructive tool from another plugin running, a burst of denied calls or a connection hitting the rate limit, and read-only mode or the high-risk lock being switched. Each type of event sends at most one email every 15 minutes, so turning read-only mode on and turning it off count separately, as does each app that is authorized. Switch changes and the warnings sent to the old address get a reserved six emails an hour that nothing else can use up. High-risk runs get four an hour of their own, new apps get two, and bursts of denied calls get two. When the limit holds a message back, the next one says how many it missed. Emails say what happened and link to the Activity Log. They never include the content of a call, a user name or an IP address. They go out through WordPress's own mail, so on a host where mail is unreliable the admin notice is the dependable option. The daily email needs WP-Cron.

Yes. Set a per-minute cap on the Settings tab under "Rate limit (per minute)". Each connection can make that many agent calls a minute, counted per agent user; 0 turns the limit off. Calls over the cap are denied and logged on the Activity Log tab, so you can spot a connection that keeps hitting it.

No. The plugin never connects to OpenAI, Anthropic, Google, or any other AI provider. Your own AI client connects in to your site and calls the abilities you have enabled. Whatever your AI client does with the results afterward is between you and whoever makes that client. (The one thing the plugin itself can fetch is a URL, if you enable the URL-upload ability - see "Does it send data anywhere?" below.)

No AI provider and no telemetry. Your agent talks directly to your site. The one exception is the off-by-default upload-media-from-url ability: if you turn it on, it fetches the URL your AI client gives it (HTTPS only, private and reserved addresses refused, no redirects followed) so that file can be added to your media library. That fetch is an ordinary HTTP GET - like any request to that address, its destination sees the URL, your site's IP, and when the request happened - but it carries none of your content, credentials, or other site data; it only pulls in the file at the URL you asked it to fetch.

Every call to one of this plugin's abilities, whether it started, succeeded, errored, or was denied, with the acting user, the ability name, the argument keys, and a short note of what the call touched: small identifying values only, such as ids, meta key names, slugs, and status values. For a failed call to another plugin's bridged ability, it also records that plugin's error code, never its message. Free-text argument content, a post body or an email address, is never stored. It also records the source IP address of the request and the time the tool took, and a denied call records why it was refused (in the log, not in the message the agent sees). The activity log lives in your own database and can be cleared from the admin screen.

Not by itself. Uninstalling removes the plugin's own settings and activity log, and, only if you turned on "Delete data on uninstall" first, its OAuth tables too. It never removes the dedicated agent user the plugin can create for you, or any Application Password issued to it, because those are ordinary WordPress account credentials that exist outside the plugin's own data. To fully cut off an agent, revoke its OAuth grant from the Connection tab, or delete its Application Password or user account from the Users screen, before or after you remove the plugin.

Please report security issues privately rather than in the support forum, so a fix can ship before details are public. Use the security contact listed on the plugin's GitHub repository.