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

No annotations are provided, so the description carries the full burden. It discloses the vintage-respecting behavior of the as_of parameter ('never uses data published after this date'), which is a meaningful behavioral trait. It also discloses that telemetry fields are safe to omit and that the capability is free and always returns 200. It doesn't describe the output shape, but an output schema exists, so that burden is partially lifted.

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 well-structured with clear sections: what it returns, when to use, when not to use, and parameter explanations. Every sentence earns its place, and the key information is front-loaded. The use of 'Use when' and 'Do not use when' headers makes it scannable for an agent.

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 read-only snapshot tool with an output schema and zero required parameters, the description is nearly complete. It covers the data returned, the historical vintage behavior, the alternative tools, and the optionality of telemetry fields. The only minor gap is not explicitly describing the output structure, but the output schema exists and the description's purpose is to add value beyond structured fields.

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%, so the description must compensate. It explains the as_of parameter's meaning and vintage behavior, and clarifies that the telemetry/access-policy fields are optional and safe to omit. The synthetic_identity parameter is not mentioned, but it is a boolean with a default, and the description covers the main semantic parameters well.

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 specific verb ('Returns') and resource ('Brazil's current policy rate (Selic target) plus realized short-term rates (Selic 252, CDI) and the last Copom decision'). It clearly distinguishes itself from siblings by naming get_brazil_copom_path and compare_brazil_market_vs_focus as alternatives for forward-looking expectations. An agent can tell exactly what this tool provides.

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 explicitly states when to use ('when you need the current or historical Brazilian policy rate, or the most recent Copom decision, without needing forward-looking pricing') and when not to use ('Do not use when: you need market expectations for FUTURE meetings'), naming the specific sibling tools to use instead. This is explicit routing guidance.

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