Calcgrid

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description goes further by disclosing the exact formula (one day at a time, decrement only on is_working_day=true), coverage limits, and a direct REST fallback endpoint, which is genuinely useful operational context beyond the 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?

Front-loaded with the key when-to-use guidance, but padded with redundant sections ('Example user requests', 'Inputs', 'Complete JSON argument examples') that duplicate what the schema already supplies. The 'Example user requests' line is awkward filler that does not earn its place.

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?

With an output schema present, the description needn't detail returns, yet it lists output fields (harmless redundancy). It fully covers the tool's scope, formula, and coverage caveats, giving the agent enough to invoke correctly; only minor bloat keeps it from a 5.

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% and the schema itself documents both parameters (including 'start date excluded for non-zero offsets'). The description merely restates the input names and one JSON example, adding no meaning beyond the structured fields, so the baseline 3 applies.

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?

States a specific verb+resource (Argentina working-day offset) and explicitly scopes it as the 'nationwide default' authority-scope calendar. An agent can distinguish it from add_br_working_days or add_at_working_days purely by the country/scope qualifier.

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?

Explicitly directs the agent to call the tool and return its result instead of computing from memory, and adds a clear when-not clause (provincial/municipal/employer/bank/sector schedules and regional one-off holidays are out of scope). Both the affirmative and negative conditions are present.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real behavioral context beyond that: the day-by-day formula, that Saturday/provincial/sector schedules are NOT inferred, a REST fallback endpoint, and a docs link.

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?

Front-loads the core purpose, but the body is bloated with boilerplate ("Example user requests", a formula restatement, output field inventory, REST fallback and docs URL) alongside an awkward partially-parsed when-not clause. Useful content is there but it is not tightly edited.

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?

Covers inputs, an example call, the computation rule, the excluded schedule types, and fallback endpoint; with an output schema present, return values need not be enumerated, so it is largely complete. The ambiguous Werktag/when-not wording leaves a small gap in deciding against alternatives.

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 both parameters are already documented in the schema (Gregorian date range, signed offset with start-date exclusion). The description only restates the input names plus one JSON example, adding little beyond 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?

States a specific verb (add/subtract) and resource (Austria working-day offset) with exact scope, and the Austria identity distinguishes it from the ~60 sibling country tools. An agent can identify the right tool without comparing schemas.

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?

Explicitly tells the agent when to call it (deterministic Austria offset, use directly rather than answering from memory) and gives a when-not condition (nationwide statutory holiday list only). However it never names the sibling alternatives (check_at_working_day, count_at_working_days, add_global_working_days), and the when-not sentence is grammatically garbled.

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

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, but the description adds real behavioral context: the 2026-2027 scope limit, state-level (non-local/employer) calendar semantics, the counting formula, and a REST fallback with a warning not to guess other /api/* paths. That goes meaningfully beyond the structured 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?

Front-loaded well, with when-to-use and when-not-to-use leading, but it then enumerates the full output field list (start_date, result_date, ..., dataset_version) which duplicates the existing output schema and bloats the definition. The many labeled sections make it scannable but not tight.

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?

Given an output schema exists, the description need not explain return values, and it still supplies scope limits, formula, example arguments, fallback endpoint, and docs link. Nothing an agent needs to call this correctly 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 description coverage is 100%, so the schema already documents start_date, division enum, and the signed working_days offset. The description restates the inputs and repeats a JSON example without adding syntax or constraint detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource: 'Adds or subtracts working days using the selected Australian state/territory public-holiday calendar,' which separates it from the check_/count_australia_* siblings by the additive behavior. It does not explicitly name those siblings, so differentiation is implied 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?

Gives an explicit when-to-use ('a state/territory-specific Australian date offset in 2026-2027'), an explicit when-not-to-use ('division unknown or the task needs local, employer, exchange or future-year rules'), and instructs the agent to return the calculation rather than compute from memory. It stops short of naming the alternative sibling tools for the excluded cases.

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

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds real behavioral context beyond them: the exact computation rule ('move one day at a time; decrement only on status.is_working_day=true'), coverage limits, the Feb 10 exclusion rationale, and a caveat that lunar dates may be revised by later official notice.

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?

Usage guidance is correctly front-loaded, but the block is padded with a full 'Outputs' enumeration that duplicates the existing output schema and an 'Inputs' line that duplicates the schema, so not every sentence earns its place.

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 tool with an output schema and full annotations, the description covers everything else an agent needs: when to use and when not, the computation rule, argument example, and a direct REST fallback path with a warning not to guess other /api/* routes.

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 descriptions plus examples, so the baseline is 3. The description's 'Inputs' line and JSON example merely restate the schema, adding no meaning such as offset sign conventions beyond what the schema already says ('signed offset; start date excluded for non-zero offsets').

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?

States a specific verb pair (adds or subtracts) and a scoped resource (Bangladesh authority-scope working days), and the country qualifier is exactly what separates it from the ~60 add_*_working_days siblings. An agent can pick it out of the family without opening the schema.

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?

Explicit 'use this when' plus a detailed 'do not use this when' that names the excluded schedule scopes (private-employer, bank, school, industrial-zone, essential-service, regional) and a specific date exclusion. It does not, however, route to the nearest siblings (count_bd_working_days, check_bd_working_day) for count/check needs, so the alternative-selection guidance is incomplete.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the exact computation rule ('move one day at a time; decrement only on status.is_working_day=true'), the precise coverage boundary (substitute dates, regional/sector/employer/school/bank schedules excluded), and a direct REST fallback endpoint with a warning not to guess other paths.

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?

Front-loaded with the usage directive, which is good, but the block is long and choppy: it enumerates an Outputs field list that duplicates the output schema, and repeats input names already in the schema. Several fragments (example user requests, formula, fallback, docs) pad the body without adding selection value.

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 two-parameter calculation tool this covers everything an agent needs: when to use, when not to, inputs, computation rule, edge-case scope, and a REST fallback. With an output schema present, the description needn't explain return values further.

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 both parameters are already documented in the schema, including the 'start date excluded for non-zero offsets' caveat. The description restates the inputs and adds a JSON example, which is helpful but redundant with schema examples, so the baseline 3 applies.

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?

States a specific verb and resource with scope: 'Adds or subtracts Belgium authority-scope working days in exact coverage.' An agent can distinguish this from check_be_working_day and count_be_working_days without opening a schema, and the region-of-scope qualifier is explicit.

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 an explicit trigger ('Use this when you need a deterministic Belgium working-day offset') and a genuine exclusion ('Do not use this when private-sector statutory core only... not inferred'), plus instructs to call directly rather than answer from memory. It never names the sibling alternatives (check_be_working_day, count_be_working_days) that an agent should pick when it wants a boolean check or a range count, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral scope: education-only November 1 does not create general rest, one-off January 2 rest, no payroll/legal-deadline computation, and a REST fallback endpoint. It does not contradict the annotations, though the formula line is terse relative to the long output list.

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 entry is bloated: it restates inputs, repeats a full JSON example that already exists in the schema, enumerates 20+ output fields even though an output schema exists, and appends REST fallback and docs URLs. The 'Do not use this when bulgaria 2026 nationwide statutory holidays, observed non-attendance days and January 2 one-off rest over an explicitly selected Monday-Friday planning baseline' sentence is garbled and unparseable, wasting prime negative-scoping space.

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 calculation tool with an output schema and full annotation coverage, the description supplies the needed scope boundaries, holiday-policy caveats, fallback endpoint, and documentation link. The broken exclusion sentence and the redundant output enumeration are flaws, but nothing critical to correct invocation 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%, so the baseline is 3; the description nevertheless adds meaning by stating that mon_fri_planning is required because it is a planning baseline rather than a universal legal roster, and by giving the planning_workday formula that defines what working_days actually counts. It also supplies a complete JSON argument example, though that largely duplicates the schema examples.

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: 'Adds or subtracts Bulgaria authority-scope working days in exact coverage,' and the opening line names the general behavior (deterministic Bulgaria working-day offset). It is distinguishable from sibling country variants like add_ar_working_days and from check_bg_working_day/count_bg_working_days by the add/subtract framing, though it never names those siblings explicitly.

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?

'Use this when you need a deterministic Bulgaria working-day offset. Call this tool directly and return its calculation instead of answering the formula from memory' is a clear usage directive with a stated anti-pattern (relying on memory). Scope exclusions are given (no personal, shift, school, employer, bank/exchange, religious-leave, payroll, or legal-deadline schedules; future years unsupported), but no alternative sibling tool is named and the 'Do not use this when...' sentence is grammatically broken.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them by disclosing the exact algorithm ('move one day at a time; decrement only on status.is_working_day=true'), the calendar scope limitation, a deterministic REST fallback endpoint, and the docs URL. Nothing about behavior is left implicit.

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?

Front-loads the routing guidance well, but then enumerates all 17 output fields even though an output schema exists, and adds formula/fallback/docs sections. The Outputs list in particular is redundant bloat that duplicates structured data.

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?

Given a 2-parameter tool with full schema coverage, an output schema, and rich annotations, the description supplies the remaining pieces an agent needs: the authoritative scope boundary, the deterministic-computation mandate, fallback endpoint, and documentation link.

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 both parameters (start_date, working_days) are already fully documented in the schema including the signed-offset semantics. The description's 'Inputs:' line and JSON example merely restate what the schema already provides, adding no new parameter meaning.

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?

States a specific verb+resource+scope: 'Adds or subtracts Brazil authority-scope working days in exact coverage.' An agent can distinguish this from the dozens of sibling add_*_working_days tools for other jurisdictions without opening the schema.

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?

Explicit when-to-use ('call this tool directly and return its calculation instead of answering from memory or stopping at discovery') and when-not ('Do not use this when this is not a universal Brazilian private-employer calendar; state, municipal, sector, employer and private payroll schedules are not inferred'). This is a genuinely calibrated routing statement.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: the exact formula, the limitation that schedule-dependent substitute days remain unresolved, the enumerated output fields, and a REST fallback path plus docs URL. This is unusually rich disclosure for a read-only calculator.

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?

Front-loads the when-to-use condition, then segments inputs, outputs, formula, and fallback with clear labels. Slightly long because it restates outputs already covered by the output schema, but every block is scannable and purposeful.

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 2-param read-only calculator with annotations and an output schema, the description covers scope, exclusions, formula, and fallback endpoint completely. Nothing an agent needs to invoke it correctly is missing, and the redundant output listing is harmless rather than a gap.

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 two parameters (start_date, working_days) are already fully documented including the signed-offset and start-date-exclusion semantics, so the description's 'Inputs' line largely repeats structured data. The complete JSON argument example adds marginal value, but the baseline 3 applies when the schema carries the meaning.

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?

States a specific verb (adds/subtracts) and resource (Canada federal working days) and immediately distinguishes scope: 'federally regulated-employer calendar' versus provincial/private-employer/schedule-specific. An agent can separate it from add_us_federal_working_days or the provincial siblings without opening schemas.

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?

Explicitly gives when-to-use ('deterministic baseline offset for a federally regulated-employer calendar, 2026-2027') and when-not-to-use ('provincial, private-employer or schedule-specific substitution result'), plus the instruction to call it directly rather than answering from memory. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds significant behavioral context beyond that: the step-by-step calendar-day iteration, the rule for decrementing only on working days, special handling of State Council-designated weekend makeup workdays, and the 2024-2026 coverage limit. 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 long but well-structured and front-loaded with the use case and exclusions before technical details. However, the Inputs and Outputs sections largely repeat what is already in the input schema and output schema, adding mild redundancy. Still, each major section serves a purpose.

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?

Despite having an output schema and rich annotations, the description still supplies the algorithm, coverage bounds, and a direct REST fallback URL with a warning not to guess other paths. Everything an agent needs to invoke and return the result correctly is present.

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 schema already documents both parameters with format, units, minimum/maximum, and examples. The description only restates the inputs and complete JSON examples, adding little semantic meaning beyond the schema. Baseline 3 applies.

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 uses a specific verb and resource: 'Adds or subtracts official mainland China working days,' and immediately distinguishes the tool with explicit exclusions (calendar days, sector-specific settlement calendars, outside 2024-2026). It also differentiates from sibling add_uk_working_days by making the 'China' scope explicit in both title and description.

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?

The description gives explicit 'Use this when...' and 'Do not use this when...' conditions, including a clear exclusion for calendar days and out-of-range dates that map to potential alternatives. It also instructs the agent to call the tool directly and return its calculation rather than answering from memory, which is strong routing guidance.

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

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

Annotations already cover readOnly, idempotent and non-destructive traits, yet the description adds real value: the deterministic guarantee, the explicit scope limits (cantonal/municipal holidays not inferred), the stepwise algorithm, and a REST fallback with the exact path. This is well beyond what the annotations convey.

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?

It is front-loaded with a use/when-not/computation structure, which helps, but it is bloated and contains broken text: 'Cantonal holiday is not inferred' appears verbatim inside the example user requests, and the outputs list is long and redundant. Several sentences do not earn their place.

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 well-annotated, fully documented two-parameter calculation tool with an output schema, this is essentially complete: purpose, scope limits, inputs, algorithm, REST fallback and docs are all present. The redundant output enumeration and garbled exclusion sentence are minor blemishes, not gaps.

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 the baseline is 3. The description only restates the two inputs (start_date, working_days) plus a JSON example; the schema itself carries the finer meaning (date range 2026-2027, signed offset, -1000..1000 bounds, start date excluded for non-zero offsets). No additional parameter semantics are added.

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 a specific verb and resource ('Adds or subtracts Switzerland authority-scope working days in exact coverage') and scopes it to the authority/federal layer. It is clearly distinct from the many sibling country tools, though it never explicitly contrasts with its own siblings like count_ch_working_days or check_ch_working_day.

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 an explicit trigger ('when you need a deterministic Switzerland working-day offset') and instructs the agent to call it directly rather than answering from memory or stopping at discovery. It also states an exclusion (cantonal/municipal/employer/collective-agreement schedules are not inferred), though the phrase 'Do not use this when federal layer only' is garbled and hard to act on.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered. The description adds real behavioral context beyond that: the exact coverage layer, the provenance-preservation caveat for commerce mandatory-rest exceptions, the non-generalization warning, the refresh requirement for future dates, and the day-by-day algorithm. This is more than the schema and annotations convey.

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?

Content is front-loaded (when-to-use, when-not, what it computes, examples) and labeled so an agent can scan it. It is verbose and carries some templated boilerplate ('Call this tool directly and return its calculation instead of...') plus an awkwardly phrased when-not sentence, but every section is functional rather than padded.

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 2-param deterministic calculator with an output schema present, the description covers scope limits, the formula, and an API fallback path more than adequately. The return fields are enumerated despite the output schema existing. The slightly confusing when-not wording is the only gap for an otherwise self-sufficient definition.

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% – both parameters are documented in the schema, including the signed-offset and excluded-start-date semantics. The description restates the two inputs and supplies a complete JSON example, but adds no syntax or edge-case meaning the schema lacks. Baseline 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?

States a specific verb (adds/subtracts) and resource (Chile authority-scope working days) and explicitly frames the computation model. Against ~60 country-specific siblings sharing the add_*_working_days prefix, the 'Chile' scoping and 'nationwide statutory/public-holiday layer over a Saturday-Sunday baseline' phrasing lets an agent pick it apart from add_ar_working_days, add_ch_working_days, etc.

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?

Gives an explicit trigger ('Use this when you need a deterministic Chile working-day offset. Call this tool directly... instead of answering from memory or stopping at discovery') and a scoping exclusion (regional/local, school, bank, private-employer, sector schedules are not inferred). It does not, however, route to the natural alternatives check_cl_working_day or count_cl_working_days, so sibling selection among the non-add Chile tools is left to inference.

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

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

Annotations already declare this is a safe, idempotent, closed-world read (readOnlyHint/idempotentHint/openWorldHint=false). The description adds real value beyond them: the exact coverage layer (nationwide statutory paid-rest holidays over a Sat-Sun baseline), the exclusion of municipal/local schedules, and the staleness caveat that future annual calendars need refreshed official evidence. It also documents the traversal formula, well beyond what annotations provide.

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 content is front-loaded with purpose and usage, which helps, but the block is bloated with redundant sections (inputs restated, full output field list despite an output schema, REST fallback, docs URL) and one garbled sentence. Every sentence does not clearly earn its place.

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 two-parameter deterministic calculator with an output schema, the definition covers usage, scope limits, formula, and error-avoidance (REST fallback). Nothing essential to calling it correctly is missing, though it redundantly enumerates return fields that the output schema already supplies.

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 the schema already documents both parameters, and the description largely restates the same input names plus a JSON example. The formula line adds minor semantic context on how working_days is applied, but parameter-level meaning beyond the schema is thin. Baseline 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 names a specific verb+resource pair ('Adds or subtracts Colombia authority-scope working days in exact coverage') and the 'What it computes' line reinforces scope. It clearly distinguishes this offset tool from the sibling check_co_working_day and count_co_working_days by framing the operation as an addition/subtraction of a signed offset.

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 strong positive guidance ('Use this when you need a deterministic Colombia working-day offset', 'Call this tool directly') and a do-not-use clause covering uncovered municipal/departmental/school/bank/sector schedules. The exclusion sentence is garbled ('Do not use this when this package covers...') and it never names a concrete alternative sibling, so it falls short of a clean 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: commemorative days do not create rest, no substitute Monday is inferred, future-year coverage is not asserted, and the exact formula and REST fallback path are disclosed. This is well past the reduced annotation bar.

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?

It front-loads the core purpose well, but the body is bloated and repetitive, with garbled fragments like 'around Two names on January 1, one rest date' and 'in 2026-2026.' Several sentences restate the same coverage exclusions, diluting the signal.

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?

An output schema exists and annotations cover the safety profile, so the description needn't explain returns, yet it still lists them. It thoroughly covers the policy scope and constraints an agent needs, though the garbled example phrasing leaves minor ambiguity about the intended use cases.

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%, so the baseline is 3, but the description adds real meaning: it supplies a complete JSON argument example, the planning_workday formula, and clarifies that work_schedule is an 'explicit Monday-Friday planning baseline, not a statutory universal roster.' That goes beyond what the schema fields state on their own.

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+resource: 'Adds or subtracts Czech Republic authority-scope working days in exact coverage.' It is clearly the add variant within the add_/check_/count_ family, so an agent can distinguish it from sibling tools. It stops short of naming the alternative tools explicitly, so it lands at 4 rather than 5.

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 genuine usage direction: 'Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery,' and it enumerates what it does NOT cover (shift, employer, bank/exchange, school, retail, payroll, legal-deadline schedules). The 'Do not use this when...' sentence is grammatically broken and hard to parse, which weakens an otherwise strong routing statement.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact coverage boundary (authority-scope only, no state/municipal/school/bank/TARGET/transport/collective-agreement/employer schedules) and the deterministic day-by-day algorithm. The outputs list, REST fallback URL and docs link are operational rather than behavioral.

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?

Front-loaded with the trigger condition, then organized into labeled sections (coverage exclusion, computation, examples, inputs, outputs, formula, fallback, docs), which scans well. It is longer than necessary, though: the output field list, REST endpoint, and docs URL are largely redundant for an agent that already has an output schema.

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 2-parameter deterministic calculator with an output schema, the description covers the coverage boundary, the computation rule, and an invocation example — nothing essential is missing. Minor deduction for the awkwardly phrased exclusion clause ('...are not inferred') and for enumerating outputs that the output schema already defines.

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 properties carry their own descriptions (date range, signed offset semantics, start-date exclusion). The description's 'Inputs:' line and JSON example merely restate what the schema already provides, so it adds no meaning beyond it — baseline 3 is correct.

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?

States a specific verb+resource ('Adds or subtracts Germany authority-scope working days') and pins the scope to national/authority level. In a sibling set dominated by per-country add_* tools, the Germany qualifier plus the explicit coverage scope makes it unambiguously distinguishable from add_ar_working_days, add_at_working_days, etc.

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?

Gives explicit when-to-use ('when you need a deterministic Germany working-day offset', call directly rather than answering from memory) and a when-not clause excluding state/municipal/school/bank/TARGET/employer schedules. It stops short of naming the adjacent siblings (count_de_working_days, check_de_working_day) that an agent might otherwise pick, so it is strong but not complete routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's real added value is the coverage boundary: only authority-scope statutory days are modeled, half-day and employer-specific closures are not inferred, and Store Bededag stops being a holiday in 2024. It also exposes the computation rule ('decrement only on is_working_day=true'). This is meaningful behavioral context beyond the structured fields.

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?

Front-loaded with the use case, but bloated: it lists sixteen output fields that the output schema already defines, plus a raw REST URL and docs link, and contains some awkward phrasing ('in exact coverage', the Constitution Day example). Roughly a third of the text duplicates structured data that the agent already receives.

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 2-parameter calculator with an output schema and full annotations, the description covers the critical gaps: calendar scope, holiday policy boundary, the 2024 Store Bededag rule, an example invocation, and a REST fallback. Only the redundant output-field enumeration and the slightly malformed exclusion sentence keep it short of 5.

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 are documented there (date range, signed offset semantics, min/max). The description only restates the parameter names and gives one JSON example, adding little beyond the formula hint about one-day-at-a-time movement. Baseline 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 ('Adds or subtracts Denmark authority-scope working days') and explicitly frames the tool as a deterministic offset calculator. It implicitly distinguishes itself from check_dk_working_day and count_dk_working_days via the add/subtract framing, though it never names those siblings. An agent can identify the operation without opening the schema.

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?

Explicit 'Use this when you need a deterministic Denmark working-day offset' plus a 'Do not use this when...' exclusion listing what is out of scope (collective-agreement, employer, sector, school, bank, local, customary half-days) and the Store Bededag 2024 change. It also tells the agent to call directly rather than answer from memory, and supplies a REST fallback. The when-not sentence is slightly garbled ('nationwide statutory list only'), which keeps it from a 5.

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

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

With readOnlyHint/idempotent/destructiveHint already covering safety, the description adds substantial context: the exact coverage formula, that national-importance dates and three-hour shortening never add full-day rest, and an explicit negative scope (no personal roster, payroll, opening hours, or future years). That is real behavioral disclosure beyond the 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?

Roughly 250 words for a simple offset computation, with heavy repetition ('Add or subtract Estonia working days around…' three times) and a garbled 'Do not use this when' clause. Useful content exists but it is not front-loaded or 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?

An output schema exists, so return-value explanation is unnecessary, yet the definition still lists outputs, provides a REST fallback path, a docs URL, and a worked JSON example. Coverage of what an agent needs to invoke it correctly is strong; a minor deduction for the confusing negative-guidance sentence.

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 the schema already documents start_date, working_days, and work_schedule. The description restates the three inputs and adds a valid JSON example, but supplies no semantics the schema lacks. Baseline 3 applies.

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+resource: 'Adds or subtracts Estonia authority-scope working days in exact coverage.' The 'Estonia' qualifier distinguishes it from the many country-named siblings. It is clear, though the framing is buried under dense policy prose rather than stated crisply up front.

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 a use trigger ('Use this when you need a deterministic Estonia working-day offset') and a routing instruction ('call this tool directly… instead of answering from memory'). However, the 'Do not use this when…' sentence is garbled and names no real alternative sibling such as check_ee_working_day or count_ee_working_days.

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

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

Beyond the annotations, the description discloses the algorithmic behavior ('move one day at a time; decrement only on status.is_working_day=true'), the weekend baseline (Friday-Saturday), exclusions (remote-work/operating-hour decisions), data freshness constraints for Islamic dates, and the exact REST fallback endpoint. This is rich behavioral context that annotations alone do not provide.

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 structured with clear sections and front-loads usage guidance, but it is long and includes an unnecessary enumeration of all output fields despite the presence of an output schema. Several lines repeat schema information, reducing conciseness without adding proportional value.

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?

Given a 2-parameter tool with annotations and a full output schema, the description is thorough: it covers scope, exclusions, computation logic, examples, fallback access, and documentation links. An agent has everything needed to select and invoke it correctly.

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%, so both parameters are already documented in the input schema. The description lists the same inputs and repeats a JSON example already present in the schema, adding only minor clarification ('signed offset; start date excluded for non-zero offsets') that is already captured by the schema description.

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: adding or subtracting Egypt authority-scope working days. It distinguishes this from siblings by naming the Egyptian government/public-sector holiday scope and the Egypt-specific calculation, so an agent can separate it from check_eg_working_day or count_eg_working_days.

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 clear when-to-use guidance ('when you need a deterministic Egypt working-day offset') and calls out when not to use it (private employers, banks, schools, diplomatic missions, sector calendars). It does not explicitly name the alternative sibling for single-date checks or counts, so it falls short of a full 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real behavioral context beyond them: the exact iteration formula, the deterministic/no-memory-fallback directive, the output field set, and a concrete REST fallback path with a warning not to guess other endpoints. It stops short of 5 only because it does not explain error/edge behavior (e.g., what happens beyond the ±1000 bound).

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?

Well front-loaded: purpose, when-to-use, when-not, then a consistent Inputs/Outputs/Formula/REST structure. However the 'Example user requests' lines are noisy ('around Ordinary weekday') and some output/fallback content is padding, keeping it from a 5.

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?

With an output schema present, annotations covering safety, and 100% schema coverage, the description supplies everything else an agent needs: deterministic formula, direct-call directive, JSON example, REST fallback, and docs link. Complete for this tool's complexity.

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% and both parameter descriptions already carry meaning ('start date excluded for non-zero offsets'). The description restates the two inputs and gives a complete JSON example, which is mildly useful but largely redundant against the schema. Baseline 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?

States a specific verb and resource ('Adds or subtracts Spain authority-scope working days in exact coverage') and names the exact jurisdiction scope. Against the many sibling add_<country>_working_days tools, the Spain confinement is unambiguous, so an agent can route correctly.

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?

Explicitly says when to use it ('when you need a deterministic Spain working-day offset') and to call it rather than answer from memory, plus a 'do not use' clause routing cases needing local/municipal calendars elsewhere. The exclusion is worded confusingly (it never names the alternative tool to call instead), so it falls short of a clean 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the coverage scope ('authority-scope', exact coverage), the caveats about which closures are NOT inferred, and the step-by-step formula (move one day at a time, decrement only on is_working_day=true). It does not, however, detail date-range limits or rate/error behavior.

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?

It is front-loaded with the usage decision and scope caveats, which is the right ordering. It is somewhat long: the full output-field list, formula, REST fallback and docs URL add bulk, though each serves a purpose. Overall efficient but not maximally tight.

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?

With an output schema present, enumerating return fields in the description is partly redundant, but coverage, formula, inputs, and a runnable JSON example make the definition self-sufficient for a country-scoped calculator among many siblings. Minor redundancy keeps it from a 5.

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 both params (start_date, working_days) are already documented, including the signed-offset and start-date-exclusion semantics. The description's 'Inputs' line merely repeats the parameter names and adds no syntax or meaning beyond the schema. Baseline 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+resource+scope: adding/subtracting Finland authority-scope working days. It explicitly frames the tool as a deterministic offset computation and distinguishes it from the discovery/legacy path ('call this tool directly... instead of ... stopping at discovery').

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 Finland working-day offset') and when-not-to-use conditions (nationwide public-holiday-only layer, Midsummer Eve, Christmas Eve, employer/collective-agreement/sector/school/bank/Åland/Sámi and local closures not inferred, private-sector leave treatment). It also directs the agent to return the calculation rather than answer from memory.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: the deterministic formula ('move one day at a time; decrement only on is_working_day=true'), explicit coverage scope, and a direct REST fallback endpoint. It stops short of stating rate limits or error behavior.

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?

Front-loads the use case well, but bloats with a redundant outputs enumeration even though an output schema exists, plus formula/REST/docs blocks. The muddled 'Do not use this when...' sentence adds confusion rather than scoping information, so size is not fully earned.

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 two-param read-only calculator with an output schema, the description is complete: coverage scope, determinant formula, fallback path, and docs link are all present. The redundant output-field list is unnecessary given the output schema, but nothing an agent needs 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 description coverage is 100% and the schema already documents both parameters, including the 'start date excluded for non-zero offsets' rule and the ±1000 bound. The description only restates the input names ('start_date (date); working_days (integer)') without adding format or range meaning, so the baseline 3 applies.

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?

States a specific verb+resource+scope: 'Adds or subtracts France authority-scope working days in exact coverage,' and anchors it with 'deterministic France working-day offset.' The France authority-scope qualifier distinguishes it from the 60+ other country/region add_*_working_days siblings.

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?

Gives a clear positive trigger ('when you need a deterministic France working-day offset') and an explicit directive to call it rather than answer from memory or stop at discovery. However, the exclusion sentence ('Do not use this when alsace-Moselle, overseas territories, employer... are not inferred') is garbled and doesn't name an alternative scope tool, so the negative guidance is only partly usable.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: nationwide statutory layer only, 2026 observed-date dataset, lunar dates and later Executive Instruments may change, and pre-Act-1142 Founder's Day is excluded.

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?

Front-loaded with the when-to-use condition, which is good, but several sentences restate the same idea ('Adds or subtracts... in exact coverage' repeats the opening), the example user requests are low-value, and the formula is duplicated across the description. The REST fallback and docs URL earn their place; the redundancy does not.

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?

Output schema exists, so the enumerated output fields are redundant but harmless. Everything an agent needs to call correctly — scope limits, date window, formula, fallback endpoint — is present, missing only explicit sibling differentiation against count_/check_ variants.

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% for both parameters, so baseline 3 applies. The description lists the inputs and a JSON example but adds no semantics beyond the schema's own field descriptions ('signed offset', date range).

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?

States a specific verb (add/subtract) and resource (Ghana working days) plus the exact scope: 'deterministic Ghana working-day offset'. An agent can distinguish this from count_gh_working_days and check_gh_working_day by the offset semantics, though neither sibling is named explicitly.

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?

Gives explicit 'Use this when...' and 'Do not use this when...' clauses plus a directive to call the tool rather than compute from memory. The exclusions are real (private-employer, bank, exchange, school calendars are out of scope), but the negative clause is grammatically mangled ('Do not use this when this package covers...'), which weakens routing precision.

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

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

Annotations already declare readOnly/idempotent/openWorld=false, and the description adds substantive behavior beyond them: the exact reference semantics, the CLDR weekend rule, coverage window, substitute-day policy, the day-by-day counting formula, the output units, and a pinned REST fallback with a warning not to guess other paths.

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?

Front-loaded with usage and exclusions in labelled sections that are easy to scan, but it is long and carries some redundancy (re-listing all ~17 output fields, duplicating the JSON example already in the schema, and restating the REST URL).

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?

Given a 3-parameter, high-coverage schema with an output schema and multiple near-identical siblings, the description covers semantics, scope, sourcing, formula, fallback endpoint, and docs link. Nothing an agent needs to select or invoke it correctly 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 description coverage is 100%, so all three parameters are already documented (including the alpha-2 pattern, date format, and signed-offset unit). The description's Inputs line largely restates the schema and adds no new format or boundary meaning, so the baseline 3 applies.

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?

States a specific verb (adds/subtracts working days) plus the pinned reference source, scope (nationwide-only OpenHolidays, 2026-2028) and a concrete example request. It is clearly distinguishable from siblings like count_global_public_holiday_working_days or check_global_public_holiday_working_day.

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?

Explicit when-to-use (need a 2026-2028 offset and accept nationwide-only, no-inferred-substitute-day semantics; call directly instead of answering from memory) and an explicit do-not-use clause (official authority, regional/local or employer calendars, substitute-day rules, out-of-coverage dates). This is textbook routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: pinned snapshot semantics, observed/estimated source flags, coverage window, the exact day-by-day formula, and the REST fallback endpoint with a warning not to guess other paths.

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?

Front-loaded with usage guidance and well-organized under labels, but it is long and repeats the JSON example already present in the input schema, plus an output field list that duplicates the existing output schema. Most sentences earn their place, though a few are 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?

Covers scope limits (2026-2028 coverage), required inputs, a worked example, computation semantics, and a documented fallback for a low-complexity calculation tool. Since an output schema exists, the enumerated output fields are redundant but harmless rather than a gap.

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%, so the schema already documents all three parameters (including enum, pattern, bounds, and unit), making 3 the baseline. The description restates the parameter list and adds only marginal detail (start date exclusion for non-zero offsets, working-day decrement rule), which is genuine but modest added meaning.

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 ('Adds or subtracts working days using the pinned OpenWorkdays national-scope reference for 246 country/territory codes') and distinguishes its 'broad reference' scope from official-authority, regional, and employer calendars. It never names the closest sibling tools (add_global_working_days, add_global_public_holiday_working_days), so the differentiation is conceptual rather than explicit.

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?

Gives explicit when-to-use ('when you need a broad 2026-2028 date offset'), explicit when-not-to-use ('direct official authority, regional/local or employer calendar, or dates outside published coverage'), and an operational directive ('Call this tool directly and return its calculation instead of answering from memory'). Nothing is left to inference.

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

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

The annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior. The description adds substantial behavioral context beyond those annotations: the exclusion of public-holiday defaults, the CLDR weekend-rule basis, the step-by-step formula, output fields, and a direct REST fallback. There is no contradiction with the 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 and exclusions, then follows a scan-friendly structure with inputs, examples, outputs, formula, fallback, and docs. It is longer than necessary because the inputs and outputs sections largely duplicate the fully described schema and output schema, but the organization keeps it readable for a complex calculation 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?

Given the tool complexity, full schema coverage, output schema, and annotations, the description is complete enough to select and invoke the tool correctly. It covers scope, exclusions, examples, inputs, computation behavior, outputs, and fallback documentation.

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 each parameter is already documented in the schema with type, examples, and constraints. The description repeats the inputs and gives a complete JSON example, but it adds little semantic meaning beyond what the schema already provides. The baseline score 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: adding or subtracting weekday-baseline working days for a CLDR territory. It directly distinguishes this from public-holiday, employer, bank, exchange, school, religious, and emergency-closure calendars, which is exactly the boundary needed among the sibling working-day tools.

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 guidance: a weekday-based date offset with public holidays excluded. It also gives explicit when-not-to-use guidance: when a public-holiday or other specialized closure calendar is required. Although it does not name the exact sibling tool, the condition maps unmistakably to the public-holiday sibling and is stronger than a generic context cue.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real domain context beyond that: which holidays are and are not treated as compulsory, that substitute-day and employer-discretion policies exist, and that regional/municipal/school/bank schedules are not inferred.

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-case statement is front-loaded, but the body is bloated and partly garbled (the 'Do not use this when this package covers...' phrasing is hard to parse), and it enumerates an output field list that the output schema already provides.

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 two-parameter deterministic calculator with an existing output schema, the description covers scope, coverage caveats, and invocation intent adequately. The redundant output enumeration and awkward exclusion sentence are minor blemishes rather than missing information.

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%, so both parameters are already fully documented. The description lists the inputs and adds a formula note ('decrement only on status.is_working_day=true'), but that is algorithmic detail rather than clarification of the parameter values beyond 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 opens with a specific use case and states plainly that it 'Adds or subtracts Greece authority-scope working days in exact coverage.' The Greece/jurisdiction scope cleanly distinguishes it from the many sibling add_*_working_days tools.

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 ('Use this when you need a deterministic Greece working-day offset') and instructs the agent to call it rather than compute from memory. The 'Do not use this when...' clause is garbled but signals that optional/regional/employer-discretion layers are out of scope, which is a useful exclusion, though it never names a specific alternative sibling.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds genuinely new behavioral context: the algorithm ('move one day at a time; decrement only on status.is_working_day=true'), the deterministic guarantee, the explicit non-inference of statutory/school/bank holidays, and a REST fallback endpoint. No auth, rate-limit, or error-behavior notes, so not a 5.

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?

Front-loads the routing instruction, which is good, but the body is padded: the 16-field output list is pure duplication of the output schema, the territory name is repeated in near-identical phrasing across three lines, and the REST-fallback/docs URLs consume space without aiding selection. The useful content could be roughly halved.

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 2-parameter deterministic calculator with a full output schema and rich annotations, the description covers the remaining burden well: scope, exclusions, algorithm, and an API fallback. Enumerating return fields is redundant given the output schema, but nothing an agent needs to invoke it correctly 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 description coverage is 100%, so both parameters (start_date, working_days) are already documented, including the 'signed offset; start date excluded for non-zero offsets' semantics. The description repeats the input list and adds a JSON example, plus the formula clarifies what working_days means operationally, but this is marginal 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?

States a specific verb and resource: 'Adds or subtracts 中国香港特别行政区 authority-scope working days in exact coverage', with a concrete 'What it computes' line and example requests. However, it never distinguishes itself from the many close siblings (add_china_working_days, count_hk_working_days, check_hk_working_day) or the other HK-adjacent calendars, so an agent must infer the boundary from the name alone.

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?

Gives explicit positive routing ('Use this when you need a deterministic working-day offset... return its calculation instead of answering from memory') and an explicit scope exclusion ('Do not use this when this package is the Hong Kong general/public-holiday calendar... statutory employee holidays, employer rest days, school calendars, bank/exchange closures... are not inferred'). It stops short of naming the sibling tools (count_/check_ variants) as alternatives, which is the one routing gap.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, non-open-world). The description adds genuine scope disclosure: what is NOT computed (individual shifts, replacement weekly rest, employer/local/sector schedules, payroll, legal deadlines, future years), plus a REST fallback path and docs link. This is real behavioral context beyond the 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 bloated with template fragments and broken sentences (e.g. 'Add or subtract Croatia working days around Good Friday is not a general statutory holiday,' 'Do not use this when croatia 2026 article 1 general holidays over an explicitly selected Monday-Friday planning baseline'). Example requests, output field lists, formula, REST path, and docs are all crammed in without clear front-loading; several sentences do not earn their place.

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?

The scope boundaries and coverage limitations are meaningfully covered, and an output schema exists so return values need not be explained (the long output-field dump is redundant). However, the malformed exclusion clause and cluttered structure leave the when-not guidance incomplete for an agent deciding between this tool and the count/check siblings.

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 all three parameters are already documented in the schema; the baseline is 3. The description restates the inputs and adds the constraint that mon_fri_planning is required and not an individual statutory roster, but contributes little beyond what the schema already supplies.

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: 'Adds or subtracts Croatia authority-scope working days in exact coverage,' and the opening line frames it as a deterministic Croatia working-day offset. This clearly distinguishes it from sibling check_hr_working_day and count_hr_working_days, though that distinction is left implicit rather than named.

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?

There is a usable when-to-use instruction ('Call this tool directly and return its calculation instead of answering from memory') and an attempt at a when-not clause, but the exclusion sentence ('Do not use this when croatia 2026 article 1 general holidays over an explicitly selected Monday-Friday planning baseline') is grammatically broken and its condition is not parseable. Guidance exists but is partly garbled.

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

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

Annotations already mark it read-only, idempotent, non-destructive and closed-world, yet the description adds substantial domain behavior: eleven statutory holidays, three paired transfers, three working Saturdays, no automatic substitute Monday, no inferred shift/bank/exchange/payroll schedules, and a decree expiry of 2027-01-01. This is exactly the kind of coverage/limitation context annotations cannot express.

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 definition is long and contains redundancy: the example user requests, the outputs list (already in the output schema), the REST fallback URL and docs link all inflate it. It is information-dense and somewhat front-loaded, but several sentences could be trimmed without loss.

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?

Given a deterministic calculator with a full output schema and complete annotations, the description supplies the calendar coverage, transfer rules and expiry that an agent needs to decide whether the tool applies. Its main gap is the ambiguous when-not sentence; otherwise it is complete enough to invoke correctly.

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 the baseline is 3, but the description goes further by spelling out the signed-offset semantics (

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 opening 'Adds or subtracts Hungary authority-scope working days in exact coverage' gives a specific verb and resource, and the tool is clearly the HU member of the country working-day family, distinguishable from check_hu_working_day and count_hu_working_days. The purpose is clear but muddied by the garbled 'Do not use this when hungary 2026 general Monday-Friday work schedule only' clause that interrupts the flow.

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 says to call the tool directly rather than answering from memory or stopping at discovery, and notes the requirement for an explicit work_schedule. The 'Do not use this when...' sentence appears intended as an exclusion but is syntactically broken, so the when-not guidance is only partially usable.

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

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

Goes well beyond the readOnly/idempotent annotations by disclosing the algorithm ('move one day at a time; decrement only on is_working_day=true'), the non-inferred schedule boundaries, a REST fallback URL, and documentation link. This is substantive behavioral context the annotations cannot convey.

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?

Front-loaded with the trigger and exclusion, which is good, but the 'Outputs:' field list duplicates the existing output schema and the formula/REST/docs lines pad an otherwise tight definition. The core guidance is buried among redundant enumerations.

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 2-parameter calculator with an output schema and full annotations, the definition covers trigger, exclusions, computation, and fallback. Minor confusion in the 'cuti bersama' exclusion phrasing, and the output list is redundant, but nothing an agent needs 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 description coverage is 100%, so both parameters are already documented, including the signed-offset/exclusion semantics. The description's 'Inputs:' line merely restates types, adding nothing beyond the schema, so baseline 3 applies.

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?

States a specific verb ('adds or subtracts') plus resource ('Indonesia authority-scope working days') and scope ('exact coverage'). An agent can distinguish this from the many sibling add_*_working_days tools purely by jurisdiction.

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?

Explicit 'Use this when...' trigger, a directive to call directly rather than answer from memory, and an explicit 'Do not use this when...' exclusion covering cuti bersama/ASN/employer-specific schedules. Both the positive and negative conditions are stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds substantive behavioral context beyond that: the pinned 2026 Gazetted schedule, weekend baseline, the fact that Restricted and local optional selections are not inferred, and the day-by-day decrement formula. It also surfaces policy fields returned so the agent knows what constraints apply.

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?

Well front-loaded: purpose, exclusions, computation, example, inputs, JSON example, outputs, formula, fallback and docs. It is long, and the Inputs line plus full JSON argument example and the Outputs list partly duplicate the schema and output schema, so there is some redundancy, but each labelled section earns its place.

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?

Covers the computed schedule, the office_scope requirement, the formula, an explicit JSON example, the REST fallback endpoint, and docs link. With an output schema present, the description is more than sufficient for an agent to select and call the tool correctly.

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%, so the baseline is 3. The description goes beyond by restating the inputs, explaining working_days is a semantical offset, and providing a complete JSON argument example with office_scope enum and date format, which reinforces how to invoke it correctly.

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?

States a specific verb (add/subtract working-day offset), a precise resource (India central-government date offset) and scope (2026 pinned Gazetted schedule, office scope required). It also distinguishes this from state/UT, bank, employer, school and exchange calendars, which lets an agent separate it from the many sibling country tools.

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?

The first sentence gives the condition to use it and even instructs the agent to call directly rather than answer from memory or stop at discovery. The 'Do not use this when...' sentence explicitly names the excluded scenarios (state/UT, bank, employer, school, exchange, locally selected optional-holiday calendars), giving both when and when-not.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes further, disclosing the actual algorithm ('move one day at a time; decrement only on Ireland status.is_working_day=true'), the exact coverage window (2026-2027), and a REST fallback URL. This is substantive behavioral context beyond the structured fields.

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?

Front-loaded and clearly labeled (Use this when / Do not use / What it computes / Inputs / Outputs / Formula / REST fallback / Docs). Despite its length, each section serves a distinct purpose with no wasted text.

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?

An output schema exists, yet the description supplements it with coverage window, formula, worked example, fallback endpoint, and docs link, leaving no gap an agent would need before invoking the tool.

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 the schema already documents start_date and working_days. The description restates the inputs and gives a complete JSON example, but adds little semantic detail beyond the schema, so the baseline 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?

States a specific verb+resource+scope: 'Adds or subtracts Ireland national working days in exact 2026-2027 coverage.' It distinguishes the operation from the check_ireland_working_day and count_ireland_working_days siblings and from other territories, so an agent can route correctly without opening a schema.

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?

Explicit when-to-use ('when you need a deterministic Ireland national public-holiday offset'), explicit instruction to return the calculation directly rather than answering from memory, and an explicit when-not-to-use exclusion ('employer-selected benefit day or non-national schedule'). Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: the exact computation formula ('move one day at a time; decrement only on status.is_working_day=true'), the authority-scope coverage boundary, and a REST fallback endpoint with an explicit warning not to guess other paths.

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 critical routing sentence is front-loaded, which is good, but the description is bloated: the 'Outputs:' enumeration duplicates the output schema field-by-field, and the docs/fallback/formula lines, while useful, push the length well past what a small offset calculator needs. Several labelled sections could be trimmed without losing decision-relevant information.

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 two-parameter deterministic calculator with an output schema and full annotation coverage, this is nearly complete: it discloses coverage scope, computation formula, a REST fallback, and documentation. The only real gap is that it explains return fields the output schema already defines and never clarifies its relationship to the count_/check_ siblings.

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 both parameters are already documented in the schema. The description restates the input names and gives one full JSON example (including the working_days=0 boundary), which adds marginal value but does not go beyond the schema's own examples and the 'signed offset; start date excluded for non-zero offsets' note.

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?

States a specific verb and resource with scope: 'Adds or subtracts Italy authority-scope working days in exact coverage' plus a 'deterministic Italy working-day offset'. The Italy scoping distinguishes it from the many country siblings, but the description never explicitly distinguishes it from check_it_working_day or count_it_working_days, which share the same country scope and differ only in operation.

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?

'Use this when you need a deterministic Italy working-day offset' gives clear when-to-use context, and the 'Do not use this when...' clause signals a scope limitation. However, it never names the obvious alternatives (count_it_working_days, check_it_working_day) or states the condition that selects between them, so the routing between sibling operations is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description goes beyond them by disclosing the pinned dataset/version, the deterministic step-by-step algorithm, the enumerated output fields, source attributions, and a REST fallback path with an explicit warning not to guess other /api/* paths.

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?

Front-loaded with the use/defer decision and organized into labeled sections, but it is long and repeats information the schema already contains (inputs list, JSON example, output field list). Mostly earns its length, with some redundancy against structured fields.

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?

Covers computation semantics, scope limits, output fields, dataset versioning, and a REST fallback plus doc link, which is ample for a 2-parameter deterministic calculator. The output-field enumeration is redundant given the output schema exists, keeping it just under a 5.

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 the schema already carries both parameters' formats and the signed-offset semantics. The description's 'Inputs' line and JSON example merely restate what the schema provides, adding no new syntactic or edge-case detail. Baseline 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?

States a specific verb (adds/subtracts), resource (dates), and scope (Japan statutory national-holiday schedule with weekend baseline and a 2026-2027 window). This is clearly distinguishable from the 60+ sibling country working-day tools and from check_/count_japan_national variants.

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?

Explicit when-to-use ('deterministic Japan statutory national-holiday date offset in 2026-2027'), an explicit instruction to prefer this over memory/discovery, and an explicit when-not ('company, school, bank, exchange or prefectural closure semantics'). Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, but the description adds substantial extra context: deterministic exact-coverage calculation, Saturday-Sunday baseline convention, 2026 Gazette pinning for Idd holidays, need to refresh future lunar dates, preservation of the Act's Sunday substitution rule, no Saturday-to-Monday inference, the step-by-step formula, and a REST fallback endpoint. This goes well beyond the structured 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 the main use case and organized into sections for scope, computation, examples, inputs, outputs, formula, REST fallback, and docs. However, it is verbose, includes an output field list despite an output schema being present, has awkward example user requests, and contains redundant caveat phrasing that could be tightened without losing selection guidance.

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 read-only deterministic calculator, the description is highly complete: it covers scope, limitations, data vintage, holiday policy, formula, inputs, example invocation, outputs, REST fallback, and documentation. The output list is redundant because an output schema exists, but no critical context needed to select or invoke the tool 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 description coverage is 100%, and the schema already documents both parameters with descriptions and examples. The description restates the inputs and gives a complete JSON example, but adds little semantic meaning beyond what the schema provides, such as the signed offset and start-date exclusion rule. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource: 'Adds or subtracts Kenya authority-scope working days' and scopes it as a 'deterministic Kenya working-day offset'. This clearly distinguishes it from the many country-specific sibling tools, so an agent can identify it as the Kenya add-offset calculator without opening the schema.

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?

Gives explicit when-to-use guidance: 'when you need a deterministic Kenya working-day offset', and says to call it directly instead of answering from memory. It also lists when-not-to-use cases such as private-employer, bank, school, county, sector, diplomatic, or shift-work calendars. It does not name sibling alternatives such as check_ke_working_day or count_ke_working_days, so it falls short of a 5.

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

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

Annotations already declare readOnly/idempotent/closed-world, and the description still adds real behavioral context: the exact computation rule ('move one day at a time; decrement only on status.is_working_day=true'), the coverage boundary, the enumerable output fields, a REST fallback endpoint, and a docs link. This goes well beyond the structured safety hints.

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?

Usage guidance is correctly front-loaded and the sectioned layout is easy to scan, but the Inputs line duplicates the schema and the full Outputs field list duplicates the existing output schema. The size is larger than the marginal informational gain warrants.

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?

Covers everything an agent needs: purpose, scope exclusions, argument example, computation rule, fallback transport, and docs URL. Since an output schema exists it needn't explain return values, yet the description is complete even without relying on that.

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 the baseline is 3. The description's 'Inputs: start_date (date); working_days (integer)' only restates the schema types, and the offset semantics ('start date excluded for non-zero offsets') are already documented in the schema. The JSON example adds a little concreteness but no new meaning.

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 gives a specific verb+resource+scope: 'Adds or subtracts South Korea authority-scope working days in exact coverage.' An agent can tell this computes an offset rather than checking a day or counting days. It never names its closest siblings (count_kr_working_days, check_kr_working_day, list_working_day_calendars), so the differentiation rests mainly on the tool name.

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?

Explicit when-to-use ('when you need a deterministic South Korea working-day offset') and when-not-to-use ('package covers the 2026 statutory/public-office schedule only; private-employer, school, bank, exchange, local-government and 2027 schedules are not inferred'), plus a directive to call it rather than answer from memory. It stops short of naming an alternative tool to use instead for the excluded cases.

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

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

Annotations already declare the safe/idempotent read profile, but the description adds real behavioral context beyond them: exact coverage boundaries, calendars explicitly NOT inferred, Qurban Ait handling, and the Constitution Day legal-transition caveat. It also supplies the iteration formula and a canonical REST fallback path.

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?

Section labels (What it computes, Inputs, Outputs, Formula, Docs) front-load usefully, but the Adilet/Constitution Day passage is dense legal detail of marginal value to a caller, and the 'Do not use this when this package covers...' clause is a malformed run-on. Several sentences do not earn their place for tool-selection purposes.

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?

With an output schema and annotations already present, the definition still covers enough for correct invocation: scope limits, formula, example arguments, and error-avoidance guidance. The Outputs field list redundantly duplicates the output schema, but nothing an agent needs to call it 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 description coverage is 100% and both parameters (start_date, working_days) are already fully documented in the schema, including the sign convention. The description restates the inputs and adds a JSON example, but contributes no meaning beyond what the structured schema already provides; baseline 3 applies.

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?

States a specific verb+resource (add/subtract Kazakhstan working days) and its scope precisely: the nationwide published 2026 five-day schedule over a Saturday-Sunday baseline. It names the country-specific coverage that distinguishes it from the ~60 sibling country tools, so an agent can select it without opening schemas.

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?

Provides an explicit 'use this when' trigger (deterministic Kazakhstan working-day offset, prefer the calculator over memory or stopping at discovery) and a 'do not use' clause listing excluded calendar types (six-day, shift, continuous-operation, employer, bank, school, local, sector). The do-not-use sentence is grammatically garbled, and it does not name sibling alternatives like count_kz_working_days or check_kz_working_day, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: authority-scope limits, government-office-only fuel-conservation entries cancelled April 8, no inference of private employers/essential services, and the explicit one-day-at-a-time algorithm. The garbled do-not-use sentence costs it a point.

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?

Badly bloated and poorly front-loaded: it dumps the full output field list despite an output schema existing, includes a REST fallback URL and docs link, and buries the actual purpose among contradictory caveat sentences. Several sentences do not earn their place, and the 'Do not use this when...' construction is syntactically broken.

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?

An output schema exists, so enumerating return fields is unnecessary, but the description does fill the important gap of calendar-scope caveats (what is and is not inferred, dataset limitations). For a 2-param, richly annotated tool it is nearly complete, missing only clean routing against its country-sibling alternatives.

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 the baseline is 3. The description restates the two inputs and supplies a complete JSON argument example, but adds no semantics the schema lacks (signed offset, start-date exclusion, -1000..1000 range are all in 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?

States a specific verb and resource: 'Adds or subtracts Sri Lanka authority-scope working days in exact coverage', plus the formula (move one day at a time, decrement only when status.is_working_day=true). This distinguishes an offset operation from the sibling check_lk_working_day/count_lk_working_days family, though it never names those alternatives directly.

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?

The opening line gives a use condition ('when you need a deterministic Sri Lanka working-day offset'), but the 'Do not use this when' clause is incoherent — it reads as a scope disclaimer ('this is a combined official holiday-class calendar, not a universal private-employer closure rule') rather than a genuine when-not/alternative routing statement. No sibling tool is named as an alternative.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds substantial context beyond those annotations: deterministic planning-calendar semantics, sixteen statutory holidays, no weekend substitution or bridge inference, and explicit non-computation of payroll, personal leave, and future years.

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 far longer than necessary and includes redundant sections: a full output list despite an output schema, example user requests, and complete JSON examples already present in the schema. It is front-loaded but bloated with material that does not earn its place.

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?

Given the tool's complexity, the description is complete enough for correct invocation. It covers inputs, formula, holiday behavior, exclusions, REST fallback, and documentation link, and 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 description coverage is 100%, so the baseline is 3. The description adds meaning through the planning formula and explicit notes that work_schedule selects a planning calendar rather than a personal roster, though the JSON examples largely duplicate the schema examples.

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: 'Adds or subtracts working dates' for Lithuania. It distinguishes the tool from sibling check_lt and count_lt tools by framing it as an offset calculation, and it names the country and year scope directly.

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 clear when-to-use guidance and several when-not-to-use exclusions, such as actual hours, pay, shifts, and personal rosters. The awkward 'Do not use this when lithuania 2026 Labour Code holiday facts...' sentence is unclear, and it does not explicitly name sibling alternatives like check_lt or count_lt.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial scope disclosure on top: bank-only Good Friday/Christmas Eve afternoons, customary or collective holidays, personal leave, hours, payroll and legal deadlines are explicitly out of scope, plus the exact formula and dataset version. This is meaningfully more than the annotations provide, though the mutated 'Do not use this when' sentence weakens the exclusions.

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 definition is bloated with template-rendering artifacts: the three 'Example user requests' lines do not parse as sentences ('Add or subtract Luxembourg working days around Europe Day is statutory rest.'), the negation clause is truncated, and holiday commentary is repeated between the when-not and what-it-computes sections. Useful elements (REST fallback, docs URL) are buried.

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 3-param, fully-specified, annotated tool with an output schema, this is close to complete: it establishes the deterministic-offset contract, the coverage boundaries, the formula, and a fallback URL. Since an output schema exists, the long Outputs field list is redundant rather than necessary, but nothing an agent needs in order to call it correctly 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 description coverage is 100%, so the schema already carries the semantics for start_date, working_days and work_schedule (signed offset, start-date exclusion for non-zero offsets, explicit Mon-Fri baseline). The description's Inputs line and JSON example restate rather than extend that meaning, so the baseline of 3 applies.

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?

States a specific verb+resource+territory: 'deterministic Luxembourg working-day offset', and clarifies coverage scope ('Adds or subtracts Luxembourg authority-scope working days in exact coverage'). It does not, however, explicitly position itself against the obvious siblings check_lu_working_day and count_lu_working_days, so an agent must infer the distinction from the verb alone.

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?

There is a genuine usage directive ('Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery'), which is useful routing guidance. But the complementary 'Do not use this when...' clause is grammatically broken and never resolves into a clear exclusion condition, so the when-not guidance is only implied.

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

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

Goes well beyond the annotations by disclosing that Order 330 transfers apply only to covered/adopting employers with no inferred adoption, that Section 2 observances add no rest, that shortening is conditional, and that six-day/shift rosters, payroll, actual hours and legal deadlines are out of scope. It also discloses the deterministic formula and a direct REST fallback endpoint.

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 opening sentence is well front-loaded, but the text is padded with repetition (explicit basis/schedule requirement stated multiple times), three near-identical 'example user requests', and a long enumeration of output fields that duplicates the existing output schema.

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?

With an output schema present, annotations covering the safety profile, and 100% schema coverage, the description supplies everything else an agent needs: scope limits, prerequisites, edge-case policy, formula, and a REST fallback. Nothing material is missing for correct 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 the baseline is 3. The description restates the four inputs and repeats the calendar_basis adoption caveat that the schema already documents, adding examples but little genuinely new parameter meaning beyond 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?

States a specific verb+resource+scope: adding/subtracting Latvia authority-scope working days under an explicit calendar basis. It is clearly distinguishable from sibling families (check_lv_working_day, count_lv_working_days) and other country variants by naming Latvia and the add/subtract offset operation.

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?

Gives an explicit 'use this when' trigger and a 'do not use this when' section, plus hard prerequisites (explicit calendar_basis and work_schedule=mon_fri_planning). The exclusion sentence is garbled ('Do not use this when latvia 2026 only') and no sibling tool is named as an alternative, so it falls short of a full 5.

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