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

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to re-establish safety, and it correctly spends its words elsewhere: result caps, the absence of recommendation text, and pay-per-call billing ('$0.002 in USDC per successful call... failed calls are not charged'), which is genuinely useful operational context an agent would otherwise not have. The only shortfall is that nothing is said about behavior when a gene symbol yields no CPIC guideline, which for an open-world lookup is a plausible empty result the agent may need to interpret.

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?

Core capability, scope limit, and call cap are front-loaded in the first two sentences, with routing to alternatives and pricing after — good ordering. Minor waste remains in the sibling clauses, which read as pasted-in fragments ('...health interventions, found'; missing prepositions such as 'for a different need' followed by a bare tool name), so the sentences are slightly longer and less polished than they need to be.

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 two-parameter read-only lookup this covers everything an agent needs: what is returned, what is deliberately excluded, the per-call ceiling, the alternatives for adjacent needs, and the billing model. An output schema exists, so return-format detail is correctly delegated rather than restated.

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 both params carry their own descriptions, so the baseline of 3 applies. The description's 'Up to 20 guidelines per call' corroborates and bounds the max parameter, but adds no interpretation of the gene symbol format or matching behavior beyond what the schema already states.

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 names a specific verb and resource ('CPIC pharmacogenetics guidelines (api.cpicpgx.org) for a gene symbol') and enumerates the returned fields: guideline name, genes covered, version, ClinPGx link. It also explicitly scopes itself against the two named siblings, so an agent can route between CPIC, Cochrane, and ClinicalTrials.gov without inspecting any 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?

It states an explicit exclusion ('Lists guidelines only; recommendation text is not included') and names each alternative with the condition that selects it ('health_clinical_evidence_cochrane when you need Cochrane systematic reviews', 'health_clinical_trials_gov when you need ClinicalTrials.gov study search'). The trial-and-error surface for choosing among these three tools is essentially zero.

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