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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes beyond them with real operational context: quota treatment (no charge against the daily free limit), result caps (20 addresses / 20 companies), and the caveat that the origin's protection limit still applies. Return-format details remain thin, keeping it short of a 5.

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?

Three compact clauses, front-loaded with what the tool returns and immediately followed by the most decision-relevant fact (no quota cost). No filler sentences, though the `pontos_total` field reference sits slightly awkwardly mid-sentence.

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 single-parameter read tool with full annotation coverage and no output schema, the description supplies what an agent needs: scope, caps, a named response field, and quota behavior. Nothing consequential to correct invocation is missing.

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?

With one parameter at 100% schema description coverage, the schema already documents `cep` including hyphen tolerance. The description adds only the gloss '(Brazilian postal code)', which is mildly helpful but not semantic content the schema lacks. Baseline 3 is appropriate.

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 the resource precisely — addresses and companies at a Brazilian CEP — and even clarifies the acronym for non-Brazilian readers. The retrieval verb is implicit but unambiguous. It does not, however, distinguish itself from near-identical siblings such as consulta_cep and cep, so an agent must still guess which of those overlaps to pick.

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?

There is no statement of when to use this tool versus consulta_cep, cep, consulta_cnpj, or empresas, despite the sibling list containing at least two plausibly overlapping CEP lookups. Quota remarks ('does not count against the daily free limit') hint at a preferred use case but never convert that into explicit routing guidance.

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