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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile, so the bar is lower. The description adds genuine context beyond that: the exact output format, the UK exception example, and the cross-tool contract that the returned 'code' feeds into other tools' country_code parameter. It doesn't disclose minor details like sort order or list exhaustiveness, but for a 0-param reference list these are low-stakes.

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 no waste: the first front-loads the core purpose and key format detail with an example; the second delivers usage exclusions with rationale. Every clause earns its place.

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 0 params, a present output schema, and safety covered by annotations, the description covers everything an agent needs to call this tool correctly: what it returns, in what format, when to use it, and why it is not a required prerequisite for sibling lookups. Nothing material is missing for a simple read-only reference tool.

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?

The tool has 0 parameters, so the baseline is 4 per the rubric. The description adds adjacent value by explaining that the return value's 'code' field is precisely what must be passed as country_code to sibling tools, effectively documenting the parameter contract of the entire tool family.

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 the countries GotCashback covers' — and goes further by specifying the output format (lowercase ISO 3166-1 alpha-2) with a concrete example ('gb' for the United Kingdom). It differentiates from its 17 siblings by positioning itself as a reference lookup for country_code rather than a deals/cashback/stores tool.

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?

Explicitly states when to use it ('only to confirm whether a country is supported or which code to use') and when not to ('not needed before store, cashback or gift card lookups'), with the reason that those tools accept country_code directly and search all countries when omitted. This is a model of when/when-not guidance, with the alternative behavior clearly described.

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