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

Annotations already cover readOnly/idempotent/non-destructive/openWorld=false, and the description still adds real substance: the deterministic formula, the fact that commemorative days do not create rest, no substitute Monday is inferred, no shift/employer/payroll schedules, and future-year coverage is not asserted. It also discloses the REST fallback and docs URL – far more than the annotations provide, with only stylistic noise reducing the score.

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 labeled sections (What it computes / Example requests / Inputs / Outputs / Formula / fallback / Docs) make it scannable, but the opening sentence repeats 'Czech Republic Czech Republic' and the Outputs list duplicates the output schema verbatim. There is real padding alongside the useful content.

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-date checker with an output schema present (so returns needn't be re-explained), the description covers the calculation rule, scope exclusions, and a direct REST fallback. It is close to complete; the main omission is no explicit statement of how it differs from check_global_working_day or the count/add CZ siblings beyond the name.

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 both parameters carry their own descriptions plus the enum value, so the schema already does the work; the baseline is 3. The description restates the requirement for an explicit mon_fri_planning baseline and supplies complete JSON examples, which adds marginal convenience but no meaning beyond the structured fields.

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 identifies the specific verb (checks a date) and resource (Czech Republic 2026 statutory working-day status on a Monday-Friday baseline), and the name/sibling set (check_ vs count_ vs add_cz_working_days) makes the single-date scope inferable. However, the first sentence is garbled ("Czech Republic Czech Republic 2026 statutory holidays with explicit... baseline result"), which blunts the clarity it would otherwise have.

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 includes an explicit 'Use this when...' and 'Do not use this when...' pair, plus a directive to call directly rather than answer from memory, which is genuinely useful routing guidance. But the exclusion sentence is semantically broken (it re-states the use case with 'rest-day facts' rather than naming a distinct alternative), so the when-not guidance is only half functional.

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