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

Annotations declare readOnly/idempotent/non-destructive, and the description goes well beyond them by disclosing determinism ('No model: the same result every time'), the closed rule set, the four possible output levels including the fallback 'routine when no rule fires', and that each firing rule carries its source sheet. That is substantive behavioral context an agent cannot get from annotations alone.

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?

Two tight paragraphs, front-loaded with scope followed by routing guidance; every element earns its place. Slightly dense prose, but 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?

Given an output schema exists, the description needn't describe return values, and it still sketches them (level, fired rules with source, warning text, emergency number). Combined with the routing guidance and determinism note, an agent has everything needed to select and call the tool correctly.

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 description coverage is 100% and the schema already documents lang, country (including ISO 3166-1 alpha-2 format) and the symptoms field with the age hint. The description's mention of 'eight languages and four scripts' and 'the country's emergency number' restates rather than extends the schema, so the 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?

The description states a precise verb and resource ('checks a description of a child's symptoms against 96 fixed warning-sign rules'), names the rule coverage, the eight languages/four scripts, and the exact symptom domains covered. It is instantly distinguishable from siblings like paediatric_question_with_sources or oral_rehydration_plan.

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?

It gives an explicit trigger ('Use when symptoms are described, first, to know if the child needs emergency care...'), an explicit ordering ('first'), and routes the agent to two named alternatives with their own conditions (full explanation afterwards; fluids-only cases). Nothing 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.