Assess readiness for a robotics deployment

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description is free to add domain behavior: 'no' answers become blockers, unanswered items are returned separately, and matching platforms are 'ordered by strength of evidence'. That scoring and ordering logic is real context an agent cannot infer from annotations, though it stops short of explaining how bands are computed or what the evidence strength scale is.

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?

Three sentences, front-loaded with the core action and its outputs, then workflow, then the scope exclusion. The middle output-enumeration sentence is long and dense, but nearly every item listed (blockers, unanswered, weakest area) is decision-relevant, so little is waste.

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?

An output schema exists and the parameter schema is fully documented, so the description does not need to carry return-value detail — yet it usefully previews the shape anyway. Coverage of the no-answers-first workflow, matching behavior, and the non-recommendation limit makes this sufficient for correct invocation; only the scoring/banding mechanics remain unstated.

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 the baseline is 3. The description still earns above baseline by explaining the two-phase use of `answers` (omit it to get every question back) and by tying `environment`, `sector` and `family` to what gets matched, which tells the agent why those three filters matter rather than just what they are.

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 ('Run the deployment guide's readiness assessment') and enumerates what it returns: per-area and overall scores, band, weakest area, blockers, unanswered questions, plus matching platforms and deployments. This clearly separates it from siblings like compare_physical_ai_platforms or calculate_physical_ai_roi, which are comparison and economics tools rather than readiness scoring.

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 invocation pattern ('Call with no answers first to receive every question') and a clear trigger ('Use this when an organisation asks whether it is ready to deploy robots'). It also carves out a when-not ('It never recommends a purchase'), though it does not name the sibling tool an agent should switch to for purchase or ROI questions.

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