banking-intelligence

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

Annotations only declare readOnlyHint/openWorldHint, yet the description discloses a great deal beyond that: the payment_impact section shape, the two-part rule for a recent holiday counting, the meaning of an empty list, the costs_a_business_day flag caveat, and that elapsed_business_days_by_send_date is authoritative. This is unusually rich behavioral context.

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 the bulleted return-value breakdown keeps a long description scannable. The length is largely earned by the payment-delay diagnostic rules, though a few clauses (e.g. repeated warnings about inventing holidays) could be tightened.

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 whose output schema already exists, the description supplies everything an agent needs to interpret and safely act on the result, including how to reason about holiday-caused delays and the authoritative business-day count.

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

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

Schema description coverage is 100%, so both country_code and the year range/clamping behavior are already documented in the schema. The examples (bank_holidays("US"), bank_holidays("DE", 2026)) only illustrate call shape and add no semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Get bank/public holidays for a country') and adds the differentiating scope ('with payment impact analysis'), which separates it from siblings like is_business_day_check and value_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?

Explicitly frames the use case: diagnosing a payment that is ALREADY stuck, plus checking whether today is a business day and upcoming/recent holidays. Strong context, but it never names the alternative sibling tools an agent should prefer for the narrower business-day or value-date questions.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses the narrowed return shape ('only swift + name per bank'), the subscription requirement (PRO, VIP, or FI API key), the mandatory-parameter rejection behavior, and the paging bound of 1-4. This is exactly the behavioral context annotations cannot carry.

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 purpose, then layered detail and examples. Slightly long, and the 'Country and currency are required (not optional)' line partly restates the schema's required array, but the reason given (bounding the result set) 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?

Despite an output schema existing, the description usefully summarizes the return shape and routes the agent to ssi_lookup for detail. Auth tier, required params, and pagination limits are all covered, leaving nothing an agent needs missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real value on top: it explains why country and currency are required (they bound the result set) and supplies worked examples showing correspondent_swift, currency, country, and name_prefix combined.

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 and scope: 'Reverse SSI lookup — find banks that use a given correspondent for a currency.' It explicitly names its sibling relationship ('Inverse of ssi_lookup'), letting an agent distinguish it from ssi_lookup without opening either 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?

States the exact when-to-use case, the mandatory inputs, and the explicit follow-up path: call ssi_lookup(bank_swift, currency) on a result to get account numbers or intermediary chains. Exclusions are covered by the required country/currency constraint and the 'query is rejected without them' note.

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 only declare readOnly and openWorld=false; the description adds substantial behavioral context beyond them: no API key required, the list is LIVE and outranks the sibling tool descriptions, and — critically — that an unregistered jurisdiction returns empty with a 'completed' status that does not mean the company is unregistered. That failure-mode disclosure directly prevents a misread of results.

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 experimental marker and the core purpose, then the precedence rule and fallback semantics. Every sentence carries information, though the trailing 'Examples: company_registries()' block is redundant for a zero-parameter 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?

An output schema exists, so return values need no explanation here. Given a zero-param, read-only list tool, the description supplies everything an agent needs: what it returns, why it matters relative to siblings, and how to interpret empty results.

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 the baseline is 4. The description correctly shows the no-argument call form rather than implying any input is needed, and the schema is fully documented.

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 available company registries and supported jurisdictions') and distinguishes the tool from its siblings by declaring itself the authoritative source that 'outranks the codes named in those two tools' descriptions.' An agent can identify this 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?

Explains the context clearly: it is the live list to consult for jurisdiction codes used by company_search_person and company_search_company, and it specifies the fallback ('XX' GLEIF LEI) for unlisted codes. It does not explicitly say 'call this first' as a sequencing instruction, but the precedence rule makes the use case unambiguous.

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

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

Goes well beyond the annotations by disclosing the backend's silent-drop failure mode: an unsupported jurisdiction returns total_results 0 with status 'completed' and no error, plus the explicit instruction to check jurisdictions_not_searched and coverage_warning before reporting an empty result. It also discloses the automatic sanctions screening and what GLEIF hits contain. Annotations only supply openWorldHint=true; the description carries the meaningful operational risk. One minor gap: it never explains the readOnlyHint=false annotation on what is plainly a read-only search.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the EXPERIMENTAL flag, the mandatory jurisdiction constraint, and the damaging-false-negative warning, which is the right ordering. The prose is dense but a few facts (jurisdiction list, ALL unsupported, XX meaning) are repeated from the schema and the two trailing paragraphs on XX are longer than strictly needed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description still names the response fields that matter for interpretation (jurisdictions_not_searched, coverage_warning), which is exactly the value-add a description should provide. Combined with the jurisdiction semantics, screening behavior, and worked examples, an agent has everything needed to call it correctly and interpret the result honestly.

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, and the description partly restates schema content (UK not GB, XX is GLEIF, ALL unsupported). It earns the extra point by adding rationale the schema lacks — when to reach for XX rather than a national registry — and by showing concrete invocation examples with jurisdictions and include_only_active.

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 ('Search company registries for a company with its officers and shareholders') and immediately separates itself from siblings like company_search_person and company_search_result by scoping to the company entity plus its officers/PSC data. An agent can select it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use rules (at least one jurisdiction required, 'ALL' unsupported), names the alternative for the live jurisdiction list (company_registries()), and explains the exact scenario that selects the XX/GLEIF jurisdiction (company outside national registries: Hong Kong, China, US, UAE). This is routing guidance an agent can act on directly.

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?

Adds substantial behavior beyond the annotations: automatic sanctions screening, the silent-drop failure mode, and the recommendation to inspect jurisdictions_not_searched and coverage_warning. However, the api_key schema explicitly defers key requirements to 'its description,' and the description never explains them, and nothing accounts for the non-readOnly/non-idempotent annotations on what is presented as 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?

Front-loaded with the capability and the hard constraint, and the examples at the end are useful rather than filler. The inline jurisdiction list is long and somewhat duplicative given the pointer to company_registries(), but it is defensible as a stale-prone fallback.

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-required-param search with an output schema, the description covers invocation constraints and the main failure mode well. The one real hole is API-key requirement detail, which the schema explicitly delegates to this description but it never provides.

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 baseline is 3, but the description supplies meaning the schema does not: the consequence of an unsupported code, the distinction between national registries and the global GLEIF entry, and the empty-result interpretation. The include_inactive_roles and include_sanctions_check defaults are only restated from the schema, not extended.

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 ('Search company registries for a person's directorships, officer roles, and shareholdings') and scopes it to person-level results, which clearly separates it from the sibling company_search_company. Nothing is left ambiguous about what is being found or whose roles are returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit usage constraints: at least one jurisdiction required, 'ALL' unsupported, the exact supported code list, the instruction to call company_registries() for a live list, and what XX/GLEIF is for. It also names the failure condition (off-list jurisdiction is silently dropped) and tells the agent not to treat that as a negative finding.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the results are cached, this avoids re-running a search, and the tool is EXPERIMENTAL. It stops short of stating cache lifetime or whether results can go stale, which is the main unaddressed trait.

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 purpose, followed by a short mechanism explanation and a compact example. Tighter than most; the example is mildly redundant with the already-explicit search_id wording but not wasteful.

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 no prose, and annotations cover the safety profile. The description supplies the retrieval workflow and its precondition, leaving only edge cases (expired search_id, retention window) unstated — minor for a two-parameter read tool.

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

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

Schema description coverage is 100% — the search_id parameter is already documented as coming from a prior search call, and api_key documents its own header alternatives. The description restates the search_id origin without adding format, validity, or expiry details, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Retrieve cached company search results by search ID.' It explicitly names the siblings that produce the search_id (company_search_person, company_search_company), so an agent can immediately distinguish cached retrieval from running a new search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear when-to-use: retrieve prior results again 'without re-running the search,' and explains the precondition (a search_id from a prior search call). It does not state when NOT to use it (e.g. expired/unavailable search IDs), but the routing context is unambiguous.

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 only cover readOnly/openWorld, but the description adds real behavioral semantics: the fatf_listing block is authoritative, a not_listed result is a positive determination rather than missing data, the coarse fatf field is a separate weaker signal, and currency is country-level and must not be used to diagnose account mismatches. These are non-obvious disclosure traits that go well 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?

Well front-loaded with the core purpose and return contents first, then scoping/warning notes, then examples. Every section is substantive, though the total length is on the heavy side for a one-parameter lookup, with some output-interpretation material that could be trimmed.

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, yet the description still clarifies the interpretation of key fields (fatf_listing vs. fatf, currency). Combined with readOnly annotations and a trivial single-param schema, an agent has everything needed to select and call this 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?

With a single parameter fully documented in the schema (ISO 3166-1 alpha-2), the schema does the heavy lifting. The description adds marginal value through concrete invocations that illustrate what different codes yield ("KZ" includes KNP, "AE" includes Purpose of Payment), reinforcing the parameter's role beyond the schema's generic example.

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 ("Get banking rules and requirements for a country") and enumerates exactly what comes back: IBAN requirements, SEPA membership, FATF status, national currency, account formats, payment requirements. It also explicitly distinguishes itself from the sibling country_payment_codes, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ("check country-specific STP rules that could cause payment delays, repairs, or rejections"), an explicit alternative for code lookup ("Use country_payment_codes to look up specific code values"), and an explicit substitution instruction for FATF questions ("Use it instead of training data"). It also includes a when-not usage warning about pairing currency with the payment currency.

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 only say readOnly/openWorld=false; the description adds the critical domain behavior that jurisdiction controls bind only with a nexus, and that each response carries a payment_jurisdiction_note explaining applicability. That is genuine behavioral context an agent cannot get from the annotations or 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?

Well front-loaded: purpose, returns, then the nexus caveat, then examples. The IMPORTANT paragraph restates the payment_jurisdiction_note point already made one sentence earlier, and the four example lines are somewhat redundant, so it is slightly longer than strictly needed.

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 with an output schema already declaring return shape, the description supplies everything else an agent needs: scoping semantics, the nexus rule, filter usage, and worked examples. Nothing material 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 goes beyond the schema by explaining when to supply jurisdiction (only when you know the payment's actual touchpoints) and by giving multi-example invocations including the two-argument form. The added semantics justify a 4.

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 ('Look up export control restrictions for a specific country') and enumerates the returned data (embargo status, sanctioned programs, control reasons, jurisdictions). It never names the closest sibling, export_controls_screen, so an agent cannot rule that tool out from this 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?

Gives a clear when-to-use trigger ('What export restrictions apply to shipping to Russia?'), a parameter-selection rule for the jurisdiction filter, and an explicit when-not ('do NOT cite US controls without confirming a US nexus'). It stops short of routing between this and sibling tools like export_controls_screen or sanctions_screen.

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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: omitting the search filter returns the entire table and is flagged as a large response, and the dependency on country_banking_rules output is disclosed. No auth/rate-limit detail, but little is missing for 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?

Front-loaded one-line purpose, then a short workflow note, then examples. The phrase "which is a large response" is duplicated from the schema description, a minor redundancy, but every block otherwise 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?

An output schema exists so return values need not be explained. Purpose, workflow ordering, parameter usage and the large-response caveat are all present, leaving nothing an agent needs to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The example calls add value beyond the schema by mapping real keywords ("transport", "insurance", "trade") onto the optional search parameter and showing the required argument order, which helps an agent construct a correct invocation.

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 (look up) and resource (country-specific payment codes) with concrete examples of code types (KNP, purpose codes). It also distinguishes itself from the sibling country_banking_rules by positioning itself as the second step in that workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call country_banking_rules first to discover which code types a country requires (payment_requirements block), then use this tool to resolve values. This is a clear when-to-use and how-it-relates-to-alternatives statement, and the examples show concrete invocations.

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 and openWorldHint=false, so the safety profile is covered. The description adds that it is a pure reference lookup returning classification details, controlled jurisdictions, and license requirements, which clarifies determinism and scope. It does not disclose error behavior for unknown or malformed ECCNs.

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, followed by return scope and examples. The ECCN background paragraph and three examples are somewhat verbose for a one-parameter lookup, but each line is informative and scannable.

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 an output schema, the description supplies enough context: what an ECCN is, what the call returns, and representative inputs. The main gap is the absence of any pointer to sibling tools for related tasks (screening, HS classification).

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 single parameter is fully described, including case-insensitivity, so the schema does the heavy lifting. The description's example codes reinforce but do not extend the schema's meaning beyond it.

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 (look up) and resource (ECCN) and defines what an ECCN is, so an agent understands the domain immediately. However, it never distinguishes itself from close siblings like hs_code_lookup, goods_classify, country_export_controls, or export_controls_screen, so sibling routing is left to inference.

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?

"Pure reference tool" implies this is a static lookup rather than a screening action, which is weak implicit guidance against using export_controls_screen or sanctions_screen. There is no explicit when-to-use/when-not-to-use statement or named alternative, so usage must be inferred from the domain framing.

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 declare readOnlyHint=true and openWorldHint=false, and the description adds real value beyond them: it warns that goods_description is matched lexically and typically returns the wrong HS code, tells the agent to read classification_basis / classification_confidence_note and never quote an inferred code back to the user, and clarifies that destination findings (embargo, transshipment risk, screening duties) are unaffected by that doubt. That is precisely the kind of failure-mode and output-interpretation context annotations cannot carry.

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 purpose, then the two IMPORTANT blocks and worked examples, each earning its place for a non-trivial compliance tool. Slightly redundant — the 'provide at least one of' rule is stated both in prose and again in every schema field — and the block layout is dense, but there is 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 tool with an output schema, this description supplies everything else the agent needs: how to identify goods, how to select jurisdiction, what the fallback path implies, and five concrete invocation examples spanning eccn, hs_code, free-text, and ALL-jurisdiction calls. Nothing required 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 coverage is 100%, so baseline is 3, but the description meaningfully exceeds the schema: it ranks the three identification parameters (eccn/hs_code preferred, goods_description a fallback), explains the lexical-matching weakness of goods_description, and gives real substance to jurisdiction via the nexus rule (US EAR binds US persons/USD-clearing/US-origin; EU/UK/JP bind their persons, currencies, origin) — none of which appears 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 description opens with a specific verb+resource+scope: 'Screen goods for export-control restrictions to a destination country,' then names the exact combination it performs (goods classification × destination restriction status). It is clearly distinguishable from siblings like eccn_lookup, goods_classify, hs_code_lookup, country_export_controls, and sanctions_screen, which each cover only one half of that combination.

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?

Strong internal guidance: 'Provide at least one of eccn / hs_code / goods_description,' 'prefer eccn or hs_code,' and a detailed rule for choosing jurisdiction ('ALL' for multi-jurisdiction, or the one matching actual touchpoints). It does not, however, explicitly route the agent away from siblings (e.g. when to call eccn_lookup or goods_classify instead), which is the only gap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered structurally. The description adds the nature of returned content (entity list updates, rule changes, sanctions programs) but says nothing about ordering, freshness, pagination, or truncation behavior beyond the limit param. With annotations carrying the safety profile, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose, then a content list, then compact examples with inline comments. Nothing is redundant and each block 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 an output schema present, the description needn't explain return values, and annotations cover read-only/open-world semantics while the schema covers all five parameters. The definition is essentially complete for a read-only filtered feed; only freshness/ordering context is absent.

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 every parameter is already documented in the schema (ranges, enums-as-strings, defaults). The description only illustrates parameter combinations through examples, adding no syntax or constraint detail beyond what the schema provides. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (get recent US regulatory changes from BIS and OFAC) and enumerates the content returned (entity list updates, rule changes, country policy shifts, new sanctions programs). This clearly separates it from sibling screening tools like sanctions_screen or export_controls_screen, though it never names a sibling 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?

Three concrete invocation examples plus an explicit use case ('Any new entity list additions affecting China?') give clear context for when to reach for this tool. It stops short of stating when NOT to use it or naming an alternative (e.g. sanctions_screen for checking a specific party).

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 only declare readOnly/openWorld, but the description discloses provenance semantics ('ecb' vs 'market', never call market data 'the ECB rate'), coverage limits (~60 currencies, CLP/COP/PEN absent), the exact error behavior on a missing leg, and that cross-rates via EUR are indicative and not executable. This is rich behavioral context well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in the first sentence, then layers provenance, coverage, and error handling. It is dense but earns most of its length; the 'source'/'source_note' guidance is slightly repetitive and could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required, and the description still calls out the result fields that matter for provenance. Combined with coverage caveats, cross-rate mechanics, and error behavior, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100% and the schema already documents base/target and quote orientation, so baseline is 3. The description adds meaningful semantics on top: both params mandatory, no implicit default, mis-named currencies produce a 'missing required argument' error rather than a silently-wrong rate, plus worked examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource: 'Get the latest available reference (mid-market) exchange rate for a pair.' It also carves out a clear niche against siblings like fx_rate_history, fx_volatility and fx_timing_advisor by emphasizing the latest single snapshot. An agent can distinguish it without opening another 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?

Strong when-to-use guidance: BOTH currencies required, no implicit default pair, never assume EUR/USD, and what to do when a leg is uncovered (relay that no rate is held rather than inventing one). It does not, however, name a sibling alternative (e.g. fx_rate_history for past rates), so it stops short of explicit routing.

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 only declare readOnlyHint and openWorldHint; the description carries substantial extra behaviour: the source field's 'ecb' vs 'market' semantics and which currencies fall under each, series_coverage.truncated logic, peg_context and third-currency anchors, and error-on-uncovered-pair instead of an empty series. This is exactly the kind of context annotations cannot 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 long but front-loads purpose then outputs, and nearly every sentence conveys a distinct constraint (provenance, truncation, pegs, errors, required params, examples). The shouting-capital directives are slightly verbose, but the density is justified by the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description supplies the interpretive layer the schema cannot: how to report coverage honestly, how to attribute each source, and how to handle pegged or uncovered pairs. Nothing an agent needs to call and correctly describe the result 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 adds real meaning beyond it: it reinforces that days is a ceiling rather than a promise with a concrete illustration ('a 365-day request routinely returns five months'), and stresses that both currencies must be passed exactly with no implicit EUR/USD default. That is genuine added value over 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?

The opening sentence names a specific verb and resource — retrieve the historical reference exchange-rate series for a currency pair — which cleanly separates it from the sibling fx_rate (current rate). An agent can identify the tool's function 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 gives strong in-scope guidance (how to characterise the period, how to attribute provenance, how to report uncovered pairs) but never routes the agent to or away from siblings such as fx_rate or fx_volatility, and states no explicit 'when not to use this tool' condition. Clear context, missing the alternative comparison.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context – that output carries an inbound_processing_note for restricted currencies and that hold durations are explicitly not in the data – but it does not describe the shape of the session/liquidity windows returned beyond naming them. Solid additive context on top of annotations, not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose then bullets the two usage modes; the caveat block is long but every sentence carries a real instruction (what not to say, which tool to call instead). The trailing Examples block is somewhat redundant with the schema's ordering semantics, keeping it just short of maximal.

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 no explanation, and the description covers purpose, both call modes, the safety caveat, the escalation path to country_banking_rules, and the inbound_processing_note. Nothing an agent needs to invoke or interpret this correctly is missing.

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

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

Schema coverage is 100% and the single optional parameter is already documented, so the baseline is 3. The description goes slightly beyond by spelling out the two call modes' outcomes ('optimal window' when passing a code vs 'all market sessions and overlap windows' when omitting) and gives concrete examples (EUR, JPY, INR).

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 ('Get FX trading windows... Returns market sessions and liquidity windows for a currency') and clearly differentiates itself from siblings like fx_rate, fx_volatility, and payment_cutoff_times by scoping to session/liquidity timing. An agent can route to it 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?

Explicitly names the primary reliable use (rate/spread optimization) and a use-with-care case (delay diagnosis), then redirects to a named alternative (country_banking_rules(destination)) for the binding delivery-side cutoff. It also tells the agent what not to claim ('held until the next session', quoted hold durations) – a rare and valuable negative constraint.

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 only declare readOnly/openWorld, so the description carries the behavioral burden and does it well: it discloses that figures are REALISED from a short history (not implied), warns about horizon.beyond_sample, states the band is future spot rather than a transactable rate, and forbids inventing forward rates in favor of relaying horizon.hedge_cost_note.

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 purpose, then usage, then guardrails, and examples land at the end. It is long, and the hedge-cost warning is somewhat repetitive, but the length is largely justified by the number of correctness rails the model must observe.

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 values need not be spelled out, and the description still covers the qualitative buckets, the horizon block contents, and the interpretation caveats. An agent has everything needed to call it correctly and report results safely.

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 already 100%, so the baseline is 3. The description goes beyond the schema by explaining horizon_days semantics — count calendar days from today to exposure end, rough estimates are fine because the band scales with sqrt(time) — which meaningfully adds to the 'accepts 1-1825' 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 (get realized FX volatility for a currency pair) plus the secondary action (size FX risk on an exposure to a future date). It clearly separates this from siblings like fx_rate, fx_rate_history and fx_timing_advisor by being the realized-volatility/bucketing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use triggers for horizon_days ('whenever the user's exposure runs past settlement'), a bulleted list of question shapes that select this path, and the negative case (omit it for spot/settlement risk only). This is about as routed as a definition gets.

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 and openWorldHint=false, yet the description adds substantive behavioral context: the matcher is lexical, confidence measures string-match strength not correctness, and unclassified results carry classification_basis and classification_confidence_note that must be read before quoting a code. That is exactly the kind of caveat annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and routing rule, then caveats, then examples. Every section earns its place, though the return-value enumeration is partly redundant given an output schema exists and adds length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter bilingual classifier, the definition covers scope, destination-agnostic boundary, matcher limitations, confidence interpretation, and fallback behavior when no HS code is supplied. Nothing needed to invoke or trust the output 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 baseline is 3; the description goes beyond it by showing the empty-description + hs_code direct-lookup pattern and noting bilingual auto-detection, which gives practical meaning to the optional parameters rather than just restating 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 (classify) and resource (goods for export control) and immediately distinguishes itself from siblings by declaring it is destination-agnostic and pointing to export_controls_screen for the license decision. Also enumerates the returned artifacts (HS code, ECCNs, control reasons, level, confidence, 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?

Explicitly names the alternative (export_controls_screen) and the condition that selects it, explains the destination-agnostic vs destination-specific split, and clarifies the hs_code lookup path. Examples cover EN, RU and direct-lookup invocation.

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 and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: mappings are richest at 6-digit level, an empty list is NOT a guarantee of being uncontrolled, and results carry confidence levels, control reasons, sensitivity, and governing regime.

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 purpose and audience, then granularity guidance, caveat, and examples. Slightly long, but each block (audience, direction, caveat, examples) earns its place and the practical caveat is well-placed.

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 annotations covering safety and an output schema covering return values, the description supplies everything else an agent needs: direction, granularity expectations, filter syntax, an explicit false-negative caveat, and a fallback tool. Nothing material 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% and an output schema exists, so the baseline is 3. The description goes beyond the schema by explaining the 4-digit vs 6-digit tradeoff (richer mappings at 6 digits) and showing jurisdiction-filtered invocation, adding real decision value.

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 direction ("Reverse-lookup an HS code → mapped ECCNs") plus the resource and output artifact. The word "reverse" and the HS→ECCN direction let an agent distinguish it from the forward-looking eccn_lookup sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the target audience, explains what an empty result means, and routes the agent to goods_classify or a formal classification when confirmation is needed. It does not explicitly contrast itself with eccn_lookup, which is the most likely sibling an agent could confuse it with, so it stops short of full when/when-not coverage.

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 only declare readOnlyHint and openWorldHint, so the description carries the semantic burden — and it does: it explains that mask violations are refused before mod-97 and reported via format_violations, and that valid:true means only the check digits pass, not that the account exists or matches the beneficiary. The currency caveat (country_currency is national, not account denomination) is critical behavioral context an annotation cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded (what it does, then the cross-check, then failure modes, then what valid means), but the emphatic all-caps assertions and repeated warnings make it longer than strictly needed for a single-parameter tool. Every paragraph is substantive, yet some points could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the description still names the key response fields an agent must interpret (resolved_institution, bank_identifier.code, is_bic_prefix, format_violations, verification_note, currency_note), so an agent can act on results and avoid the two most likely misreadings.

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

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

Schema coverage is 100% and the schema already documents whitespace/hyphen tolerance and upper-casing, so the baseline is 3. The description reinforces this with a spaced GB example that confirms normalization behavior, adding modest value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a precise verb+resource (validate an IBAN) and states the exact scope: format check, country-length check, mod-97 checksum, plus institution resolution. It distinguishes itself from neighbors like swift_lookup and country_banking_rules by explaining what it returns about the beneficiary bank versus country-level rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: 'Call this whenever the user supplies an IBAN AND names a beneficiary bank or BIC.' It also states the condition under which no institution is named (national bank/sort-code countries) and tells the agent what to quote in that case, and it points to verification_note/currency_note for follow-up.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the return shape (business-day boolean, weekend-vs-holiday reason, next business day), the presence of a `today` block, and the `date_anchor_warning` behavior with a concrete failure example. This is precisely the kind of non-obvious behavioral detail annotations cannot carry.

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 purpose, then progressively adds behavior and examples. The date-anchor digression and its parenthetical '(2025-07-20 is a Sunday, 2026-08-20 is a Thursday)' are justified by the failure mode they prevent, though the mid-sentence line wrapping makes it slightly denser than needed.

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 annotations covering the safety profile and an output schema covering the return structure, the description supplies exactly the missing pieces: the reason codes, the next-business-day field, and the date-resolution/warning semantics. An agent has everything needed to call and interpret 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 description coverage is 100%, so both parameters are already documented as ISO 8601 date and ISO 3166-1 alpha-2 code. The description only reinforces this indirectly through examples; it adds no new format, constraint, or edge-case meaning beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a precise verb+resource+scope ('Check if a specific date is a business day in a country'), and the following sentences clarify what factors into the answer (country-specific weekends, public holidays). It is unmistakable what the tool does, but it never distinguishes itself from the closely related sibling 'bank_holidays' or 'value_date', leaving the agent to infer the boundary.

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 invocation guidance rather than tool-selection guidance: resolve relative dates against the server's `today` block, and heed `date_anchor_warning` for past check_dates. That is real when-to-use-this-way context, but there is no statement of when to prefer this over 'bank_holidays' or other date/holiday siblings.

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 write/non-idempotent/openWorld, but the description adds real behavioral context: an account is created and a 6-digit code is emailed, and registration only completes via a follow-up call to mcp_verify. It goes further by spelling out the legal meaning of accept_terms. It stops short of noting duplicate-registration behavior or rate limits, so not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then the flow, then the legal clause, then a concrete example. The legal paragraph is verbose but justified for a terms-acceptance field, so most sentences 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?

An output schema exists, so return values need not be explained, and the description fully covers the multi-step registration flow and the required terms acceptance. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema for accept_terms by explaining it confirms acceptance of the Terms on behalf of the operator, citing specific sections. The inline example also clarifies positional usage.

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 ('Register for an Ohmyfin API key') with the downstream purpose ('to use paid tools'). It distinguishes itself from the sibling mcp_verify by explicitly describing the registration step versus the completion step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to call this (to obtain an API key for paid tools) and routes the agent to the next step: call mcp_verify after receiving the 6-digit code. The sequencing and the alternative tool are both named, leaving nothing to inference.

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

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

Annotations cover the safety profile (not read-only, not idempotent, open-world), so the bar is lower, but the description adds genuinely useful behavior: it returns production AND test API keys on success, and paid tools require a separate subscription. It does not say whether the code is single-use or what happens on failure.

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 line, precedence follows, and the example is compact. Slightly more prose than strictly necessary (the subscription line could be tightened), but every sentence carries usable 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 an output schema present and full param coverage, the description needn't explain return values, and it still adds the key behavioral facts (returned keys, subscription gate, prerequisite call). Complete enough for an agent to invoke correctly, missing only failure/retry behavior.

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 both parameters documented, so the schema does the heavy lifting (code = '6-digit verification code from that email'). The description adds only the worked example showing the call shape/order and no format nuances beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Verify your email and receive your API key') and ties it to a clearly named sibling flow (mcp_register), so an agent can distinguish it from the many lookup-style siblings. Scope and outcome (production and test API keys) are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the precondition and sequencing explicitly: 'After calling mcp_register, check your email for the 6-digit code and pass it here.' It also adds a separate activation condition (ohmyfin.ai/subscription) for paid tools, so the agent knows when the tool is sufficient and when extra action is needed.

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 a safe read-only, non-open-world operation. The description adds important behavior beyond annotations: DST-sensitive fields, the distinction between standard-time and summer offsets, and the instruction to quote operative_cutoff_today for the current season.

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 purpose, then adds scoped coverage, usage guidance, a critical DST caveat, and concise examples. Despite its length, every section earns its place for a domain-specific reference 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 and clear annotations, the description does not need to explain return values. It covers scope, filtering behavior, DST caveats, and examples, leaving no essential invocation detail 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 schema already documents both optional parameters. The description adds meaningful selection semantics, including what currency='EUR' returns (SEPA schemes plus T2) and what omitting system does, going beyond the schema descriptions.

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 and resource: 'Get payment system cutoff times for major clearing systems,' then lists covered systems. This is unambiguous, though it does not explicitly distinguish itself from siblings such as settlement_eta or value_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?

It provides clear usage context, especially the same-day EUR guidance and concrete call examples. It does not state when not to use the tool or name alternative sibling tools, 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 declare readOnlyHint=true and openWorldHint=false, so safety is already covered; the description usefully adds the fee-investigation workflow and that specific MT103 fields reveal each deduction. It goes beyond the annotations by disclosing the analytical process, though it does not mention input validation limits or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the when-to-use condition are front-loaded before the examples. Four examples is slightly more than needed but each demonstrates a distinct mode (SEPA, SWIFT, domestic, fee investigation), so the size is largely justified.

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 restated; the description nonetheless summarizes them (cost, speed, requirements, charge options, guidance). With only two required, fully documented params and clear annotations, the definition is effectively complete, missing only minor edge-case guidance.

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

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

Schema description coverage is 100%, so both country-code parameters are fully documented in the schema (ISO 3166-1 alpha-2). The description adds no format or edge-case detail beyond the schema, and the examples only reinforce a format the schema already states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (compare payment methods) plus a second capability (fee investigation for a country pair). It explicitly enumerates the compared options (SEPA vs SWIFT vs domestic) and the charge-option model (OUR/SHA/BEN), so an agent can distinguish it from siblings like transfer_cost or ssi_lookup without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a clear triggering condition ("use this when the beneficiary received less than expected") and four examples that map country-pair shapes to expected outputs (SEPA → SCT, non-SEPA → SWIFT, domestic → CHAPS/FPS). It lacks explicit when-not usage or named sibling alternatives, so it stops short of a 5.

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

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

With only readOnlyHint and openWorldHint annotations, the description carries the behavioral burden and does so extensively: it explains verification, adjudication, verification_gate, coverage_gate, query_match, withheld non-designation rows, false-positive handling, and reporting constraints. This goes far beyond structured fields and gives the agent the context needed to interpret results correctly.

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 the content is organized into useful paragraphs, but the description is extremely long and repeats several warnings about gates and adjudication. Much of the length is justified by a complex tool, yet it is not concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of sanctions screening, the presence of an output schema, and the critical reporting nuances, the description is highly complete. It defines return-field semantics, edge-case behavior, and action-lowering rules that an agent would otherwise misinterpret.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some practical context around subject_type and examples using threshold, but most parameter meaning is already documented in the schema itself.

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 gives a specific verb and resource: 'Screen a name against global sanctions and watchlists.' It names the sibling tool swift_lookup and the BIC-based bank screening alternative, so an agent can distinguish this tool 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 explicitly covers when to use this tool, when to prefer swift_lookup or BIC screening, and how subject_type changes behavior for banks versus parties. It also provides concrete invocation examples with threshold and api_key variations.

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 only declare readOnlyHint/openWorldHint; the description adds far more — beta payload flag, mandatory caveat language, what mode="outlier" implies, route.confirmed=false meaning inference not GPI confirmation, basis.route_adjusted meaning no observed corridor data, and the distinction between ACCC delivery and funds usability. That is exactly the behavioral context annotations cannot carry.

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?

Long but front-loaded: the BETA caveat and the use-it-honestly instruction come first, then modes, then input discipline, then answer-reading. Every section is actionable, though the BETA warning and the confidence caveat are restated in more than one place, costing a little economy.

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 12-parameter, two-mode statistical estimator with an output schema, the description covers mode selection, input hygiene, contractual caveats, and interpretation of each returned field. Nothing an agent needs in order to call it correctly or relay the result honestly 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 each parameter is already documented at baseline. The description nevertheless adds cross-parameter meaning the schema cannot: which parameter set applies to which path, the prohibition on self-computing elapsed_business_days, and the rule that arrive_by_date deadlines must be resolved against the today block. Some of this duplicates schema text, which keeps it below 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 specific verb and resource — 'Estimate when a SWIFT payment will arrive' — and immediately separates the two operating modes (forward arrival vs reverse send-by). It is clearly distinguishable from siblings like track_payment (which supplies the uetr) and value_date/bank_holidays (which supply the calendar basis), both 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?

Explicit routing rules: pass ONLY the uetr for mid-flight payments, currency+sender_bic/receiver_bic for pre-trade, and arrive_by_date for reverse mode. It also names exclusions and alternatives ('elapsed_business_days are for this path only', 'pivot to the stuck-payment diagnostic flow' on mode="outlier"), so an agent knows when not to use it.

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 only declare readOnlyHint/openWorldHint; the description adds far more: the API-key/FI-subscription auth requirement, the null-vs-empty distinction for `intermediaries` (98% of rows), the COMMERCIAL vs FINANCIAL asset-category split, why `is_preferred` is null, and the meaning of empty `correspondents` (a coverage gap, not a finding). This is exactly the behavioural context annotations cannot carry.

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 and the routing/chaining guidance are front-loaded, which is good. However the body runs long with repeated admonitions ('Do NOT invent account numbers', 'do not read it as a direct chain', 'Do NOT name a correspondent') and onboarding boilerplate for registration, much of which could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet for this data set the description's explanation of field semantics (correspondent_selection sets, clearing_note, asset_categories vs asset_category, the various *_note fields) is what makes the response interpretable and prevents hallucinated routing. Given the tool's complexity and the open trap surface, the coverage is 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 100% and all three parameters are documented there, so the baseline is 3. The description adds only indirect parameter meaning — the examples show swift/currency pairing and the optional api_key form ('ssi_lookup("DEUTDEFF", "USD", api_key="prod-abc123...")') — but no extra semantics on format or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Look up correspondent banking / settlement instructions (SSI) for a bank') and immediately scopes the return to 'correspondent banks (nostro accounts) ... to settle payments in a specific currency'. It is clearly distinguishable from the nearest sibling, swift_lookup, which it explicitly frames as the coverage pre-check rather than a duplicate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use routing ('If the note suggests a further lookup, call ssi_lookup on the correspondent's SWIFT code'), names alternatives for the failure case (swift_lookup for the published correspondent page when accounts are missing), and states the prerequisite workflow (mcp_register → mcp_verify → FI plan subscription). It even tells the agent when NOT to skip the call ('Do not treat "might be a coverage gap" as a reason to skip').

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 only declare readOnlyHint and openWorldHint, so the description carries the rest and does so richly: it discloses the representative-office election behavior, the sanctioned-watchlist FLAG being coarse rather than a screen, and the tri-state semantics of settlement_instructions (on_file true / false / null, where null is 'not established yet'). It also warns that a name search returns only one office per bank and that BIC choice changes pricing, which is behavior an agent cannot infer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical scoping facts are front-loaded, but the body is heavy: all-caps emphasis lines, aphoristic asides ('never one to recall from training data'), and eight partly-overlapping examples pad the length. Most sentences carry information, but the styling and repetition keep it from being tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists and return values need not be described, the definition goes further and explains settlement_instructions and office_note semantics, which is exactly the interpretive context an agent needs. Nothing required 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 coverage is 100% and the schema already documents BIC length handling and the country filter, so the baseline is 3. The description adds genuine operational meaning beyond the schema by instructing that a user-named city belongs in the query string and by explaining why office selection inside the query changes the result.

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 ('Search banks and financial institutions by name, SWIFT/BIC code, or country') and explicitly scopes the corpus to SWIFT and non-SWIFT institutions. It distinguishes itself from siblings by name, routing compliance verdicts to sanctions_screen and correspondent data retrieval to ssi_lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use coverage with eight concrete call examples, plus when-not guidance ('this is NOT a full screen, use sanctions_screen for a compliance verdict'), a rule for including a city in the query, and a fallback instruction to ask the user for the BIC on their statement. Alternatives and exclusions are both spelled out.

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 and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: MT103 and pacs.008 responses include a `tracing_note` explaining UETR recovery, which tells the agent something about return content it would not otherwise know.

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 purpose, then the two usage modes, then concrete examples. Every sentence adds distinct information (domain coverage, field-location use case, response detail) with 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 documented, yet the description still flags the tracing_note behavior. With one optional parameter fully documented and clear usage modes, nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100% and the parameter's description already covers the case-insensitive/omit behavior, so the baseline is 3. The description goes further by naming concrete valid values (MT103, pacs.008, MT202, MT700, MT760, MT940, camt.053, pacs.002) and showing call examples, which is valuable given there is no enum on the parameter.

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 ('Look up SWIFT message types — MT (FIN) and MX (ISO 20022)') and immediately enumerates the domains covered, so an agent can distinguish it from siblings like swift_lookup or gpi_status_codes 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?

Explicitly gives both modes of use ('Pass a specific type to get full details, or omit to list all types') and adds a second legitimate use case (field-location questions). It does not, however, state when to prefer a sibling such as swift_lookup or gpi_status_codes instead, so no exclusion guidance is present.

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

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

Annotations are thin boolean hints, yet the description discloses the API-key/FI-subscription requirement, onboarding steps, exact-match and 90-day constraints, and the probability profile of each lookup path (~80% UETR vs <1% reference). It also warns that a reference-only miss is the expected outcome rather than a failure.

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 IMPORTANT blocks and worked examples are front-loaded and mostly earn their place, but the 'Returns a dict with...' section largely re-narrates an output schema that already exists, and the repeated emphasis markers add bulk that could be tightened.

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 6-parameter tool with 100% schema coverage and an output schema, the description still supplies the operational context an agent needs: required-vs-optional dependency logic, auth setup, status-value interpretation rules, and guidance on relaying not_found_guidance.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it establishes that amount/currency/date are required even on the UETR path and that there is no UETR-only lookup, and it explains what the reference number is (MT103 field 20 / pacs.008 InstrId).

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+identifier ('Track a SWIFT payment by UETR or reference number') and clearly distinguishes itself from siblings like tracking_history and gpi_status_codes by scoping to live SWIFT gpi tracking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it (reference-only user scenarios), the prerequisites that must be collected first, the alternative path (recover UETR from MT103 Block 3 {121:}), the alternative tool (swift_message_reference), and the expected success rates for each path. Nothing is left to inference.

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

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

Annotations only declare readOnlyHint/openWorldHint, so the description carries the real burden and does so unusually well: beta status, refusal semantics (answered=false and why there is deliberately no total), range vs point estimates, provenance of each figure (observed vs tariff), upper-bound semantics when a tariff is unknown, and the OUR/SHA/BEN non-guarantee. This is behavior an agent cannot get from the 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?

It is very long for a tool description, but it is well front-loaded (purpose, then beta caveat, then a structured 'HOW TO READ THE ANSWER' list) and almost every bullet corresponds to a distinct failure mode an agent would otherwise get wrong. Some length is repetition rather than new information, which keeps it out of the top band.

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 10-parameter, high-stakes financial estimator with an output schema, the description covers the input decisions (which segments, which charge type), the refusal paths, and the interpretation of the returned fields. Nothing an agent needs in order to call it correctly or relay it honestly 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 already 100%, but the description adds genuine meaning beyond it: customer_segment is explained as selecting which side of the sending bank's price list is read (with a concrete 220 PLN vs free example), beneficiary_segment as the receiving bank's separate schedule, and beneficiary_bic as the prerequisite for any total at all. This is materially more than the terse schema strings.

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 precise verb ('Estimate') and resource ('what a cross-border payment will COST'), and immediately decomposes it into the three payer-attributed components. This is clearly distinguishable from siblings like fx_rate, payment_method_compare and track_payment, which do not estimate landed cost by payer.

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?

Strong conditional guidance is given for the optional inputs: 'Pass beneficiary_bic whenever the user knows the receiving bank', 'pass business when the payer is a company', 'prefer asking over guessing when the amount makes the difference material', and 'if the user has not said which they will use, ask'. It does not name an alternative sibling tool or state when to reach for a different tool instead, so it stops short of the top band.

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 declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuine behavioral context beyond that, notably that relative dates must be resolved against the `today` block returned by this tool, bank_holidays, or is_business_day_check. It also spells out the settlement conventions (T+0/T+1/T+2, D+1) that govern the result, though it does not discuss error behavior for invalid country codes or unsupported pairs.

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 line, followed by a compact factor list and four illustrative calls; every element earns its place. The examples section is slightly long relative to the core content but remains skimmable and informative.

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, return values need no explanation, and the read-only annotations cover the safety profile. The description is largely complete for a 6-parameter computation tool, with the main residual gap being no explicit differentiation from adjacent siblings like settlement_eta and fx_timing_advisor.

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 six parameters including defaults and the FX-required currencies. The description's examples add positional-argument ordering (value_date("US", "DE", "fx_spot", "USD", "EUR")), which is a mild bonus over the schema, but it introduces no new semantics for individual parameters.

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: calculating the value/settlement date for a payment, with the inputs that drive the result (holiday calendars, weekend conventions, settlement convention). Clear enough to distinguish from pure holiday/calendar lookups like bank_holidays or is_business_day_check, though it never explicitly contrasts itself with the close-sounding sibling settlement_eta.

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 bullet list of contributing factors and the four worked examples imply when the tool applies, and the settlement_type options give concrete usage modes. However, there is no explicit when-to-use/when-not statement and no routing to alternatives such as settlement_eta, payment_cutoff_times, or bank_holidays, leaving the agent to infer the boundary.

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