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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read only.' is redundant. What earns credit beyond the structured fields is the consent-handling obligation ('Show the consent text to the person before gpfr_register') — a behavioral/workflow requirement the annotations do not convey. It still does not say what happens for unsupported languages beyond what the schema states, so it falls short of a 5.

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 core content is front-loaded, but the main sentence is a comma-spliced fragment ('...is, in the caller's language, with the register page, the consent text and its version and, with a country, our fund pages'), which is awkward to parse. The short second sentence about consent is tight and well-placed.

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 does list the payload contents (register page, consent text, version, fund pages). Combined with the sequencing instruction and a 100%-covered schema, an agent has enough to invoke it correctly; only edge behavior (invalid country, fallback language output) is left unstated.

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%, so the baseline is 3; the description adds functional meaning by tying each parameter to an output effect — 'in the caller's language' (language drives response localization) and 'with a country, our fund pages' (country unlocks country-specific fund pages). That is real added value over the schema's format-only descriptions.

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?

States a specific resource (GPFR: the Global Pension Finding Register) and enumerates exactly what the caller gets back: what it is, the register page, the consent text with version, and country fund pages. It is distinguishable from siblings like gpfr_register and gpfr_status. The phrasing is a run-on fragment ('What GPFR ... is, in the caller's language, with the register page, the consent text...'), which makes the scope slightly harder to parse than it needs to be.

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 an explicit sequencing rule: 'Show the consent text to the person before gpfr_register.' That directly routes the agent to call this before the registration sibling. It lacks an explicit when-not or a mention of the other informational siblings (country_pension_facts, list_covered_countries), but the primary workflow condition is stated clearly.

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