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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds substantive behavioral facts: only the list owner may act, existing contacts are not overwritten, normalized duplicates can shrink the final count, and importing grants no email/text permission and sends no messages. These are exactly the side-effect and authorization details an agent needs and would not get from the structured fields.

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?

Dense but efficient: the action and its inputs are front-loaded, followed by authorization, side-effect, and permission caveats in short declarative sentences. Every sentence carries information, with only the resource pointer as a minor tail.

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 non-idempotent mutation with a nested payload and no output schema, the description covers the critical unknowns — auth requirement, overwrite behavior, count effects, and permission side effects — and points to a workflow resource. It omits what the tool returns or how failures/reviewHash mismatches are surfaced, a minor gap given no output schema exists.

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 67% and the generic payload description only vaguely mentions 'reviewHash where required.' The description compensates by telling the agent that confirm requires jobId plus the exact reviewHash while cancel needs only jobId, which is more actionable than what the schema conveys, though it does not fully document the remaining payload fields.

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?

The description states a specific verb+resource (confirm/cancel a contact import) and pinpoints the two operating modes with the exact identifying arguments (jobId and reviewHash). It distinguishes this confirmation step from the earlier analysis step it depends on, though it never names sibling tools like inspect_contact_import or import_contacts_to_list explicitly.

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?

It gives a clear precondition — the organizer must first see the import analysis and confirm — and maps the two branches (confirm with jobId+exact reviewHash, or cancel with jobId). No explicit when-not conditions or named alternatives are provided, so it stops 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.