Bizday

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful behavioral context: default calendar selection, unknown calendar ids are errors, and calendar-specific exception handling. It does not cover every edge case, but it adds meaningful transparency 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 first sentence front-loads the result, but the paragraph repeats schema information such as the day range and the us-fed-banking calendar exception. The ambiguous 'days=1 always leaves the start date' phrasing also costs clarity rather than earning 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?

With an output schema and full parameter descriptions already present, the description supplies the key day-count convention, default calendar, and calendar exception behavior. It is nearly complete for calling the tool, though the day=1 wording could be clearer.

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 adds real semantic value by explaining that the start date is day 0 and by describing the calendar default, though it also repeats some schema details and the 'days=1 always leaves the start date' phrasing is ambiguous.

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 clearly states the operation: it returns the date that is N business days after a start date, with day-count semantics tied to Excel WORKDAY. It does not explicitly distinguish itself from siblings such as count_business_days or roll_date, so it is clear but lacks sibling differentiation.

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 parameter-level guidance such as omitting calendar for the default us-federal-opm, but it never says when to use this tool instead of count_business_days, roll_date, or other date utilities. The agent must infer tool selection from the name and description alone.

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, and the description adds genuinely new behavior: the 3660-day span cap, signed (possibly negative) output, error on unknown calendar ids, and calendar alignment quirks are all disclosed in the schema layer. That 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?

Four short sentences, purpose front-loaded, constraints following. Terse constructions like 'Negative when end is earlier' and the redundant calendar-default line cost a little polish but nothing is 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?

With an output schema present, the return value needn't be described; the description instead covers exactly the non-schema essentials — boundary semantics, span limit, error behavior, and calendar defaults — leaving no significant gap 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 coverage is 100% with very rich per-parameter descriptions, so the baseline is 3; the description still adds meaning the schema lacks — that start/end define an *inclusive* span (the schema never says inclusive) — though 'Omit calendar for us-federal-opm' merely repeats the schema text.

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 — counting business days in an inclusive start-through-end span — and anchors the semantics to Excel NETWORKDAYS, which unambiguously separates it from siblings like add_business_days, is_business_day, and roll_date.

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 clear usage context (inclusive span, Excel NETWORKDAYS equivalence, negative result when end precedes start) and a defaulting rule for the calendar parameter, but never names an alternative tool or states when NOT to use this one (e.g., for a single-date check use is_business_day).

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, openWorld=false), so the bar is low, yet the description adds substantial behavioral detail: the trigger day is excluded, all calendar days count including intermediate weekends/holidays, only the last day rolls, holidays use the federal-office observed weekday, and Juneteenth is included. It also discloses explicit non-goals, which prevents misapplication.

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 core operation, then progressively hardening constraints and exclusions. Sentences are dense but every one earns its place by disambiguating expected behavior (trigger exclusion, roll-only-last-day, holiday rule). No filler.

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 values need not be explained, and the description fully covers the remaining gaps: scope of the rule, counting mechanics, holiday basis, and explicit non-goals. Nothing an agent needs to invoke this correctly on a legal deadline 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 adds value by stating the day range (1–3660), clarifying direction semantics ('after' or 'before'), and noting the absence of a calendar argument entirely — a meaningful constraint not obvious from the schema. It stops short of any additional syntax detail, so not a full 5.

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 precise verb ('count') plus the exact resource and governing rule (Fed. R. Civ. P. 6(a)(1) day-counting), and explicitly contrasts itself with 'Excel WORKDAY' and with business-day-style counting. An agent can distinguish it from count_business_days or add_business_days on the calendar-day-vs-business-day axis 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?

The description clearly scopes when this applies (Rule 6(a)(1) day periods) and lists explicit exclusions (state holidays, one-off holidays, clerk inaccessibility, Good Friday, Inauguration Day) plus a boundary disclaimer ('does not decide whether a filing is timely'). It never names the sibling alternative count_business_days by name, so routing between the two is left slightly implicit.

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 new behavioral context: the result includes calendar, sources, and a disclaimer; unknown ids error out; early closes stay open; and the not-legal/payroll/financial-advice caveat. That is real added value 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 purpose is correctly front-loaded, but the body is a long, repetitive wall of per-calendar exceptions, with near-duplicate phrasing such as 'Friday, July 3, 2026 stays open' repeated across several calendars and much of the enum text duplicated from the schema. 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?

With an output schema present, the description need not explain return values, and it still notes the result carries calendar/sources/disclaimer. Combined with date-format and error behavior for unknown ids, an agent has enough to call it correctly; the remaining gap is the absence of sibling routing.

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 enum descriptions already document each calendar id, so the baseline is 3. The description largely restates that schema content (us-fed-banking Saturday-holiday rule, us-nyse/us-sifma/us-ca/us-ny/us-nyc scopes) with only marginal additions such as specific example dates, so it does not clearly exceed 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 precise predicate: 'Whether a civil date is a business day, and why.' That is a clear verb+resource and is distinguishable from mutation/counting siblings (add_business_days, count_business_days, roll_date) by implication. It does not name any sibling explicitly, so it falls short of a 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 rich guidance on which calendar id to choose and states 'Omit calendar for us-federal-opm' plus 'Unknown ids are an error,' which is useful selection context. However, it never says when to use this tool versus the siblings (list_holidays, list_calendars, report_discrepancy), so tool-selection 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the default calendar and coverage ranges, which is useful context but not a behavioral trait like auth requirements or error handling beyond what annotations supply.

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 field list, but then spends several sentences enumerating coverage dates for individual calendars, which is redundant given that an output schema exists. It is not bloated with fluff, but it is longer than necessary for a no-parameter list 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?

With an output schema present, the description need not explain return values, and annotations cover the safety profile. It provides the key operational facts: what calendars exist and which is the default, making it complete enough for an agent to call this read-only 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?

The tool has zero parameters, so per the rubric the baseline is 4. The description lists output fields rather than input parameters, and the empty schema leaves no parameter semantics to clarify.

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 the resource ('Shipped calendars') and enumerates the fields returned (id, name, source URL, rules, coverage, last verified, changelog), making it clear this tool lists calendar definitions. It distinguishes itself from holiday-listing siblings by focusing on calendar metadata rather than holiday dates, though it never explicitly names an alternative.

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 only usage hint is 'us-federal-opm is the default,' which implies a fallback when no calendar is specified, but there is no explicit when-to-use guidance, no mention of when not to use it, and no named alternatives such as list_holidays.

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), yet the description adds real behavioral nuance: observed is null on us-fed-banking when the legal date is Saturday, Saturday holidays close Friday, distinct full-day vs. early-close semantics, per-calendar acceptance windows, and the forward-compatibility caveat that post-2030 years use identical rules rather than a later official table.

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 purpose is front-loaded and nearly every sentence carries a distinct per-calendar rule. It is a dense wall of prose with mild redundancy, though, repeating the Saturday-closes-Friday rule in both the bank and generic phrasings that the schema already states for us-fed-banking.

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 lookup tool with an output schema present, the description covers the caller's real ambiguities: which calendar to pick, what each calendar's rows mean, default behavior, year limits per calendar, and forward-compatibility. Nothing needed 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 coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema's generic 2021-2100 range by stating per-calendar year windows (us-nyse 2026-2028, us-sifma/ny/nyc 2026-2027, us-ca 2026) and the default-when-omitted behavior. It does not restate the enum values, but that is handled by 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?

Opens with a specific verb+resource+scope: 'Holiday rows for one year.' It immediately distinguishes itself from siblings like list_calendars (which enumerates calendars) and is_business_day (which tests a single date). An agent knows exactly what this tool returns.

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 rich context for choosing among the seven calendars, including their legal meaning and accepted year windows, which effectively routes the agent. However, it never explicitly names an alternative (e.g., use list_calendars to discover ids) or states when not to use this tool, so it stops short of full when/when-not 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 establish the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent). The description adds real behavioral context beyond that: the report is stored but NOT applied to either calendar, and the result is returned as "accepted true and applied false." It also constrains content (no names/emails). This is useful side-effect disclosure, though the "accepted true / applied false" wording is cryptic without the output schema.

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?

Purpose is front-loaded in the first sentence, which is good. But two sentences verbatim restate schema constraints for claim and source_url, spending words without adding information. The trailing "This is not a calculation" is placed last rather than with the other scoping notes, slightly weakening structure.

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 tool is low complexity (4 fully-documented params, output schema present), so the description need not explain return values. It covers the essential facts: this is a write that stores a report without applying it, with content restrictions. The one gap is that the "accepted true / applied false" semantics lean on the output schema rather than being self-contained.

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 all four parameters, including the date format, calendar enum, claim length, and URL constraints. The description largely repeats schema content ("claim is one line of at most 500 characters," "source_url is an http or https URL with no username or password"), adding only the marginal "Do not send a name or an email" restriction. 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 opening sentence states a specific verb and resource: "Store a suspected wrong closing for later review." This clearly distinguishes it from the calendar-computation siblings (add_business_days, roll_date, etc.), which never store anything. An agent can identify what this tool does and why it differs from its siblings 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?

Usage is implied by "suspected wrong closing for later review," and the description gives explicit exclusions: "This is not a calculation" and "The report is not applied to either calendar." This routes the agent away from mistaking it for one of the sibling calculation tools. However, no alternative tool is named, so it stops short of a full when/when-not/alternatives 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 cover read-only, idempotent, non-destructive and closed-world behavior, yet the description still adds real value: the idempotent no-op condition, the error on unknown calendar ids, and the scope limitation that it does not adjudicate filing timeliness. It does not restate anything the annotations contradict.

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?

Four short sentences, front-loaded with the core behavior, then scoping caveats, then the default-calendar rule. No filler and nothing 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?

With an output schema, a complete parameter schema, and full annotations, the description only needs to supply behavioral and scoping context — which it does via the no-op rule, the unknown-id error, the calendar default, and the explicit non-timeliness disclaimer.

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 enums are documented in the schema, so the schema carries the parameter burden. The description only restates the calendar default and the direction semantics, which the schema already conveys — marginal added meaning over structured data.

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 precise verb+resource behavior: keep the date if it is already a business day, otherwise move it to the nearest business day in the given direction. It explicitly bounds itself against neighbors — 'not Excel WORKDAY' and 'does not decide whether a filing is timely' — which separates it from frcp_6a_deadline and add_business_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?

Gives clear usage context: the no-op case, the two directions, and the default-calendar rule ('Omit calendar for us-federal-opm'). It also flags when this tool is the wrong choice (filing timeliness), though it never names the sibling an agent should use instead, so routing is implied rather than explicit.

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