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

Adds substantial context beyond the annotations: 35-50s latency, the async running/polling contract, a daily free-answer limit surfaced via free_answers_remaining_today, grounding reporting of uncited parts, and a privacy warning against patient identifiers. These are exactly the traits an agent needs that annotations (readOnlyHint/openWorldHint/idempotentHint) do not convey.

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-loads the purpose, then layers behavioral details (latency, polling, limits, privacy) in a logical order. Every sentence carries information; slightly verbose but no filler.

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?

With an output schema present, return-value explanation is rightly omitted, and the description covers the async pattern, cost limit, grounding, and privacy constraints. The only material gap is the undocumented locale parameter, which leaves a small incompleteness for a 2-param tool.

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 0% and neither parameter is explained in the description. The 'question' parameter is inferable from the tool's purpose, but 'locale' is never mentioned and constraints (8-2000 chars) go unstated, so the description does not compensate for the coverage gap.

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 ('full CliniAtlas answer ... with numbered citations') and specifies the sources searched (literature, guidelines, EMA documents). This cleanly separates it from the retrieval/sibling tools like lookup_pubmed and search_evidence_library, which return evidence rather than a synthesized cited answer.

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 explicit scope guidance ('For literature research and education, not individual care decisions') and handles the async case by telling the agent to call get_cliniatlas_answer with job_id when status is 'running'. It does not, however, distinguish when to prefer this over get_evidence_answer or search_medical_evidence, so routing among the answering siblings is left implicit.

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