Skip to main content
Glama

wp_sync_post_meta

Copy all custom fields (meta) from a post to the same post ID in another environment with checksum verification. Updates existing destination post.

Instructions

SYNC a post's COMPLETE meta (all custom fields) onto the SAME post ID in another environment, with a mandatory checksum round-trip verification. This UPDATES an existing destination post that shares the source's ID; it does NOT create a post (use wp_clone_post to copy a post that doesn't exist on the destination yet). Preserves EVERYTHING: multiple values per key, serialized arrays/objects (e.g. ACF repeaters), and exact scalar representations — the raw stored meta map is PHP serialize()'d on the source, base64-encoded IN CODE, and rebuilt on the destination with each stored value written back verbatim (no re-interpretation). It then re-reads the destination and compares a canonical PHP-native digest to the transferred payload; a mismatch is returned as verified=false, never silently trusted. By default ALL meta keys are synced and any destination keys not present on the source are removed (full mirror). Pass keys=[...] to sync only specific keys (destination keys outside that list are left untouched). Content never passes through the caller's text. Transport (local Docker vs Terminus vs SSH) is resolved per side 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 meta TO. Must differ from 'from'.
fromYesSource environment to read meta FROM.
keysNoOptional allow-list of meta keys to copy (each must match [A-Za-z0-9_:.-]+). Omit to copy ALL keys and mirror the source (destination-only keys are deleted). When provided, only these keys are touched on the destination.
siteNoWhich configured site to target (matches a [site:NAME] section in wp-cli.conf). Omit for DEFAULT_SITE or the sole site.
to_envNoTerminus environment override for the DESTINATION when to='production'. Omit for TERMINUS_ENV.
confirmNoRequired to write to a production destination when the guard is enabled. Default: false.
post_idYesThe post ID whose meta to sync (SAME ID on both sides).
from_envNoTerminus environment override for the SOURCE when from='production'. Omit for TERMINUS_ENV.
Behavior5/5

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

Discloses critical behavioral details: mandatory checksum round-trip verification, preservation of serialized data, verbatim write with no re-interpretation, re-reads destination for comparison, content not passing through caller's text, and transport resolution matching wp_cli. No annotations provided, so full burden is met.

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?

Description is in a single paragraph but front-loads the core action and is concise given the complexity. Every sentence adds value, though some structure (e.g., bullet points) could improve readability. Still well within acceptable length.

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 tool's complexity (8 parameters, no output schema), the description covers all essential aspects: verification process, transport, production guard, default mirroring, and parameter effects. No critical gaps for an agent to misuse 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 has 100% parameter description coverage, but the tool description adds significant context beyond the schema: explains the mirroring behavior of the 'keys' parameter, the role of 'confirm' with production guard, and the override purpose of 'from_env'/'to_env'. Goes beyond baseline 3.

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?

Clearly states the verb 'SYNC' and resource 'post meta' with the specific action of transferring complete meta between environments with checksum verification. Distinguishes from sibling tool 'wp_clone_post' by explicitly noting it updates an existing post rather than creating one.

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?

Provides explicit when-to-use: updates existing post, does not create (references wp_clone_post for creation). Explains default full mirror behavior and the effect of the 'keys' parameter. Mentions production guard requiring 'confirm=true'. Offers clear alternatives.

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