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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description adds the important non-obvious behavior that the plan text is never accepted ('the plan itself stays with you') and that the human does the per-practice judgement. It also discloses the shape of the return (do-first practices as a checklist with evidence rating and supporting wording, plus how to find similar cases). Minor gaps: no note on result caps or what happens when size/industry are omitted.

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 purpose and the board example, and the division-of-labour sentence ('You read the plan and decide...') earns its place. It is on the long side at four sentences, and the 'Pass the size and industry' sentence is the weakest given the schema already covers it.

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?

No output schema exists, and the description compensates well by describing the returned checklist, its evidence ratings and the 'how to find similar cases' component, plus the human-in-the-loop workflow. It is nearly complete for a read-only, three-optional-parameter lookup; only the optionality of size/industry and fallback behavior are left unaddressed.

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%, including enum values and the micro-small/medium/mid-market/enterprise bands, so the schema carries the semantics. The description only says 'Pass the size and industry', adding nothing about the enum mapping or the employees alternative — and it slightly implies both are required when nothing is. Baseline 3 is appropriate.

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 ('Review') and specific resources (AI transformation proposal, business case, rollout memo), plus a concrete timing example ('before it goes to a board'). It also fences itself off from the sibling that handles a narrower job ('For one figure in the plan, use check_ai_figure'), so an agent can distinguish it from check_ai_figure and find_practices without opening either schema.

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?

Names one alternative explicitly with the condition that selects it ('For one figure in the plan, use check_ai_figure'), which is genuine routing guidance rather than an implied hint. It gives clear context for when to reach for this tool, but does not address the other plausible siblings (find_practices, board_brief, find_company_cases) or state what to do when the user has no plan in hand.

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