cwp mcp

cwp mcp [env] [flags]

Acts on the local site. Name an environment to act there instead.

Argument	What it is	Default
[env]	environment to point the client at (default: default_environment in cwp.yml)

Flag	What it does	Default
--client <name>	AI client (default: claude-code)	claude-code
--print	write the config block to stdout and do nothing else	off
--rotate	replace an existing application password of the same name	off
--force	override the protected-environment refusal	off
--no-backup	skip the remote backup taken before the write	on
--yes	answer the confirmation prompts with yes	off
--with-agent	with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real	off

Plus the shared flags --json, -v, --verbose, -q, --quiet and --dry-run.

What it does

Generates the MCP client configuration that points an AI client at one environment, and mints the application password it needs.

The setup is per site, per environment and per credential. Bricks’ own documentation says the skills repository cannot ship a .mcp.json for that reason. cwp knows every environment’s URL and owns the conduits that can mint a credential, so it fills that gap.

All 19 clients get the same server descriptor and differ only in the envelope. cwp emits the envelope in whichever of the seven shapes your client wants. A local DDEV site also gets NODE_TLS_REJECT_UNAUTHORIZED=0. Its certificate comes from a local CA that the bridge’s Node process does not trust.

You see the password once. WordPress stores only its hash, so cwp cannot print it again. So a second run refuses when a password of that name already exists and there is nowhere to deliver a new one, and tells you to pass --rotate. Rotating invalidates the credential every other client is using, so it is never silent.

--print writes the block to stdout and does nothing else. It does not combine with --json, since both claim stdout.

Re-running is safe

Before it writes anything to the site, cwp reads what Claude Code already has registered under that server name. That read changes nothing. Three outcomes:

• Nothing registered. The ordinary run: mint, print the config, offer to run the claude mcp add.
• Registered, and pointing here. If the site still holds the password that entry got, there is nothing to do. cwp says so and mints nothing: running setup twice does not cost you a working client. --rotate overrides it.
• Registered, and pointing somewhere else. cwp shows what differs (the endpoint, the user) and offers the replacement as one confirmed step. Its two halves are claude mcp remove in the scope that holds the entry, then claude mcp add. If the removal fails, cwp does not attempt the add: a working stale entry beats no entry.

The probe only reads, and it applies to the claude-code client alone. The other eighteen are config files you edit, where rewriting a key has no duplicate problem to inspect.

Example

cwp mcp                          # Claude Code, local site
cwp mcp --client cursor          # any of the 19 clients Bricks supports
cwp mcp --client codex --print   # just the config block, on stdout
cwp mcp prod --rotate            # replace the existing credential

What it does not do

It does not edit your client’s config files. Nineteen clients means nineteen merge semantics over JSON and TOML in paths outside your project, and cwp has no business there. The Claude Code form is the one exception, and a small one: it is a command line, so cwp offers to run it for you. It reads that same command line first, rather than removing an entry to find out whether it needed to.

It does not install the MCP Adapter plugin. It checks for it, and gives you the command.

It is not between the agent and WordPress. Once this command has wired the connection, the client talks to the site’s own MCP server directly, and no guard in cwp is in that path. Which site its credentials point at is what bounds an agent. Why cwp has the version of this that matters.