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

Even though annotations already provide idempotentHint, destructiveHint, and readOnlyHint, the description adds rich behavioral detail: it clears awaiting_manager_decision, status remains 'Completed', project stays archived, and auto_completed_at is preserved as history. It also discloses the permission requirement and the fact that this records a human decision, going well beyond the structured annotations.

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?

The description is four sentences, each earning its place: purpose, state-change details, alternative routing, and human-judgement warning. It is front-loaded with the main action and contains no filler or repetition.

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 single-parameter tool with no output schema, the description covers the action, the state transitions, the permission model, and the boundary against misuse. Nothing necessary for an agent to invoke this tool correctly is missing.

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?

The input schema only says project_id is a string, with 0% schema description coverage. The description implies project_id identifies the auto-completed project being confirmed, but it never explicitly states that project_id is the ID of the project to confirm. The single obvious parameter reduces ambiguity, but the description does not fully compensate for the lack of schema-level parameter documentation.

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 names a specific verb ('Confirm'), a precise resource type ('a project the nightly automation closed for passing its end_date'), and clearly separates this from the sibling projects_reactivate. It also states the core outcome: recording a human judgement that the project is truly finished.

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 explicitly says when to use the tool ('Confirm that a project... really is finished'), when not to use it ('Never call this to tidy up a list'), and which alternative to choose ('Use projects_reactivate instead if the work is still running'). It also names the authorized actors, making usage conditions fully explicit.

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