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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context about coverage (no Brazilian professionals listed; lawyers and lenders never listed), but it never explains what the response actually contains or where the 'checking' occurs.

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?

Two sentences with the country scope front-loaded and no filler. The first sentence is dense but packs the trade-to-regulator mapping efficiently; the second sentence earns its place by setting coverage boundaries.

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?

With no output schema, the description carries the return-value burden and only partially discharges it: it conveys the regulators per trade but not the shape of the answer (a body name, a URL, a lookup instruction). For a one-parameter read-only lookup that is borderline adequate, but an agent cannot predict the response.

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%, so the single 'trade' parameter is already fully documented with the same value list. The description restates the values and maps each to a regulator (CRECI, CNAI, CREA/CAU, Banco Central, OAB), but that mapping is output content rather than added input meaning, so the baseline of 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?

The description states a specific resource (Brazilian property professionals) and function (where a registration is checked), opening with 'BRAZIL.' so it is clearly distinguishable from the many check_professional_XX siblings. It also clarifies what the tool is not (a listing of professionals). It stops short of naming a sibling tool, and the deliverable ('where the reader checks a registration') is phrased indirectly.

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 trade list and the note that Payotte 'lists no Brazilian professional yet, and never lists lawyers or lenders' imply when the tool applies and its coverage limits. However, no alternative tool is named and no explicit when-to-use/when-not instruction is given relative to siblings like verify_license_us or trouver_professionnel_fr.

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