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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), so the description doesn't need to restate those. It adds useful behavioral context by explaining that the tool can return monthly readings over time and that the 'historical' flag and date range affect output. This goes beyond the structured annotations, though it omits details about edge cases or output structure, which is acceptable given the read-only nature.

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 two sentences, front-loaded with the source and purpose. There is no fluff or redundant information. Every clause contributes to understanding the tool's function, making it highly concise and well-structured.

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 the tool's simplicity, the presence of an output schema, and annotations covering safety, the description is sufficient. It explains the core behavior and key parameters. The omission of sortBy/sortOrder details is minor because the schema examples provide some context, and the tool's purpose (returning monthly inflation data) is clearly conveyed.

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?

The schema has 6 parameters with 0% description coverage, so the description must compensate. It explains 'historical' and 'start/end' date range, and indirectly 'country' via 'for Brazil or other countries'. However, it does not explain 'sortBy' or 'sortOrder', and does not specify expected formats (e.g., date format, country codes). This adds marginal value but leaves a notable gap for two parameters.

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 clearly states what the tool does: it provides inflation index series (IPCA/CPI) for Brazil or other countries, returning monthly readings. It distinguishes itself from sibling tools by focusing specifically on inflation data, and the verb 'returns' is implied in the functionality. This is highly specific and does not rely on the title alone.

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?

Usage is implied by the tool's purpose: it is for retrieving inflation data, so an agent would use it when needing inflation indices. However, there is no explicit guidance on when to use it vs. alternatives (e.g., currency, crypto) or any exclusions. The description does not mention alternative tools or provide when-not-to-use context, so it falls short of explicit usage guidelines but is still clear enough to infer.

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