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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful scope caveat that this is a quizzing aid and returns no centre recommendation, which pre-empts a misuse. It says nothing about what a suitability result looks like or how conflicting inputs (e.g. deep_specialty) are weighed.

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 very short sentences with no filler; the scope limit ('does not recommend a centre') is placed second where it reads as a guardrail. Slightly clipped to the point that the first sentence lacks an explicit verb, which costs a point.

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 is the only place to learn what 'suitability' returns, and it does not say. For a five-parameter read-only computation tool with zero schema descriptions and no output contract, an explanation of the result shape would materially help, though the core inputs and purpose are covered.

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 0%, so the description carries the full burden. It does convey the key semantic that all slugs share one cert and dive count, which is genuinely additive. But it leaves deep_specialty and last_dive_months completely unaddressed, and the array size limit and enum values are left to the schema.

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 resource ('Andaman slugs') and the operation ('suitability'), and the word 'multiple' plus the 'batch_' prefix implicitly distinguish it from the single-slug sibling check_suitability. It stops short of a clean verb+resource statement (it opens with a noun phrase 'Suitability for...'), so the sibling contrast is inferred rather than stated.

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?

'Quiz helper' gives a usage context you would not otherwise infer, and 'does not recommend a centre' sets a clear negative boundary against list_centres and similar tools. It never explicitly routes to check_suitability for a single slug, so the caller has to infer the batch-vs-single split from the name alone.

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