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

Annotations only cover readOnly/openWorld, so the description carries meaningful extra weight: it discloses that no personal data is returned, that payment is $0.05 USDC per *successful* call, and that x402 on Base or Solana is used absent an API key. That billing/authorization context is exactly what annotations cannot express. It falls short of 5 only because the response shape and what counts as an unsuccessful (unbilled) call are unstated.

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 short clauses: what it validates, the data-scope caveat, and the pricing/auth model. The core purpose leads and no sentence is padding. Tight for the amount of ground covered.

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 one-param, annotation-backed read tool with no output schema, the description covers purpose, data scope, and the unusual x402 payment requirement — the highest-risk unknown for an agent. Only minor gaps remain (no hint of what a valid-vs-invalid result looks like, no mention of whether region is returned as a code or name).

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% — the single 'cpf' parameter is documented as 11 digits with optional punctuation and bounded 1-200 chars. The description adds nothing about the parameter beyond that, so the baseline 3 applies.

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?

Names a specific verb ('checks') and resource ('Brazilian CPF'), and enumerates what is verified: format, check digits, issuance region. It implicitly separates from br_cnpj (CPF = individual, CNPJ = company) but never names the sibling, so differentiation relies on the agent's own knowledge.

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?

'Validation only: no personal data' frames the appropriate use case and warns off anyone expecting enrichment data. However, no alternative is named — an agent handling Brazilian company data gets no pointer to br_cnpj — and there are no explicit when-not-to-use conditions.

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