Bankday

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: no cutoff times, no holiday/weekend handling, no statement of how precise the 'estimate' is, and no return shape. Only the word 'estimate' hints that the result is approximate rather than guaranteed.

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?

A single tight sentence with the purpose and both determining inputs front-loaded. No filler, no restating of the tool name, nothing that could be trimmed without losing 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?

No annotations, no output schema, and only 33% schema coverage for a 3-parameter tool. The description omits the amount parameter's role, cutoff-time rules, holiday/weekend behavior, and what the returned value looks like — an agent cannot call this confidently on edge 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 description coverage is 33% (only submitted_at documented), so the description must compensate. It adds useful meaning for submitted_at ('submission time') and for the standard/same-day enum, but the amount parameter is never mentioned or explained, leaving one of three parameters semantically opaque.

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 (estimate) and resource (US ACH payment settlement date) and names the two determining inputs (submission time, standard vs same-day). It is clearly separable from generic business-day siblings like add_business_days or is_business_day, though it never explicitly contrasts with them or with fx_spot_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?

The 'given submission time and standard vs same-day' phrasing implies the conditions under which the tool is used, but there is no explicit when-to-use statement, no exclusion (e.g., not for FX or wires), and no routing to the analogous fx_spot_date sibling. Usage is inferable rather than 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?

No annotations exist, so the description carries the full burden. It usefully discloses that negative inputs invert the operation, but says nothing about whether the input date must already be a business day, how weekends/holidays are handled, or how multiple calendars combine into a joint calendar.

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?

A single sentence, front-loaded with the core operation and the negative-value rule packed into a parenthetical. 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?

For a simple date-arithmetic tool with a well-described calendar parameter, the definition is roughly adequate. But with no annotations and no output schema, the description omits holiday/weekend semantics and the return format, which an agent would need to interpret results confidently.

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 67%, and the undocumented `days` parameter is exactly where the description compensates: 'negative number' subtracts, which the bare integer schema does not convey. The `date` and `calendar` formats are already well documented in the schema, so the remaining gap is small.

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 business days to a date) with the twist that negative values subtract, which distinguishes it from a subtraction-only tool. It does not explicitly distinguish itself from sibling count_business_days, but the operation is unambiguous.

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: use this to shift a date by N business days. The parenthetical about negative numbers gives a little conditional guidance, but the description names no alternatives (e.g. count_business_days) and states no when-not conditions.

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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the boundary convention (start exclusive, end inclusive), which is real behavioral context, but says nothing about return type, invalid calendar ids, or what happens when end precedes start.

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?

A single sentence with zero waste, and the semantically important boundary rule is included inline rather than buried. Nothing to trim.

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 simple three-parameter counting tool with fully documented params and no output schema, the description covers purpose and range semantics. The only real gap is the return value (an integer count) and edge-case behavior for invalid ranges.

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 parameters are already documented (including the rich calendar-id format). The description adds meaning beyond the schema by specifying how start and end are treated (start exclusive, end inclusive), which the schema's bare 'Date as YYYY-MM-DD' does not convey.

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 ('Count business days between two dates') that an agent can distinguish from siblings like add_business_days or is_business_day. It does not, however, explicitly name those alternatives or clarify the boundary between counting and date arithmetic.

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 the name and the stated range semantics, but the description offers no explicit when-to-use guidance or exclusions versus siblings such as add_business_days or is_business_day. An agent must infer the selection from the tool name 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?

With no annotations, the description carries the full behavioral burden. It discloses key computation rules (T+2/T+1 conventions, joint holiday calendars), which is useful, but it omits error handling, convention selection logic, and any edge-case 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?

The description is a single, front-loaded sentence that efficiently covers purpose and key conventions without any wasted words.

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 low-complexity, two-parameter tool with no output schema, the description provides sufficient context for correct invocation. It explains the date calculation basis, though it could mention error cases or which convention applies to which pair.

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, and the description adds no meaning beyond what the schema already provides. A baseline score of 3 is appropriate when the schema fully documents the inputs.

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 tool returns the FX spot value date for a given currency pair and trade date, with specific conventions. It is more than a tautology and the domain is distinct from the generic calendar siblings, but it does not explicitly differentiate itself from alternatives like 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?

No guidance is given on when to use this tool versus the sibling calendar functions, nor are any exclusions or prerequisites mentioned. The domain-specific name implies usage, but the description provides no actual when-to-use instructions.

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?

No annotations are provided, so the description carries the burden, and it discloses the output content beyond the name: it returns closure info plus the next/previous business day. That is meaningful behavioral context for a read-only query with no output schema, though it says nothing about invalid dates or calendar defaults.

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?

A single front-loaded sentence that packs the check, the calendar scoping, and the return content with no filler. The semicolon-clause is dense but 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?

With no output schema, the description usefully summarises what comes back (closures, adjacent business day), which is the key missing piece an agent would otherwise lack. It stops short of noting error behavior for invalid dates, but the tool's low complexity makes that a minor 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%, so the schema already documents the YYYY-MM-DD date format and the extensive calendar id examples. The description adds no parameter detail beyond noting 'on a calendar', 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 (check) and resource (whether a date is a business day on a calendar), and clarifies scope with the calendar parameter. It is distinguishable from add_business_days/count_business_days/list_holidays by its yes/no-per-date nature, but it never names a sibling to sharpen the contrast.

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 the purpose: call it when you need a per-date business-day verdict for a given calendar. There is no explicit when-to-use versus add_business_days (which shifts a date) or today_status (which is today-only), and no stated prerequisites or exclusions.

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?

No annotations are provided, so the description carries the full disclosure burden. 'List' implies a read-only operation, but nothing states the return format, ordering, or what happens when the optional year is omitted (all years vs. current year).

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?

A single front-loaded sentence with no wasted words. It is efficient, though the extreme brevity is what leaves the guidance gaps noted elsewhere.

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 simple two-parameter read tool with no output schema, the description is minimally viable but omits the year-default behavior and any hint of the returned fields, which an agent would need to call and consume 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 50%: calendar is richly documented with examples in the schema, but year has no schema description. The phrase 'in a year' hints that year filters/scopes the listing, but the description does not clarify its optionality or default behavior, so it only partially compensates.

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 (list) and resource (holidays/closures) scoped to a calendar and year. It is clearly distinguishable from siblings like is_business_day or count_business_days, 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 description gives no when-to-use context, no exclusions, and no pointer to the related sibling tools (is_business_day, search_calendars). The agent must infer usage from the name 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup but never states whether an empty query returns all calendars, how matching works (exact vs substring), or what a caller gets back beyond 'ids'.

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?

A single front-loaded sentence with no filler; the resource and its facets come first. Nothing to trim, though it could afford one more clause given how little it says.

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, no-output-schema lookup this is close to adequate, and 'find calendar ids' does convey the return type. But with zero annotations and zero schema coverage, the description should say more about matching behavior and the no-argument default.

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 0%, so the description must compensate, and it partly does: it maps the opaque 'q' string to name/country matching and echoes the enum values for 'type'. It still omits matching syntax and whether 'q' searches multiple fields simultaneously, leaving real gaps.

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 ('Find') plus the resource ('calendar ids') and the three searchable facets, so the agent knows exactly what it retrieves. The sibling set (business-day and holiday math tools) is disjoint enough that no explicit differentiation is needed, though none is provided.

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?

No guidance on when to reach for this tool versus the other calendar-adjacent siblings (list_holidays, is_business_day), and no note on whether it is a prerequisite step for resolving a calendar id elsewhere. Usage is only implied by the verb.

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 no annotations, the description carries the burden. It usefully discloses that evaluation happens in the calendar's local time zone and that upcoming holidays are included in the answer, which is real behavioral context for a read query. It does not describe the response shape or what 'upcoming' spans, so disclosure is partial.

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?

Two short sentences, zero filler, with the core question front-loaded and the time-zone qualifier immediately after. Nothing needs trimming.

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 one-parameter read-only query with no output schema, the description covers what is asked, the time-zone semantics, and that holidays appear in the result. The main gap is disambiguation from is_business_day, which the description never addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'calendar' parameter is fully documented in the schema with id examples (us-fed, xnys, de). The description adds no syntax or format detail beyond that, 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?

The description states a specific question it answers ('Is today a business day') on a named resource (this calendar), scoped to today rather than an arbitrary date. However, it never distinguishes itself from the sibling is_business_day, leaving the agent to guess which one to call for the 'today' case.

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 the word 'today' and by the time-zone note, but there is no explicit when-to-use statement and no named alternative (is_business_day, add_business_days, list_holidays) to route the agent. The agent must infer the choice from the sibling names alone.

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