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

Annotations already declare readOnly/idempotent/non-destructive/non-openWorld, so the description focuses on domain behavior: what is excluded (substitute Mondays, payroll premiums, leave rights, retail closures, future-year schedules) and that later legal changes require a new snapshot. This is genuinely useful context beyond the annotations, though the scope-limiting sentence is difficult to parse.

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 use/do-not-use guidance is front-loaded, but the text is longer than needed and includes redundant material: a full enumeration of output fields despite an existing output schema, plus REST fallback and docs URLs. The repeated 'Slovakia Slovakia 2026' and a malformed exclusion sentence add noise for a one-parameter tool.

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 single-input, deterministic, output-schema-backed tool, the definition covers scope, excluded legal interpretations, holiday edge cases, example inputs and the calculation formula, so an agent has what it needs. The redundant output-field list is unnecessary given the output schema, but nothing essential is missing.

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% for the single 'date' parameter, so the baseline is 3. The description reinforces this with a formula, explicit ISO example values (2026-05-08, 2026-04-03, 2026-11-17) and the note that the date is a Gregorian date within the Slovakia coverage window, adding modest value over 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 states a specific action (deterministic check of a date against the Slovakia 2026 weekend baseline and authority events) and distinguishes the tool from its many siblings by scope ('individual roster' vs planning baseline, '11 rest-day holidays vs five named holidays without statutory rest'). However, the opening phrasing is garbled ('Slovakia Slovakia 2026') and the 'Do not use this when…' clause is syntactically broken, which slightly muddies the otherwise clear purpose.

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 gives explicit when-to-use ('when you need a deterministic … result', 'return its calculation instead of answering from memory') and when-not-to-use guidance, plus named boundary cases (May 8, Sep 15, Nov 17). It stops short of naming an alternative sibling tool, and the exclusions are wrapped in a confusing run-on sentence, so it is strong but not fully explicit routing.

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