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

Adds substantial context beyond the annotations: strict-mode abort-and-reverse semantics, the 7-day undo scope (restores meta, deletes created redirects), explicit cannot-recall sub-ops (IndexNow/GSC/cache purge), the snapshot caveat that undo does not restore from SiteVault, and the Royally approval gate. These are exactly the mutation and rollback traits an agent needs and that readOnly=false/destructive=true alone cannot convey.

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

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

Front-loaded with the pipeline then the mode/undo semantics, every sentence carrying weight. It is dense and repeats a few defaults already in the schema (e.g., opt-in flags), which slightly blunts efficiency but keeps the transactional story readable in one pass.

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

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

For a complex multi-step mutation tool with no output schema, the description covers the pipeline, failure modes, rollback, undo limits, and approval gating, which is nearly everything an agent needs to invoke safely. It could be stronger on what the response actually contains (plan vs receipt shape) and on cross-sub-op ordering guarantees, keeping it from a 5.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics the schema lacks: the ordering of sub-ops, which flags are opt-in vs default-on and why, and how compose_mode interacts with fix flags (report_only plans writes but executes reads). This is value-add beyond the per-parameter descriptions already present.

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

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

Provides a specific verb chain and resource ('transactional launch composer for a single post') plus an explicit ordered sub-op pipeline, so the agent knows this composes SiteVault snapshot, meta audit/fix, schema verify, redirects, IndexNow, GSC, and cache purge. It is distinguishable from single-purpose siblings like wp_update_seo_meta or seo_audit_meta_tags by scope (single post, multi-step, transactional). It stops short of naming those siblings explicitly, which would have earned a 5.

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

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

Clearly documents when to use each compose_mode: strict as default with rollback, report_only as dry-run where read-only sub-ops still execute, and opt-in flags for external pushes. It does not tell the agent when to prefer a narrower sibling (e.g., wp_update_seo_meta for a one-off meta fix) or when the launch composer is overkill.

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