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

Annotations declare readOnlyHint=false and openWorldHint=true, so the description's job is to add context — it does by noting the catalog lookup nature, ambiguity handling, and that locality centers are not a customer address (a scope caveat that prevents misuse). It doesn't explain why readOnlyHint is false for what sounds like a lookup, a residual gap.

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?

Five short clauses, front-loaded with purpose and then scope caveats; no filler. Slightly dense/telegraphic ('Province searches use provinceUuid' arrives without setup), but every sentence carries information.

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?

Output schema exists, so return values needn't be explained, and the one parameter is fully documented in the schema. The description covers the empty-query case, ambiguity handling, and the address caveat — enough for correct invocation; the odd readOnlyHint=false remains unexplained.

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 coverage is 100% and the single parameter's description already states 'Province, town or district name; omit to list provinces.' The description repeats the omission-to-list behavior and adds that province searches use provinceUuid, but provides no matching-syntax or fuzzy-match detail beyond the schema.

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?

Specific verb (Resolve) plus resource (Costa Rican province/town/district → catalog IDs and locality centers), and it distinguishes the output shape (IDs, centers). It doesn't explicitly contrast with siblings like wellfred_browse_catalog, but the geographic-resolver purpose is distinctive enough to stand 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?

Gives a clear usage pattern: empty query lists the seven active provinces, province searches use provinceUuid, and ambiguous names should be clarified with the caller. It lacks explicit 'when not to use / use sibling X instead' routing, so not a 5.

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