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

Beyond the annotations, the description discloses meaningful behavioral effects: setting status to Active, unarchiving and restoring tasks, clearing auto_completed_at, and the consequence of an invalid end date on nightly automation. It also reveals permission boundaries. There is no contradiction with the readOnlyHint=false or destructiveHint=false 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 concise and front-loaded with the core purpose. Three sentences cover the action, side effects, constraint, and permissions without redundancy or filler. Every sentence contributes useful decision-making or invocation information.

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 state-changing operation with no output schema, the description covers almost everything needed: prerequisites, side effects, required parameter constraints, and authorization. Minor gaps are the lack of explicit project_id semantics and no mention of what happens if the project is not currently closed/archived, but these do not seriously hinder correct invocation.

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 exactly 50%: new_end_date has a schema description and the tool description reinforces it with the requirement and rationale. project_id, however, is left entirely to the parameter name and the tool's context; the description never explicitly defines it as the ID of the project to reactivate. This adds some semantic value but does not fully compensate for the missing project_id 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 states a specific verb ('Reopen'), resource ('a completed or archived project'), and what changes ('give it a new end_date'). It also distinguishes this from restore-like operations by enumerating the concrete state changes (status Active, unarchive, clear auto_completed_at), so an agent can clearly identify what the tool does relative to siblings.

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 gives clear context for when to use the tool: reactivating a previously completed or archived project. It also provides a critical usage constraint — new_end_date must be in the future or the nightly automation will close the project again — and names the required permissions. It does not explicitly name alternative sibling tools or spell out when not to use it, but the context is strong enough for an agent to make the right call.

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