Frontman for WordPress

wp_update_customizer_setting

Destructive

Save one confirmed supported registered Customizer setting using native validation, sanitization and save. Read it first and supply its fingerprint and active stylesheet. Conflict detection is best-effort, not atomic. Reread after any failure or lost response; never retry automatically. Verify the rendered site separately.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_id": "<site_id>",
      "id": "<id>",
      "value": "<value>",
      "stylesheet": "<stylesheet>",
      "expected_fingerprint": "<expected_fingerprint>",
      "confirm": "<confirm>"
    },
    "name": "wp_update_customizer_setting"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`value`	Yes
`confirm`	Yes	Must be true after user approval.
`site_id`	Yes	The connected site's id returned by list_sites. Call list_sites first; do not use a URL or WordPress post ID.
`stylesheet`	Yes	Active stylesheet from the read.
`expected_fingerprint`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare destructive=true, idempotent=false, readOnly=false, openWorld=true, so the risk profile is known. The description still adds real value beyond them: conflict detection is "best-effort, not atomic", no automatic retries, reread after failure, and separate verification of the rendered site. Strong content, but it does not describe what happens to unmentioned settings or what a failure response looks like.

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

Conciseness5/5

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

Five short sentences, front-loaded with the action and followed by preconditions, then caveats and recovery. No filler; each sentence carries a distinct operational instruction.

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

Completeness4/5

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

For a destructive write with no output schema, the description covers prerequisites, conflict semantics, retry policy, and post-write verification. Remaining gaps (what "supported registered" excludes, accepted value types, error shapes) are modest but real.

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?

With 50% schema coverage across 6 required params, the description compensates partially: it explains that a fingerprint from a prior read and the active stylesheet must be supplied, and ties confirmation to user approval. It says nothing about the meaning or accepted shape of "id" or the polymorphic "value", which the schema also leaves bare.

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

Purpose4/5

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

Names a specific verb and resource ("Save one confirmed supported registered Customizer setting") and constrains scope to a single setting, which implicitly separates it from bulk/theme-mod siblings. It does not name the read tool (wp_get_customizer_setting) explicitly, so the sibling routing is implied rather than stated.

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

Usage Guidelines4/5

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

Gives a clear precondition workflow: read first, supply fingerprint and active stylesheet, confirm after user approval. It also states a hard prohibition ("never retry automatically") and a follow-up obligation (reread, verify rendered site). Lacks explicit when-not-to-use / named alternative, so it falls short of a 5.

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

All Frontman for WordPress tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.