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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses notable data behaviors: race is null in 1998–2007 and the filter won't reach those years; ICSAP for 1992–1997 is derived from a non-official CID-9 list, making g03/g05 non-comparable; uf is the file's UF and municipality_code is null in that period; and the default universe excludes obstetric, delivery, and long-stay admissions. This is rich behavioral context that annotations cannot 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?

The description is a single dense paragraph, but it is tightly organized: purpose first, then filters, then critical data caveats, then the universe calculation. Each sentence carries distinct information and there is no filler or repetition. It remains readable despite the complexity.

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 10-parameter tool with historical data caveats, the description covers the major lifetime issues (race availability, ICD-9 revision change, municipality/UF basis) and the calculation universe. It points to get_available_years for additional notes, and an output schema exists so return format is not needed. Still, it could be slightly more explicit about the intended use case versus sibling tools like get_icsap_indicators, but overall it is near complete.

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?

While the schema already describes all 10 parameters (100% coverage), the description adds semantic caveats for parameters: it specifies the meaning of `race` null periods, the `uf` file-basis in 1992–1997, municipality_code null, and the `universe` exclusions. These nuances go beyond the schema's terse descriptions, particularly for uf and municipality_code.

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 opens with 'Consulta internações por Condições Sensíveis à Atenção Primária (ICSAP)', a specific verb and resource, and enumerates the available filters. However, it does not explicitly distinguish this tool from siblings like get_icsap_indicators or get_hospitalizations, so it misses the top-tier sibling differentiation.

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?

The description implies the tool is for querying ICSAP hospitalizations with filters, and it refers to get_available_years for data-revision caveats. It does not state explicit when-to-use vs alternatives, nor when not to use it (e.g., if the user needs indicators or trends). The guidance is mostly implicit through the tool's name and filter list.

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