move_deal_stage

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description goes well beyond that: it explains the revenue-reporting side effect of resolution, the notification and deal-won webhook firing, the close-date re-stamp on repeat close, backwards/forwards movement, and the API-key requirement.

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 core action and analogy, then layered side effects in descending importance. Four paragraphs is more than minimal but every block carries distinct information, with only mild redundancy around the closed-stage warning.

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 2-param mutation tool with destructive annotations, no output schema, and full schema coverage, the description supplies exactly the missing behavioral layer: consequences, side effects, ordering semantics, and auth. Nothing an agent needs to call it safely is absent.

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 dealId and the newStage enum are already documented, setting the baseline at 3. The description adds the semantic meaning that stages are unordered and movement can go backwards, which is real value beyond field names but does not change the parameter contract.

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 (move deal to a different pipeline stage) and grounds it with a concrete analogy (dragging a card). It explicitly distinguishes itself from the sibling update_deal by scoping this tool to pipeline progression vs value and notes.

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 an explicit when-condition for the risky case ('only do it when the user says the outcome is settled') and names the alternative (update_deal) with a clear division of responsibility. Nothing about selection is left to inference.

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