“Agentic” sounds grander than the work needs to be. I mean letting an assistant inspect a site, use a defined tool, make or propose a change, and check what happened. The assistant can run in a desktop app or a terminal on your own computer. WordPress does not need to host the model, and the assistant does not need your main admin login.
There are two good routes. MCP lets an assistant discover named WordPress abilities and call only the ones exposed to it. WP-CLI lets a terminal assistant run ordinary WordPress commands where it has shell access. You can use either or both. They have different security boundaries, so do not treat an SSH login as if it were a limited WordPress user.
What WordPress provides, and what it does not
The Abilities API, included in WordPress 6.9 and later, gives a WordPress action a name, input and output shapes, and a permission check. The free MCP Adapter from the WordPress AI team exposes eligible abilities to MCP clients over HTTP or via WP-CLI's STDIO transport. It is a bridge, not an AI model and not a ready-made editor for everything on your site. An ability has to opt in to MCP exposure, and its permission check still applies when it runs. The default server supplies discovery, information and execution tools for those exposed abilities, rather than promising a list of post-editing commands out of the box. The default-server guide explains this layer.
The separate free AI plugin adds optional dashboard features such as an Abilities Explorer, summaries, alt text and other experiments. It can also register general-purpose abilities when you enable its Custom Abilities experiment. Review that switch and the abilities it exposes before connecting an agent. If you want WordPress itself to call a model, you also need an appropriate provider connector under Settings → Connectors; provider usage may cost money. You do not need a provider connector merely to let a model running in your own client call WordPress through MCP. Learn WordPress walks through the AI plugin and connectors.
The WordPress.org MCP server is a third, separate thing. It helps plugin developers check directory guidance, validate a readme and inspect submission status. It connects to WordPress.org, not to your own site's posts. Its quick setup is npx -y @wporg/mcp if that is your job.
Pick a route before installing anything
- A local or staging WordPress site: start with WP-CLI and the MCP Adapter's STDIO server. Nothing needs to be publicly exposed.
- A live site without shell access: use the adapter's HTTPS endpoint, a dedicated WordPress user and a separate Application Password for each client.
- A live site with SSH: run WP-CLI under that site's Unix account. This is useful for development and operations, but shell access may be much broader than an Editor role.
For a first experiment, make a staging copy, confirm its URL and take a usable backup. A production site is not the place to discover that a tool can publish, delete or read private content. The official site-owner guide is worth keeping beside these examples.
Install the adapter and see what is available
On WordPress 6.9 or later, install the directory release from Plugins → Add New, or use WP-CLI in the WordPress directory. The following examples use a local site path; replace it with your own:
wp --path=/path/to/wordpress core version
wp --path=/path/to/wordpress plugin install mcp-adapter --activate
wp --path=/path/to/wordpress mcp-adapter list
wp --path=/path/to/wordpress plugin status mcp-adapterThe MCP Adapter CLI guide documents list, serve and the user option. A server appearing in list means the transport is registered. It does not mean every action you had in mind is available. Ask the assistant to discover abilities after connecting, then inspect the name, description, input schema and permission before relying on one. If the list is short or empty, install or write an appropriate ability rather than asking the model to invent a tool.
Connect Codex or Claude Code to a local site
Both terminal clients can launch the adapter as a local STDIO process. Use a WordPress user with just the capabilities needed for your test. --user selects the WordPress permission context for this WP-CLI process; it is not a substitute for controlling who can run the process:
codex mcp add wordpress-local -- wp --path=/path/to/wordpress mcp-adapter serve --server=mcp-adapter-default-server --user=agent-editor
codex mcp list
claude mcp add --transport stdio wordpress-local -- wp --path=/path/to/wordpress mcp-adapter serve --server=mcp-adapter-default-server --user=agent-editor
claude mcp listRun the command for the client you actually use, not both unless you want both configured. The Codex MCP guide and Claude Code MCP guide explain their configuration and status commands. Codex's desktop app and CLI share MCP configuration; other desktop clients have their own settings. In a fresh session, ask: “Which WordPress site are you connected to? Discover its exposed abilities. Do not change anything.” Check the site name and tool list before a write.
Connect a remote site over HTTPS
With the adapter active, the default endpoint is https://example.com/wp-json/mcp/mcp-adapter-default-server. Create a dedicated WordPress user with the right role, then create an Application Password in that user's profile. Name it for the device and client so you can revoke just that connection later. The site-owner guide shows the exact steps and a client configuration using Automattic's local HTTP-to-STDIO helper. The useful part of that configuration looks like this:
{
"mcpServers": {
"wordpress-site": {
"command": "npx",
"args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
"env": {
"WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
"WP_API_USERNAME": "agent-editor",
"WP_API_PASSWORD": "YOUR_APPLICATION_PASSWORD"
}
}
}
}Put real credentials only in a private client configuration or a suitable secret store, never in a repository, chat transcript or screenshot. Do not paste them into a shell command that will sit in history. Restart the client, discover abilities and try a read-only request first. Some clients can use authenticated HTTP directly, but the exact configuration varies; do not point a client at the URL without arranging WordPress authentication. The helper's documentation explains what it forwards. A web-only chat app is not automatically the same as a local MCP client, and the adapter does not supply OAuth for it.
Use SSH when you already have site-level access
A local client can also start WP-CLI on a remote server through SSH. Here is the command shape to test on staging before adding it to a client's STDIO configuration:
ssh -T [email protected] 'wp --path=/home/site/htdocs/example.net mcp-adapter serve --server=mcp-adapter-default-server --user=agent-editor'Use a named site account and the correct site directory, not root or a shared account. The remote process must keep standard output clean for MCP messages: login banners, shell prompts and diagnostic text on stdout can break the connection. Check ssh -T [email protected] 'wp --path=/home/site/htdocs/example.net mcp-adapter list' first if you are unsure of the path. Once that works, register the remote command with your local client:
codex mcp add wordpress-ssh -- ssh -T [email protected] 'wp --path=/home/site/htdocs/example.net mcp-adapter serve --server=mcp-adapter-default-server --user=agent-editor'
claude mcp add --transport stdio wordpress-ssh -- ssh -T [email protected] 'wp --path=/home/site/htdocs/example.net mcp-adapter serve --server=mcp-adapter-default-server --user=agent-editor'Again, choose only the client you use. An SSH account that can run unrestricted WP-CLI can often select a different --user, edit plugin files or read configuration. The WordPress role in this command does not limit that Unix account. If you cannot give the assistant an appropriately isolated shell account, prefer the HTTPS route with a dedicated WordPress identity.
Sometimes WP-CLI is the simpler tool
MCP is useful when you want the assistant to discover named, permission-checked actions. It is not required for every terminal job. If your agent already has authorised shell access to a local or staging site, ask it to run a small WP-CLI command and show you the result. These commands illustrate an inventory followed by a draft-only change:
wp --path=/path/to/wordpress option get siteurl
wp --path=/path/to/wordpress plugin list --format=table
wp --path=/path/to/wordpress post list --post_type=post --post_status=draft --fields=ID,post_title,post_status --format=table
wp --path=/path/to/wordpress post get 123 --fields=ID,post_title,post_excerpt,post_status
wp --path=/path/to/wordpress post update 123 --post_excerpt='A checked, human-approved summary.'
wp --path=/path/to/wordpress post get 123 --fields=ID,post_title,post_excerpt,post_statusReplace 123 with the ID you verified and review the proposed excerpt before running the update. For a new piece, have the assistant prepare the content first, then create it as a draft, not a published post. WP-CLI's post list, post get, post create and post update references cover the options. WP-CLI follows the authority of the shell account, so use it with the same care as any other server operation.
Give the assistant a job with a stopping point
A good first request is specific enough to check: “On staging, tell me the site URL and list the exposed MCP abilities. Do not edit anything. Tell me which WordPress user you were configured to use.” Follow it with: “Read draft 123, suggest an excerpt in British English, and show me the proposed text. Do not save it.” Only after approval should it write, read the post back, and open the editor and signed-out page for a visual check. For plugin work, ask for the plugin versions and a proposed change in a Git checkout, then run the relevant tests before deployment.
Keep read, edit and publish separate where possible. Check whether an exposed ability can read private posts, users, orders or customer details, and do not enable it just because it sounds convenient. Revoke a lost Application Password promptly. Keep backups and WordPress revisions for content, and Git plus a rollback route for code. An assistant reporting “done” is not proof that the visitor-facing result is right.
When a connection fails
- No MCP server: confirm the adapter is active and run
wp mcp-adapter listin the right WordPress installation. - Connected, but no useful abilities: check the ability's MCP exposure setting and its permission callback; the adapter does not manufacture editing abilities.
- 401 over HTTPS: check the WordPress login name, Application Password, endpoint URL and whether the server passes the Authorization header through.
- STDIO exits or shows invalid JSON: confirm the site path and user, then remove banners, debug output and notices from standard output.
- A write is refused: inspect the user's capabilities and the individual ability's permission check. Do not jump straight to an administrator account.
The adapter's common-issues guide goes deeper. For background, start with Learn WordPress's MCP lesson and the WordPress developer walkthrough. Those explain the moving parts better than a promise that an AI plugin can run your whole site.
Where hosting helps
For AceMedia Host clients, site-scoped agent access from the hosting panel can bring read-only hosting checks into the same workflow. WordPress content actions still use a separate WordPress identity. That keeps hosting access and editorial permissions clear rather than sharing an operator key. Start with one site, one read-only question and one reviewed draft change. Add more tools only when the first workflow is dependable.
The WordPress plugins and MCP plumbing are free to install. Your model, provider API or local hardware may still have a cost. The useful saving is not a claim that everything is free forever; it is that you can begin with open WordPress building blocks and tools you already control.