Agiler MCP exposes WP-CLI through wp_run. The command runs against the selected hosted project’s WordPress installation. You do not need to install WordPress or WP-CLI locally.

Required access

Give the assistant projects.wp:execute and access to the target project. Add projects:read for project discovery and inspection. Maintenance with a backup also needs projects.backups:write. See API keys and permissions.

WP-CLI access can change site content, users, settings, plugins, and themes. There is no separate read-only WP-CLI scope; specify which commands you want and review changes before execution.

Inspect the site

Try this prompt after replacing the project identifier:

Inspect WordPress on Agiler project <project-id>. Report the core version, installed plugins and themes, and which are active. Use inspection commands only. Do not update anything.

The assistant can use these wp_run command values:

TaskCommand
WordPress versioncore version
Plugin inventoryplugin list --format=json
Theme inventorytheme list --format=json
Site URLoption get home

The MCP command argument omits the leading wp. For example, a call to wp_run can use:

{
  "project": "<project-id>",
  "command": "plugin list --format=json",
  "async": true
}

Output contains combined standard output and standard error. JSON formatting makes supported command output easier to inspect, but warnings may still appear alongside it.

Update a plugin

Start by asking for a plan:

For Agiler project <project-id>, inspect plugin <plugin-slug> and its available update. Explain the intended change and how we should verify it. Do not update the plugin yet.

After reviewing the plan:

Create a backup of project <project-id> and wait for it to complete. Update only <plugin-slug>. Report the command result and installed version, and check for new application errors. Do not update other plugins or WordPress core.

The assistant can run plugin update <plugin-slug> after the backup succeeds. A successful command is one check: also verify the affected pages and features in the browser. If recovery is needed, review restoring a backup as a separate decision, since restoring replaces newer site data.

Follow long-running commands

For a command that may take time, ask the assistant to use async: true. A pending response contains an id; pass it as command to wp_get, together with the project identifier. Continue checking until the command reports success, error, or cancelled.

wp_list finds recent commands, and wp_get retrieves their metadata and paginated output. A client timeout does not establish whether the command failed. Inspect its status before retrying a change. wp_cancel_or_delete can cancel an operation or delete its history, but does not undo changes already made.

Command limits

Commands are non-interactive and can run for up to 180 seconds. Interactive commands such as shell and db cli, WP-CLI aliases, and the --prompt, --ssh, --http, and --path flags are rejected. Agiler selects the target installation from the project argument.

Commands that normally request confirmation may need --yes. Review their effect before authorizing them; adding that flag bypasses the command’s own prompt. On a multisite project, specify the intended subsite with --url for commands that support it, and make the site or network scope explicit in your request.

See the MCP tool catalog for the execution tools, or troubleshooting for failed operations.