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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: single-country input, two years of data (latest plus prior for trend), and the meaning of both numeric scales (-2.5 to +2.5 estimate, 0-100 percentile where higher = stronger relative to peers). It doesn't discuss data-vintage/staleness or granularity (the WGI is annual and sometimes biennial), which is the main remaining 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?

One dense paragraph, front-loaded with source and subject, then usage triggers, then input/output mechanics – a sensible order. A few trigger phrases are near-redundant with the enumerated dimension names, so it's slightly longer than strictly necessary, but nothing is wasted outright.

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 and a single simple parameter, the description carries the return-value burden itself and does so: it specifies years returned, all six dimensions, and how to read both score scales. An agent can call this tool and interpret its output correctly without additional documentation.

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% for the single country_code parameter, so the baseline is 3. The description adds only the constraint 'pass one ISO country code' (i.e., no multi-country batching), while its inline examples mix two-letter ('US') and three-letter ('GBR') forms without resolving which the API expects – a gap shared with the schema, not filled by the description.

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 exact dataset (World Bank Worldwide Governance Indicators) and enumerates the six dimensions returned, so an agent knows precisely what resource this fetches. It clearly separates itself from generic siblings like get_indicator or get_country by naming the specific governance dataset and the six constituent measures.

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?

It gives concrete trigger phrasings ('how corrupt is <country>', 'rule of law in <country>') and a usage context ('country-risk context alongside news-event data'), which strongly signals when to reach for this tool. What's missing is any explicit exclusion or named alternative – it never says 'use compare_countries instead when comparing multiple countries', so routing against siblings is only implied.

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