Skip to main content
Glama

wp_block

Operate on one Gutenberg or ACF block per post with list, get, insert, replace, update-attrs, remove, move operations using WordPress core parsing to avoid post_content corruption.

Instructions

Surgically operate on ONE Gutenberg/ACF block of a single post without disturbing the rest of the body. This is the block-level primitive that whole-body wp_sync_post lacks: insert, replace, read, update-attrs, remove, or move exactly one block while every other block stays byte-identical. Use it INSTEAD of hand-written str_replace/eval surgery on post_content (which repeatedly corrupted markup: base64 transcription bugs, self-closing /--> terminators, multisite --url errors). All parsing/serialization runs in WordPress core (parse_blocks / serialize_blocks) via one PHP eval — never string surgery — so self-closing ACF blocks, inner blocks, and freeform HTML round-trip faithfully. ops: 'list' (ordered block summary: index, blockName, anchor, attr/ACF-data keys), 'get' (one block's parsed attrs + exact markup), 'insert' (add a block at a position), 'replace' (swap the matched block), 'update-attrs' (merge ACF field values into the matched block's attrs.data, preserving existing _field key pointers), 'remove' (delete the matched block), 'move' (reorder). Selectors: 'name:' (first of type), 'name:#' (Nth, 0-based), 'anchor:', or 'index:' (Nth top-level block). The block arg is either raw block markup OR an object {name, data} where data merges into the ACF attrs.data. Content never passes through the caller's text: post_content is read on the server, payloads are carried base64 in code, and every write RE-PARSES the saved post and reports verified=true only if the round-trip md5 matches. Read ops (list/get) are never guarded; write ops on target='production' require confirm=true when PROD_GUARD is enabled (a preview of the change is returned instead when blocked). Pass preview=true to get the intended change without writing. Transport (local Docker / Terminus / SSH) is resolved from wp-cli.conf exactly like wp_cli.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYesThe block operation to perform.
envNoTerminus environment override (e.g. 'dev', 'test', 'live') for target='production' on a Terminus site. Omit for the site's TERMINUS_ENV.
dataNoFor op='update-attrs': field -> value pairs merged into the matched block's attrs.data (ACF). Existing _field key pointers are preserved.
siteNoWhich configured site to target (matches a [site:NAME] section in wp-cli.conf). Omit for DEFAULT_SITE or the sole site.
blockNoThe block to insert/replace, as raw block markup (string) OR an object {"name": "acf/...", "data": {field: value}}. For the object form, data merges into the ACF attrs.data. Required for insert/replace.
targetNoWhere the post lives. 'local' = Docker container (default). 'production' = remote environment; transport (Terminus vs SSH) is chosen by the site's conf.local
confirmNoRequired to write to a production post when the guard is enabled. Default: false.
post_idYesThe post whose blocks to operate on.
previewNoFor write ops: compute and return the intended new post_content (new_md5, new_content_b64) WITHOUT saving. Default false.
positionNoWhere to insert/move: 'first', 'last', 'index:<N>' (before top-level index N), 'before:<selector>', or 'after:<selector>'. For insert, defaults to 'last'. Required for move.
selectorNoWhich block to target. 'name:<blockName>' (first of that type), 'name:<blockName>#<N>' (Nth, 0-based), 'anchor:<anchor>', or 'index:<N>' (Nth top-level block). Required for get/replace/update-attrs/remove/move.
dedupe_byNoFor op='insert': skip the insert (idempotent) if a block already matches by 'anchor' or 'name'. Omit to always insert.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses many behavioral details: parsing uses WordPress core functions via PHP eval, not string surgery; content is handled via base64; guard mechanisms for production; preview mode; verified=true on round-trip; transport resolved from config. No contradictions with annotations (none present).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but verbose, spanning multiple paragraphs. It is front-loaded with the purpose and logically structured, but contains many details that could be streamlined for conciseness. An agent may need to parse through substantial text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (12 parameters, 2 required) and no output schema, the description covers all essential aspects: all operations, selectors, block formats, safety mechanisms (preview, confirm), transport, and return value descriptions. The agent has sufficient information to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds some operational context (e.g., block arg formats, selector syntax) but much of this is already present in the schema descriptions. The additional value is more about tool behavior than parameter semantics specifically.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool performs surgical operations on a single Gutenberg/ACF block of a post. It specifies the verb ('surgically operate') and the resource ('ONE Gutenberg/ACF block of a single post'). It distinguishes itself from sibling tools like wp_sync_post by emphasizing block-level granularity and avoiding string surgery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: for block-level operations like insert, replace, read, update-attrs, remove, or move. It advises using it INSTEAD of hand-written str_replace/eval surgery, citing corruption issues. It contrasts with the whole-body wp_sync_post, providing clear alternatives and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EarthmanWeb/mcp-wp-cli-terminus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server