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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context on top: quarterly update cadence, 200+ country coverage, 1,400+ indicators, the 5-year trend/direction output framing, source attribution, and $0.10 USDC pricing. The Brazil example additionally previews the output shape an agent can expect. No contradiction with annotations.

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?

The description is well structured and front-loaded: use cases first, then a crisp 'Returns' statement, followed by coverage, cadence, example, source, and pricing. It is slightly long — the Brazil example carries some interpretive commentary — but every sentence contributes information and the example usefully demonstrates output shape.

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 two-parameter read-only tool with no output schema, this covers the full spectrum: when to use it, what it returns, data breadth and freshness, a concrete example output, source, and cost. The exact return format and indicator units are left implicit, but the example mitigates that gap.

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 only 50% — the indicator enum has no per-value description. The description partially compensates by enumerating six indicator families and illustrating actual values via the Brazil example, but it never mentions trade_pct_gdp or gini_coefficient and does not define units or exact value semantics for any indicator.

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 verb and resource: 'Returns World Bank development indicators — GDP, inflation, unemployment, ease of doing business, government debt, FDI inflows — with 5-year trend and direction.' Naming the World Bank as the source and listing the indicator families distinguishes it from macro siblings like get_imf_weo_macro_snapshot, and the explicit scoping leaves no ambiguity about what the tool does.

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?

Opens with an explicit 'Use when...' enumeration covering four concrete scenarios — country risk assessment, foreign market evaluation, capital allocation benchmarking, and ESG country scoring — which tells an agent precisely when to select this tool. It falls just short of a 5 because it never names alternative tools or states when not to use it.

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