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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds no context about what that destruction means, e.g. that resetting the baseline discards the previously accepted reference capture. It also doesn't say whether multiple fields can be combined in one call or what partial-update semantics apply, leaving the description to merely restate operations the schema already documents.

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?

A single front-loaded sentence with the main verbs first and zero filler. It is dense but readable, though the list of four operations could have been ordered to match importance.

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 7-parameter destructive mutation with no output schema, the description should warn that baseline resets are irreversible and clarify whether switching behaviour (enabled=false) stops checks immediately. Those gaps matter more than the operation list, which the schema already provides.

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 description coverage is 100%, including error behavior (BASELINE_FILE_NOT_FOUND) and target scoping (visualTargetId defaults to desktop), so the schema carries the load. The description only loosely maps operations to parameters ('rename' → label, 'turn on or off' → enabled) without adding format, precedence, or combination rules.

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?

States a specific set of operations (rename, enable/disable, reset baseline, accept capture as baseline) on a named resource ('extra page'), so an agent knows exactly what kind of mutation this is. It does not, however, distinguish itself from close siblings such as vs_visual_accept_baseline or vs_subpages_capture_now, which appear to overlap on the baseline/capture concept.

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?

The description implies when to use it (editing an existing extra page) but never states the conditions versus alternatives: vs_subpages_add for creation, vs_subpages_delete for removal, vs_visual_accept_baseline or vs_subpages_capture_now for capture/baseline flows. No prerequisites or exclusions are given.

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