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

Annotations already mark readOnly, idempotent, non-destructive, so the burden is reduced; the description adds what outputs are produced and how residence permits affect the count. It clarifies that only the permit-issuing country's days are excluded while all other Schengen days still count, which is non-obvious behavior. 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?

Information-dense and front-loaded with the main verb and resource. The returned-value list and permit caveats are necessary, though the phrase 'with a note of which country is excluded' is slightly redundant.

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 calculation tool with no output schema, the description is robust: it states inputs, outputs, status values, and edge cases for EU nationals and permit holders. It doesn't specify exact threshold boundaries for statuses or date validation behavior, but this is likely sufficient for selection and invocation.

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%, so baseline is 3. The description repeats some param concepts (nationality, residencePermit) but adds context like the permit exemption scope and the 90/180 rolling window, which supplements the schema. It does not explain locale/currency, but those are already defaulted in 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?

Description opens with 'Calculates Schengen 90/180 short-stay status from a list of stays,' naming a specific verb, resource, and scope. It enumerates concrete outputs (days used/remaining, status, projected date, permit-adjusted count), which clearly distinguishes it from sibling tools like check_tax or check_visa.

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 explicitly frames the intended audience: 'Use for non-EU travellers tracking the 90-days-in-180 limit.' It also gives important exclusions—'EU/EEA nationals have free movement (not counted)' and residence permit nuance—but doesn't name alternative sibling tools when those conditions don't apply.

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