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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, but the description adds substantial behavioral context: deterministic scope, 2026-2027 coverage, weekend baseline, exclusion of provincial patron days, school/bank/employer schedules, the exact working-day formula, and a REST fallback. It also discloses what the tool does not infer, which is valuable for avoiding overreach. There is 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?

The description is front-loaded with usage guidance and covers relevant behavior, but it is long and includes redundant material: it repeats JSON examples already present in the schema and lists output fields even though an output schema exists. The phrasing contains awkward repetitions such as 'Austria Austria' and 'Do not use this when nationwide statutory holiday list only.' It is informative but not tightly structured.

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 deterministic date-checking tool with one required parameter, an output schema, and supporting annotations, the description is highly complete. It specifies inputs, calculation basis, coverage period, limitations, formula, output fields, REST fallback, and documentation link. An agent has everything needed to invoke it correctly without consulting external context.

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%, and the single parameter 'date' is already documented as a Gregorian date in Austria coverage with examples. The description repeats the input name, type, and JSON examples but adds no new semantic detail such as date formatting rules or out-of-range behavior. With the schema doing the heavy lifting, the baseline of 3 is appropriate.

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 verb and resource: it checks a date against the Austrian working-day calendar, using weekend baseline and exact 2026-2027 authority events. It also distinguishes the scope from broader nationwide statutory holiday lists and notes that Werktag is not uniform across legal domains, which helps separate it from sibling working-day tools. The duplicated phrase 'Austria Austria' and somewhat awkward first sentence slightly reduce precision, but the core purpose remains clear.

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 usage guidance: 'Use this when you need...' and 'Do not use this when nationwide statutory holiday list only,' plus example user requests. It instructs the agent to call the tool directly rather than compute the formula from memory. It does not name a specific alternative sibling tool, but the conditions for use and non-use are clear enough to route correctly.

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