TradingCalendars

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

With no annotations supplied, the description carries the full behavioral burden, and it does disclose several useful traits: days = 0 rolls a non-business start forward, skipped days are enumerated with reasons, and date defaults to today. However, it says nothing about invalid/unrecognized calendar codes, empty calendar arrays, or rate/latency characteristics for this dependency-heavy lookup.

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 with the core operation first and supporting rules after, and every clause earns its place. The calendar-example sentence is long and read as a run-on, so a small amount of structure could be tightened 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?

For a three-parameter, no-output-schema calculation tool, the definition covers the operation, all parameter meanings and edge cases, calendar sourcing, and even the shape of the returned skipped-day explanation. 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 0%, so the description must compensate, and it does: days explains sign convention and the zero edge case, date explains the today default, and calendars explains AND semantics (open in every calendar) plus concrete code examples across FX, exchange, payment-system, and bank categories plus a pointer to list_calendars.

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 verb-and-resource statement: computes the date N business days after (or before, via negative days) a start date. That distinguishes it immediately from business_days_between, is_business_day, and bank_holidays, which answer different questions.

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 names concrete use cases (settlement/value dates, T+1/T+2, payment due dates, deadlines) and points to list_calendars for obtaining valid calendar codes. It does not explicitly say when to prefer a sibling such as is_business_day or what to do for plain holiday lookups, 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?

No annotations exist, so the description carries the full burden. It does disclose the domain semantics (retail and commercial bank closures, not market or settlement closures) and the start default of today, which is useful behavior beyond the schema. It does not state the return shape, date ordering, coverage limits, or what happens if the centre code is unknown.

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 tightly packed sentences with the purpose front-loaded, followed by the scope definition and the default. Every clause carries information an agent needs; there is no filler or repetition of 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?

For a three-parameter read tool with no annotations and no output schema, the description gives enough to make a correct call: the key parameter's format and the start default. It leaves the end parameter undefined and says nothing about the response, which is a meaningful but not fatal 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 0%, so all meaning must come from the description. It usefully explains the financial_centre format with a concrete example (UN/LOCODE, e.g. USNYC) and clarifies that start defaults to today, which is not evident from the schema's null default. The end parameter, however, is never mentioned, leaving a gap.

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 resource (bank holidays) scoped to a specific entity (a financial centre identified by UN/LOCODE) and defines it precisely as 'days retail and commercial banks are closed'. That scoping phrase meaningfully separates it from siblings like settlement_holidays, trading_holidays, and fx_market_holidays, though no 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?

Usage is implied by the domain definition: use this when you need the days banks are shut in a financial centre. However, there is no explicit when-to-use or when-not-to-use guidance, and the agent is left to infer the choice against the many holiday-related siblings on its own.

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 behavioral burden and succeeds in explaining the counting convention, the intersection rule across calendars, and that non-business days are returned with reasons. It does not cover edge cases such as reversed date ranges or output structure in detail, but the core behavior is well disclosed.

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 core counting convention and then adds only the calendar semantics and examples needed to invoke the tool correctly. Every sentence and example 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 three-parameter calculation tool with no annotations or output schema, the description covers the essential semantics: date boundaries, calendar selection, and multi-calendar intersection. It could be slightly more complete about return shape or error handling, but it is adequate to 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 description coverage is 0%, so the description must compensate. It adds substantial meaning for calendars, including where to get valid codes, multiple examples, and the rule that a date must be open in every calendar; it also clarifies the start/end boundary convention.

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 operation: counting business days between two dates, with a precise inclusive/exclusive convention and the calendar-intersection rule. It clearly distinguishes itself from related siblings such as add_business_days and is_business_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 explains how to choose calendars, points to list_calendars for valid calendar codes, and gives concrete examples for FX, NYSE settlement, euro payments, and London banks. It does not explicitly say when to prefer a sibling tool, but the intended use case is clear.

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 supplied, so the description carries the full behavioral burden; it does disclose the notable default that start falls back to today, which is real behavioral value. It omits what the response contains (list of dates? count?), what happens when end is omitted, and any timezone or weekend-inclusion semantics for a tool whose whole output is date semantics.

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?

Three short sentences, each with a distinct job: define the resource, give the use case, state the default. Nothing is padded and the most important identification detail (ISO 4217 / non-clearing) is front-loaded.

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 lookup with no output schema, an agent still does not know what comes back (dates, count, calendar objects) or the exact scope of "non-clearing" (weekends included? currency-specific holidays only?). The core identity and default are covered, but the return-shape gap is a meaningful omission for a tool this small.

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; it explains currency as an ISO 4217 code with an example and clarifies the start default behavior beyond the schema's null default. The end parameter receives no explanation at all, and date format expectations beyond the schema's format field are not addressed.

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 resource with a definition ("days the currency cannot clear or settle") and scopes it to ISO 4217 currency codes, which clearly separates it from date-arithmetic siblings like add_business_days. However, it never distinguishes this from close siblings such as settlement_holidays, bank_holidays, or fx_market_holidays, so an agent cannot route between them on the description 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?

"Use to validate FX value dates" gives one concrete usage context, which is genuine guidance rather than nothing. It provides no when-not conditions and does not name any sibling as the alternative for overlapping queries (settlement vs. bank vs. FX market holidays), leaving the selection decision 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?

No annotations are supplied, so the description bears the full burden. It usefully discloses the default behavior for start (today) and clarifies what a returned day represents, but says nothing about the response shape, whether the date range is inclusive, behavior for invalid/non-convertible currency codes, or limits on range size.

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 tight sentences with the core concept front-loaded and the default-value note appended where it belongs. The parenthetical currency example earns its place; only minor trimming would be possible.

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 and no annotations, the description has to carry everything. It covers the required currency parameter and the start default adequately, but leaves the end parameter and the returned structure entirely to inference, which is a real gap for a date-range query 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 0%, so the description must compensate. It does document currency (ISO 4217, with a USD example) and start's default, but the end parameter is never explained (inclusivity, format, or default open-endedness), leaving a third of the parameters undocumented in both places.

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 resource (FX market holidays) with a clear scope qualifier: for a given currency, defined as days that currency's FX market does not trade. This meaningfully separates it from bank_holidays, settlement_holidays, and trading_holidays, 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?

Usage is implied by the resource definition (ask for FX-market-specific non-trading days per currency), but there is no explicit guidance on when to prefer this over sibling tools like trading_holidays or bank_holidays, and no stated exclusions or prerequisites.

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 supplied, so the description carries the full behavioral burden. It usefully discloses the default start behavior and the shape of returned rows (original_date for shifted observances, half-day and early-close details), which is valuable given there is no output schema. However, it says nothing about error behavior for invalid calendar codes, whether results are bounded or paginated, or the read-only nature implied by a lookup.

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?

Three tightly packed sentences with the resource stated first, then parameter behavior, then return shape. No filler or restatement of the name. The middle clause about historical and forward dates is compressed but still parseable.

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 three simple parameters, no annotations, and no output schema, the description covers the essentials, including return-field semantics that would otherwise be invisible. It falls short on invalid-code handling and on routing among the numerous holiday siblings, which for a tool in this dense a family is a real 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 0%, so the description must compensate and it largely does: calendar is a code with a worked example, start is a date with a documented default of today and a historical-range use case, and end delineates a forward bound. All three parameters gain meaning beyond their bare type/format declarations.

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 concrete resource (holidays) scoped to a single calendar identified by a code, with a concrete example (USD.FX). It does not explicitly distinguish itself from siblings such as bank_holidays, fx_market_holidays, or settlement_holidays, so an agent must infer that this is the generic per-calendar variant.

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?

Guidance is present but parameter-oriented: it explains that start defaults to today and that an earlier start or an end bound is used for historical or forward ranges. There is no explicit statement of when to choose this tool over the many holiday-related siblings, and no reference to list_calendars for discovering valid codes.

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 does useful work by explaining the shape of the response (weekend_days vs weekend_definitions with full history), but it never states whether this is a read-only lookup, what happens with an invalid calendar code, or how large the history payload may be.

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 tight sentences with no filler; the core capability is front-loaded and the return-field explanation follows immediately. Nothing is repeated from the 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 no output schema and no parameter descriptions, the description steps in to explain the two returned fields and their temporal scope, which is the key ambiguity for this tool. It falls short only on operational details (read-only nature, error behavior, code discovery).

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% and the single parameter has no description, so the description must compensate — and it does, supplying an example value format ('USD.FX') and indicating that exactly one calendar code is expected. It does not point to a way to enumerate valid codes, which would have made it a 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 the resource precisely: weekend definitions and working weekends scoped to a single calendar code, with a concrete example format (USD.FX). The distinction from holiday-oriented siblings is implicit in the resource name, but no 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?

Usage is implied by the resource being retrieved — an agent would reach for this when it needs weekend structure for a calendar code. There is no explicit when-not guidance and no pointer to alternatives such as get_holidays or list_calendars for discovering valid codes.

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 burden and does disclose the response content: a boolean plus the reason (holiday name, weekend) and half-day/early-close flags. It also states the important aggregation rule that a date is a business day only if open in every calendar given. It omits error behavior for unknown calendar codes and any timezone/date-boundary handling.

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 core question and the aggregation rule are front-loaded, and every sentence carries information. The dense run of four bracketed calendar examples in one sentence is useful but makes the description heavier than it needs to be.

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 boolean-check tool with no output schema, the description covers inputs, semantics, and the shape of the answer (reason strings, half-day flags). A little more on the exact return fields or handling of invalid codes would make it complete.

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 supply all meaning, and it does: calendars are calendar codes with real examples and AND-semantics across the list, and date is yyyy-mm-dd defaulting to today. The cross-calendar conjunction rule is genuinely new information not present anywhere 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?

The opening question states a specific verb (check) and resource (business day) and immediately scopes it to one or several calendars. It is clearly distinguishable from siblings like business_days_between (a count) and add_business_days (a shift), since this returns a yes/no plus reasons.

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 calendar examples (USD.FX/EUR.FX for a EUR/USD trade, XNYS.SETTLE for NYSE settlement, TARGET2.PAY for euro payments, GBLON.BANK for London banks) give concrete selection guidance and point to list_calendars for codes. It stops short of explicitly saying when to prefer this over siblings such as business_days_between or market_status.

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 supplied, so the description carries the full burden. It does disclose a genuine behavioral trait — results are gated by the caller's plan/subscription — and 'List' implies a read-only operation, but it says nothing about result shape, whether entries carry identifiers usable with get_holidays, or ordering.

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 sentences, front-loaded with the action and scope, with the filter detail second. The enum enumeration is long but carries meaning; it does partly restate the schema enum, which keeps this 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?

For a one-parameter, read-only discovery tool with no annotations and no output schema, the description covers what the tool does and the filter, but leaves the return contract entirely implicit. An agent cannot tell from the text what a 'calendar' object contains or how to chain into get_holidays.

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 0%, so the description must compensate, and it partially does: it identifies the single parameter as an optional family filter and glosses each enum value as a calendar family. It does not explain the effect of omitting the parameter or how the families relate to the sibling tools that consume them.

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 ('List published holiday calendars') and adds a scoping condition ('available to your plan') that no sibling states. It stops short of naming how it differs from adjacent discovery tools such as list_financial_centres or list_exchanges, which enumerate members of the same families.

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 'Optional calendar_type filters by family', which tells the agent the filter is optional and what it narrows. There is no explicit statement of when to call this versus the sibling list_* tools, nor what the default (unfiltered) call returns.

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. The word 'covered' usefully signals that the list is scoped to the service's supported set rather than all ISO 4217 codes, but nothing states whether results are paginated, ordered, cached, or whether the list can change over time. For a zero-parameter read tool the risk is low, but the disclosure is thin.

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?

One sentence, front-loaded with the verb and resource, with the parenthetical standard and the returned fields compactly appended. Nothing is redundant and nothing is missing that would need to be said first.

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 zero-param, annotation-free list tool with no output schema, the description covers the essentials: what is listed, the code standard, and the fields returned. Only the exhaustiveness/ordering of the result set is left undefined, a minor gap given the tool's simplicity.

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 takes zero parameters, so there is no parameter meaning to add; the baseline for a no-param schema applies. The description does spend its words on output fields instead, which is the right use of space.

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?

A specific verb plus resource ('List covered currencies') with the ISO 4217 standard named and the returned fields enumerated (issuing country and issuer). An agent can immediately tell this is an enumeration of supported currencies rather than a lookup or conversion tool, and it is clearly distinct from the calendar/exchange/centre siblings. It stops short of explicitly contrasting with any sibling, which keeps it at 4.

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 no explicit when-to-use or when-not-to-use statement, but the purpose is narrow enough that usage is implied: call it to discover which currencies the dataset covers, e.g. before querying currency_non_clearing_days. No prerequisites or alternative routing are mentioned.

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 burden; it does disclose that only 'covered' exchanges are returned and names the fields in the payload, which is useful. It stops short of saying whether the result is a full static reference set, whether coverage varies by data subscription, or anything about ordering or pagination.

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 identifying detail (MIC standard, returned fields) arrives immediately.

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 zero-argument reference-list tool with no output schema, the description covers the resource, the identifier standard, and the notable returned attributes. Only the scope of 'covered' and result size remain unspecified, which is a minor gap at this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline of 4 applies. The mention of ISO 10383 MIC gives context for the returned identifiers rather than adding 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?

The description states a specific verb and resource ('List covered exchanges') and pins down the identifier standard (ISO 10383 MIC) plus the attributes returned (country, city, timezone). That is enough to distinguish it from siblings like list_financial_centres or list_calendars, though it never explicitly contrasts itself with them.

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 no statement of when to use this versus the many sibling reference-list tools (list_currencies, list_calendars, list_financial_centres), nor any prerequisites or exclusions. Use is only implied by the phrase 'covered exchanges'.

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 supplied, so the description carries the disclosure burden alone. It makes clear this is a read-only enumeration and identifies what each entry contains (code, country, timezone), but does not state that the list is static/authoritative, mention ordering, or confirm no side effects.

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 returned fields are bundled compactly in parentheses. Nothing could be removed 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?

With no output schema, the description must carry return-value expectations, and it does so only at a field-name level, giving no sense of scale (how many centres), format, or whether the codes are the keys used by sibling tools such as get_holidays or market_status. For a simple lookup this is adequate but leaves a real integration 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for zero-parameter tools applies. The description correctly adds no parameter narrative that would be redundant.

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 ("List covered financial centres") and names the identifying standard and returned fields (UN/LOCODE, country, timezone). It is clearly distinguishable from siblings like list_currencies or list_exchanges, though the word "covered" is left unexplained as to what universe of centres is covered.

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 no explicit when-to-use, when-not-to-use, or named alternative. Usage is only implied by the enumeration nature of a zero-parameter list tool: an agent can infer it is a lookup of supported centre codes, but nothing tells it whether other tools in the family expect these codes.

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 supplied, the description carries the full behavioral burden. 'List' correctly signals a non-mutating read and the description discloses the returned fields, but it says nothing about whether this is static reference data, how results are ordered, or whether any permissions/filters apply. Adequate but thin for a tool with zero annotation coverage.

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: verb, resource, and the salient returned attributes. Nothing could be removed 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?

For a no-argument reference-list tool with no output schema, the description is nearly sufficient because it names the exact fields returned. The remaining gap is ordering/completeness of the 'covered' set, which an agent might want to know but can discover from the response.

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 takes zero parameters, so there is no parameter meaning for the description to add and the baseline of 4 applies. The field enumeration in the description instead supports interpretation of results rather than 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 gives a specific verb ('List') and resource ('covered payment systems') and enumerates the returned attributes (operator, type, currency, country), so an agent immediately knows what this tool produces. It stops short of explicitly distinguishing itself from near-neighbours such as list_currencies or list_exchanges, but the domain noun is distinctive enough to avoid real confusion.

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 no when-to-use guidance at all: no indication of when an agent should reach for payment systems versus list_currencies, list_exchanges, or list_financial_centres, and no mention of prerequisites or output ordering. The word 'covered' hints at a bounded reference set but never explains what coverage means or when that matters.

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 behavioral burden and does well: it explains that status is evaluated against real trading hours and today's holidays in each exchange's timezone, lists the next_open_at/next_close_at fields, and notes the plan requirement. It omits rate-limit/error behavior and full response shape.

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 sentences, front-loaded with the core purpose, then behavior, parameter usage, and prerequisite. No repetition or 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 one-parameter status tool with no annotations or output schema, the description covers purpose, evaluation logic, key return timestamps, and access prerequisite. It could be slightly more complete about the full response shape, but it is sufficient 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?

The single schema parameter is undocumented in the schema, but the description fully supplies its meaning: a MIC code such as XNYS, optional, and omitting it returns all markets. That is exactly the missing semantic context.

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 first sentence names a specific resource (exchanges) and a specific status output (live open/half/closed), and situates it against real trading hours, holidays, and timezone. That is enough to separate it from sibling holiday/calendar tools such as trading_holidays or list_exchanges.

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 actionable scoping instructions—MIC for one market, omit for all—and states the plan prerequisite. It does not explicitly name when to prefer it over siblings or when not to use it, so it falls 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?

No annotations exist, so the description carries the full burden. It usefully notes that start resolves to today when omitted (which the schema does not reveal, since its default is null), but it says nothing about what happens when end is null, whether an empty list is returned, or how results are shaped — for a read of holiday data with no annotation coverage, that leaves the agent guessing.

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, front-loaded with the domain definition and appended with the one behavioral default. Nothing is padded, though the phrasing is clipped enough that the missing operation verb and value guidance aren't merely trimmed for brevity.

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 three parameters, zero schema description coverage, no annotations and no output schema, the definition should at minimum name the accepted payment systems and describe the returned interval. It only covers one default, so an agent cannot call this reliably without trial and error.

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. It explains the start default, but adds nothing about which payment_system values are accepted (no enum, no pointer to list_payment_systems) and nothing about the meaning or bounds of end.

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 defines the resource concretely ("Payment system holidays (e.g. TARGET2, FEDWIRE): days the system does not process or settle"), and the named examples implicitly separate it from sibling tools like bank_holidays, trading_holidays and fx_market_holidays. It never states an explicit verb such as "list" or "return", so the operation is inferable rather than declared.

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 parenthetical examples of payment systems imply the domain of use and thereby partially disambiguate it from the many holiday-family siblings. However, there is no explicit statement of when to prefer this over bank_holidays or settlement_holidays, and no prerequisites or exclusions are given.

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 the important default that start defaults to today and clarifies that returned days are those on which clearing and settlement cannot take place, but it does not describe return format, end-date behavior, timezone handling, or whether this is a read-only lookup.

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 compact and front-loaded: purpose first, then the market identifier format, then the start default. Every clause adds useful information, though the opening noun phrase could be slightly more verb-forward for scanning.

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 lookup with no output schema and no annotations, the description covers the core concept, market format, and start default. It is incomplete because it says nothing about the end parameter or the response shape, which are left entirely to inference.

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. It adds meaningful semantics for the market parameter by specifying ISO 10383 MIC format with an XNYS example, and it documents that start defaults to today. However, the end parameter is not described at all, leaving one of three parameters undocumented.

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 identifies the resource as exchange settlement holidays scoped to a market and explains what those holidays mean. It is distinguishable from siblings like trading_holidays or bank_holidays by specifying clearing and settlement, though it does not explicitly name or contrast those alternatives.

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 purpose implies when to use this tool rather than alternatives such as trading_holidays or bank_holidays, but there is no explicit when-to-use or when-not-to-use guidance. The note that start defaults to today is a useful usage detail, but sibling differentiation remains 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?

With no annotations, the description carries the full burden, and it does disclose that shortened sessions are returned with half_day and early_close_time fields plus the 'start defaults to today' behavior. It does not say whether 'end' is inclusive, whether results are sorted, how many entries are returned, or what happens with an unknown MIC.

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 dense sentence with the market identifier and the default behavior front-loaded; nothing is wasted. The parenthetical list of return fields is slightly awkward but earns its place by describing output.

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 read-only lookup with no output schema, the description covers the core semantics and one return field group, which is close to sufficient. However, the undocumented 'end' parameter and the absence of any note on timezone or range inclusivity leave real gaps for an agent constructing a query.

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 0%, so the description must compensate: it explains the 'market' format (ISO 10383 MIC, e.g. XNYS) and the default for 'start'. The 'end' parameter is never mentioned, so a third of the parameters remain completely undocumented.

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 ('Exchange trading holidays for a market') and pins the market identifier to ISO 10383 MIC with an example (XNYS). The scope ('days the exchange is closed for trading') implicitly separates it from bank_holidays or settlement_holidays, but 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?

Usage is only implied by the phrase 'days the exchange is closed for trading'; there is no explicit statement of when to pick this over bank_holidays, settlement_holidays, or get_holidays. No prerequisites or exclusions are given.

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