Working with an agent

An agent that builds a site calls wp, ddev and the host’s CLI on its own, or cwp as a shell command with --yes. Both go round what cwp knows: the guards, the plans, the families, the findings. cwp serve is the door that keeps them in.

Wiring it up

From the project directory, for Claude Code:

claude mcp add cwp -- cwp serve --allow-writes build

For any other client: a stdio server with the command cwp, the arguments serve --allow-writes build and the project directory as its working directory.

What the agent gets

Every runnable command as a tool, cwp_doctor to cwp_edge_captcha, with the command’s own arguments and flags. Reads run as they are. A write hands back its plan and an id, and cwp_apply runs the plan.

--allow-writes build opens cwp_apply for the local site and for environments whose stage is build. An environment in launch, live or handover never takes a write through the server; the tool answers with the command a person runs instead. The agent cannot pass that one rule with a flag, and it cannot move the stage either: cwp_apply refuses a config set for environments.<env>.stage and for defaults.backup_before_push, the two keys a guard reads. For that reason the stage sits in cwp.yml and not in a prompt.

What the agent learns from cwp

cwp_doctor, cwp_coverage and cwp_status say what the site holds and what the tree does not. The families under cwp/families/ say where a plugin keeps its state. An agent that reads those before it writes knows the site as cwp does, rather than as its own memory does.

What to keep in mind

The local site is a database a pull replaces, so an agent that writes it wrongly costs one cwp db restore; build opens the door on that account. The server refuses a plan that changed between the showing and the applying, so an agent that reads a plan and applies it later gets the plan again rather than a surprise.