Skip to content

cwp abilities

shipped 1.0.0
cwp abilities [env] [flags]

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

ArgumentWhat it isDefault
[env]environment to read (default: default_environment in cwp.yml)
FlagWhat it doesDefault
--filter <text>substring of the name, label or description“
--with-agentwith —dry-run on a host with no shell: install and remove the PHP agent so the plan is realoff

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

What it does

Lists every ability a site registers, and what each one declares about itself.

The second column is the part that matters, because it is what decides which guards cwp ability applies:

✓ bricks/get-page-elements — read — Get page elements
! bricks/set-page-elements — write, destructive — Set page elements

Not restricted to bricks/. This is the plain door onto WordPress’s own Abilities API, so a plain WordPress site with abilities on it is served by exactly this command. A Bricks 2.4 site with the SNN-BRX child theme registers 175. 145 of them are Bricks’ own. The rest come from the child theme’s namespace, WordPress core’s and the MCP adapter’s.

--filter matches the name, the label or the description.

Example

cwp abilities                     # everything registered, locally
cwp abilities --filter revision
cwp abilities prod                # what production actually has
cwp abilities --json              # for a script

What it does not do

It reads and reports; it calls nothing.

It cannot make an unreachable ability surface reachable. If Bricks registered nothing at all, cwp doctor names which of the four causes it is: WordPress too old, Bricks too old, the AI surface switched off, or BRICKS_DISABLE_MCP set.