Skip to main content
Glama

wp_sync_option

Sync WordPress wp_options rows (settings, ACF options) between environments with md5 verification. Select rows by exact names or LIKE pattern. Handles multisite subdomains automatically. Requires confirm for production writes.

Instructions

SYNC one or more wp_options rows (site/plugin settings, and ACF OPTIONS-PAGE data) from one environment to another, with a mandatory md5 round-trip verification. This is the options-table counterpart to wp_sync_post_meta: use it for settings that live in wp_options, which the post tools cannot reach (they only handle a post's content and post meta). Select rows two ways: option_names=[...] for exact names, OR like='prefix%' for a SQL LIKE pattern. NOTE for ACF repeaters/nested groups: a repeater is stored as a parent count row (options_), numbered sub-rows (options_), AND a parallel set of underscore-prefixed field-key references (options...). To copy one completely, match BOTH prefixes — run once with like='options_%' and once with like='options%', or enumerate the rows in option_names. Matching only 'options_%' omits the field references and ACF will not render the group. Each stored option_value is PHP serialize()'d on the source, base64-encoded IN CODE, and rebuilt verbatim on the destination (delete-then-add, values re-interpreted only via maybe_unserialize so arrays/objects round-trip byte-for-byte). The destination is re-read and md5-compared; a mismatch returns verified=false, never silently trusted. Multisite: pass from_subdomain / to_subdomain as a BARE subdomain to target a subsite per side; URL handling is AUTOMATIC PER-SIDE — each side is checked against its own environment and the correct --url is resolved from that environment's live blog table (a given subdomain → that blog; none → the main 'www' site), and single-site environments get no --url. You never construct a URL, and it stays correct even when local and production use different domains. 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 options TO. May equal 'from' when copying between two DIFFERENT subsites of one multisite (set from_subdomain != to_subdomain); otherwise it must differ from 'from'.
fromYesSource environment to read options FROM.
likeNoSQL LIKE pattern selecting every matching option_name (e.g. 'options_my_repeater%'). Mutually exclusive with 'option_names'. For ACF repeaters, also copy the '_options_<field>%' field-reference rows.
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.
from_envNoTerminus environment override for the SOURCE when from='production'. Omit for TERMINUS_ENV.
option_namesNoExact option names to copy. Mutually exclusive with 'like'; one of the two is required.
to_subdomainNoBare subdomain of the DESTINATION multisite subsite. Omit for the main 'www' site. Ignored on single-site environments. The full --url is resolved from the destination environment automatically.
from_subdomainNoBare subdomain of the SOURCE multisite subsite (e.g. 'shop'). Omit for the main 'www' site. Ignored on single-site environments. The full --url is resolved from the source environment automatically.
Behavior5/5

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

Discloses mandatory md5 verification, delete-then-add strategy, PHP serialize/base64 round-trip, automatic URL resolution for multisite, transport resolution, production guard, and that content never passes through caller's text.

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?

Front-loaded with key purpose and behavior; however, the description is lengthy due to complexity. Nearly every sentence adds value, but some redundancy exists (e.g., md5 mentioned twice).

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

Completeness3/5

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

Covers input behavior comprehensively but lacks explicit description of return values/output beyond mentioning verified=false. No output schema exists, so description should detail full response format.

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

Parameters5/5

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

Adds meaning beyond the 100% schema coverage by explaining mutual exclusivity of option_names and like, ACF repeater behavior, confirm purpose, and subdomain/URL resolution details.

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', the resource 'wp_options rows', and distinguishes it from siblings like wp_sync_post_meta by explaining that this tool handles settings that post tools cannot reach.

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?

Explicitly advises when to use this tool vs alternatives (for options not reachable by post tools), explains two selection methods, warns about ACF repeater copying needing both prefixes, and notes when confirm is required for production.

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