ZCode (GLM) WordPress MCP. Add it on the MCP Servers screen.

Keeping ZCode's content inventory current

The first ZCode task saves a table of pages, posts and categories in the workspace so later GLM sessions can start from it. An inventory goes stale the moment someone edits in wp-admin, so give the agent a cheap way to notice. wppilot/get-page-snapshot returns a compact digest of a page, including content fingerprints and its modification state, which is enough to tell whether a row in the notes still matches the site without reading every page in full.

A practical rhythm is to refresh the table at the start of any session that will touch content, compare fingerprints, and re-read only the pages that changed with wppilot/get-content. Ask ZCode to record the date of each refresh in the notes, so you can see how old its picture of the site is. Keep the notes free of anything private the site returns, such as unpublished drafts or user details, if the workspace is shared or committed to a repository, because the file outlives the session that wrote it.

• "For every page in notes, call wppilot/get-page-snapshot and mark the rows whose content changed since the last refresh."
• "Re-read only the changed pages and update their rows. Do not edit the site."

With no documented approval model, limit what ZCode can reach

ZCode's documentation does not describe how it asks before calling an MCP tool, so plan as if it might not. That moves the safety decisions to the site, where GoBuildWP enforces them regardless of the client. Keep the site on Read Only while ZCode is only building inventories. When it needs to write, prefer an access token over the OAuth sign-in, limited to the abilities the task uses and given an expiry, because a token's scope also hides everything else from ZCode's tool list.

After any session that wrote, read the change ledger. wppilot/list-changes shows each write with the credential and client behind it, and wppilot/list-sessions shows what wppilot/undo-session could reverse: changes with a supported restore and saved before-state, provided nothing else edited those targets since. Irreversible items are listed, and the run is refused rather than half-done unless you allow a partial undo.

User servers, workspace servers and client sites

ZCode stores a server either for you, in ~/.zcode/cli/config.json, or for one workspace, in that project's .zcode/config.json. For agency work the workspace scope is the safer default: the staging site of the client whose repository is open is the only WordPress server the GLM agent sees, and opening another client's project never exposes the first one. Keep production sites out of the user scope altogether, so no workspace can reach them by default.

Disabling a server from the screen writes enable: false and keeps its settings, which is handy for a site you only touch occasionally. Leave it disabled between sessions; the agent cannot call a server that is switched off, whatever a prompt or a page on the site says.

Importing an existing WordPress entry

The import icon on ZCode's MCP screen can pull a WordPress server you already set up in Claude Code, Codex CLI or OpenCode. The configuration comes across; think about the credential. An OAuth entry will need its own Open authorization in ZCode, which gives ZCode a separate grant in Connected Apps, and that is what you want. A token entry, though, copies the header, and two clients sharing one token look identical in the ledger and can only be revoked together. Create a new token for ZCode and replace the imported one.

ZCode is not among the apps GoBuildWP Cloud lists by name. Its HTTP servers support OAuth through Open authorization, so the Cloud link may work the same way, but that has not been checked; a direct entry per site is the documented setup.