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

Annotations already establish read-only, idempotent, non-destructive and open-world, and the description adds genuinely new facts: offer cases are excluded, the case url is included, the case is public/anonymised, and it warns that an individual case does not predict another applicant's outcome. The closing sentence about 'this public endpoint returns English natural-language text... pagination' is muddled for a single-record fetch and sits awkwardly against the locale parameter, which weakens an otherwise informative disclosure.

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 first sentence is long but well front-loaded, putting the verb, resource and identifier source first. The trailing sentence about 'English natural-language text, preserving sources, conditions and pagination' reads as boilerplate that adds little for a single-case lookup and actively introduces ambiguity about locale and pagination.

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?

There is no output schema, so the description carries the return-value burden and does so by naming the fields an agent will get (highlights, duration, advisor, canonical link, case url) and by stating the offer-case exclusion. The locale/English-language ambiguity is the one real gap for a tool whose only optional parameter changes language and URL prefix.

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%, with both id (public id, not internal caseId) and locale (zh-CN default, en-US, zh-TW, also selects URL language prefix) fully documented in the schema. The description reinforces the public-id requirement but never addresses locale, and the claim that the endpoint 'returns English natural-language text' is in tension with a default of zh-CN, leaving the agent to trust the schema over the prose.

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 ('Get') plus a precisely scoped resource: the full published, anonymised background of one successful 500/600/485/820 visa case, keyed by public id. It enumerates what the payload contains (highlights, processing duration, advisor, canonical link) and explicitly points at sibling search_visa_cases as the id source, so it is instantly separable from that 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?

It tells the agent the precondition (id must be the public id obtained from search_visa_cases, not the internal caseId) and a scope exclusion (offer cases are excluded). It stops short of an explicit 'when not to use' or a statement of behaviour when the id is unknown/invalid, so it is clear context rather than full routing guidance.

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