Complete Update Set

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description complements them by disclosing the validation gate, the state read-back verification, and a real irreversibility caveat about reopening a set after another instance retrieved or exported it. It does not say what the failure mode looks like when expected_captures mismatches (error vs. partial completion), which is the remaining behavioral gap.

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?

Four dense sentences, front-loaded with the action and its required checks, followed by the sequencing and cleanup guidance. Every sentence carries operational information, though the precondition clause is packed into one long sentence that could be split for scanability.

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 mutating, multi-precondition tool with no output schema, the description covers preconditions, sequencing, post-condition verification, and the follow-up restore step. The only omission is the response shape and the exact behavior on a precondition failure.

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%, so the baseline is 3; the description earns above that by framing expected_captures as the count the agent reviewed and pointing at inspect_update_set as the way to obtain it, tying the parameter to a workflow rather than restating the schema.

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 verb and resource with scope qualifiers ('Complete an In progress, non-Default update set'), which immediately separates it from create_update_set, clone_update_set, and get_current_update_set. The phrase 'after checking what it holds' signals the validation contract up front.

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?

Gives explicit preconditions (capture count equals expected_captures, no other user working in the set, every capture belongs to the set's application), an explicit when-not ('complete only when the work is done and reviewed'), and names the alternatives: inspect_update_set for review and restore_update_set for putting the previous working set back.

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