Kimi Code CLI WordPress MCP. New home, new commands.

When the PHP check passes: trying your build on staging

The first Kimi Code task answers one question: does the site's PHP meet what the repository's plugin asks for. If it does, the next step is to try the build on a staging copy. Getting the files there belongs to your normal deploy route; installing plugins through GoBuildWP needs Developer Full Access, which is not a profile to switch on for convenience. Once the plugin is on staging, Kimi Code can take over the checks.

wppilot/activate-plugin runs the plugin's own activation hooks, can take the site down with a fatal error, and therefore always requires explicit confirmation. It is recorded in the change ledger, and wppilot/rollback-change can put the plugin back to inactive, but that only reverses the activation status: whatever the plugin's activation hook created or changed, such as tables, options or scheduled events, stays until you remove it. After activation, ask Kimi Code to run wppilot/verify-rendered-page on the pages the plugin touches and wppilot/site-health-tests, and to quote any PHP error a visitor would see rather than summarising it.

• "Activate the plugin whose folder matches this repository with wppilot/activate-plugin. Show me the confirmation request first."
• "Run wppilot/verify-rendered-page on the home page and the contact page and quote any PHP notice or unrendered shortcode."
• "If anything failed, tell me the change ID so I can deactivate the plugin again with a rollback, and list anything its activation created."

Writing permission rules for WordPress tools in Kimi Code

Kimi Code names an MCP tool by joining mcp, the server name and the tool name with double underscores, and its rules accept single and double star wildcards. A rule on the server name with a trailing wildcard covers every WordPress tool at once, which is convenient and too broad for anything except a site on Read Only. Narrower rules that match only the read abilities are better, but look at the exact tool names /mcp shows before writing them: the names the client sees can differ in spelling from the ability IDs on GoBuildWP's reference pages.

Unmatched tools prompt, with an option to approve for the rest of the session. That option is a reasonable middle ground for reads during a working session. For writes, approve each call; the arguments in the prompt are the last place to catch a wrong post ID.

Clean up after kimi migrate

Migrating from the archived Python kimi-cli copies the WordPress server across but not its authorization, so you sign in again from Kimi Code. The old CLI's grant does not disappear on the site when you do. Open Connected Apps in wp-admin, find the authorization the legacy client created, and revoke it once Kimi Code has completed a read; if the old setup used an Application Password or a token instead, revoke that. Then delete the entry from ~/.kimi/mcp.json so nothing on the machine can quietly reuse it.

Long site reads without raising every timeout

KIMI_MCP_TOOL_TIMEOUT_MS raises the call timeout for every server at once, which is a blunt fix for one slow WordPress job. A site-wide content audit does not need it: wppilot/audit-content in background mode starts a job for the whole site and returns a job ID straight away, and wppilot/audit-content-status reads the progress and the findings so far, a page at a time. Ask Kimi Code to start the job and poll its status, and each call stays short however large the site is.

Kimi Code with or without GoBuildWP Cloud

Kimi Code is not on the GoBuildWP Cloud list of tested apps. Cloud accepts any client with remote Streamable HTTP servers, so the Cloud link as a bare url with /mcp-config login is the route to try, and a Cloud personal access token through bearerTokenEnvVar is the fallback if the sign-in does not complete. Until you have seen it work, a direct entry per site is the supported setup.