Skip to main content
Glama

wp_sync_post

Sync a post's content to the same ID on another environment with mandatory md5 verification, updating the destination post without creating new ones.

Instructions

SYNC a single post's post_content onto the SAME post ID in another environment, with a mandatory md5 round-trip verification. This UPDATES an existing destination post that shares the source's ID (e.g. a multidev cloned from the same DB) — it does NOT create a post; if the destination ID is missing it fails. To copy a post that does NOT yet exist on the destination (creating a new post with a destination-assigned ID), use wp_clone_post instead. Use this instead of hand-assembling post update/eval calls to push post body content between local and production (e.g. update a front-page's block markup on a Pantheon multidev). The content NEVER passes through the caller's text: it is read from the source into the server, base64-encoded IN CODE, applied on the destination through a transport-safe PHP eval (STDIN eval-file for Docker/SSH so arbitrarily large posts work; size-guarded argv for Terminus), then re-read and md5-compared to the source. If the hashes differ, the tool reports verified=false and returns an error rather than leaving the destination silently unverified. Transport for each side (local Docker vs Terminus vs SSH) is resolved from wp-cli.conf exactly like wp_cli. Writing to a production destination requires confirm=true when the PROD_GUARD is enabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesDestination environment to write post_content TO. Must differ from 'from'.
fromYesSource environment to read post_content FROM.
siteNoWhich configured site to target (matches a [site:NAME] section in wp-cli.conf). Omit to use DEFAULT_SITE or the sole site.
to_envNoTerminus environment override for the DESTINATION when to='production' on a Terminus site. Omit to use TERMINUS_ENV.
confirmNoRequired to write to a production destination when the guard is enabled. Default: false.
post_idYesThe post ID to sync. Must be the SAME ID on both source and destination (they are assumed in sync, e.g. a multidev cloned from the same DB). The tool verifies the destination post exists and fails if it does not — use wp_clone_post to create a new post instead.
from_envNoTerminus environment override for the SOURCE when from='production' on a Terminus site. Omit to use TERMINUS_ENV.
only_blocksNoOptional allow-list of blockNames (e.g. 'acf/sps-celebrations-block'). When set, ONLY these top-level blocks are carried from the source; every OTHER block on the destination is kept as-is (the source and destination bodies are spliced block-by-block). Use this to push a changed block without clobbering blocks the destination edited independently. Mutually exclusive with except_blocks. For per-block edits prefer wp_block.
except_blocksNoOptional deny-list of blockNames to LEAVE ALONE on the destination while syncing everything else from the source (e.g. except_blocks=['acf/sps-hero-slideshow-block'] pushes the body but preserves the destination's hand-built slideshow). Mutually exclusive with only_blocks.
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: mandatory md5 round-trip verification, content never passing through caller's text, transport resolved via wp-cli.conf, production guard requiring confirm, and block filtering behavior (only_blocks/except_blocks). This gives agents complete understanding of side effects and constraints.

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

Conciseness4/5

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

The description is relatively long but well-structured, with core purpose first followed by details. Every sentence adds value, though some redundancy (e.g., repeating post_id conditions) could be trimmed. Overall, it is concise enough for the complexity.

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 9 parameters, no output schema, and no annotations, the description covers all necessary aspects: parameter semantics, verification, error handling (fails if destination missing), transport resolution, and production guard. It provides sufficient context for an agent to correctly invoke the tool.

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

Parameters4/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 contextual meaning beyond schema descriptions, such as explaining the splicing behavior for block filters and the overall verification process. However, each parameter's schema description is already clear, so the extra value is moderate.

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 the tool syncs a single post's post_content between environments with md5 verification. It explicitly distinguishes from sibling tools like wp_clone_post (for creating new posts) and wp_block (for per-block edits), making its unique purpose unambiguous.

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 provides explicit guidance on when to use (e.g., pushing block markup between environments) and when not to (if destination post doesn't exist, use wp_clone_post instead). It also mentions alternatives like wp_block for per-block edits and notes that confirm=true is required for production sites with PROD_GUARD enabled.

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