banking-intelligence

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

With no annotations, the description fully discloses the tool's output structure, including payment_impact sections and diagnostic use. No contradictions or hidden behaviors.

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-structured: main purpose, bullet points for return sections, args, and examples. Every sentence adds value; no redundancy.

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 presence of an output schema, the description explains return values thoroughly and provides usage context for payment delay diagnosis. Parameters are fully explained, making the tool fully understandable.

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

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

Schema coverage is 0%, but the description explains country_code as ISO 3166-1 alpha-2 with examples, and year as optional with default current year and range 2020-2030, adding crucial meaning beyond the schema.

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

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

The description clearly states the tool gets bank/public holidays with payment impact analysis, specifying the return sections. It is specific and distinct from sibling tools like is_business_day_check due to its comprehensive payment delay analysis focus.

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 explicit context for diagnosing stuck payments, with step-by-step guidance on subtracting holidays and weekends. Lacks explicit mention of when not to use or alternatives, but the diagnostic instructions are strong.

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

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

With no annotations provided, the description fully discloses behavior: it returns only swift and name per bank, and clarifies that to get more details one should call ssi_lookup. It also states that the query is rejected without country and currency, and mentions API key and daily cap constraints. No contradictions.

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 well-structured with a one-liner, expanded explanation, args list, and examples. While informative, it could be slightly more concise by integrating some args info into the prose. However, it remains clear and organized.

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 that an output schema exists (not shown), the description does not need to explain return values. It covers purpose, usage guidelines, parameters, examples, subscription, and caps, making it complete for the tool's complexity.

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

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

The input schema has 0% description coverage, but the description compensates by providing a detailed 'Args' section explaining each parameter, including format hints (e.g., ISO codes) and examples. It also mentions that api_key can be passed via header, adding significant meaning beyond the schema.

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

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

The description clearly states 'Reverse SSI lookup — find banks that use a given correspondent for a currency.' It specifies the inputs (correspondent BIC, currency, country) and outputs (banks with swift and name), and distinguishes itself from the sibling 'ssi_lookup' by noting it is the inverse.

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 states when to use the tool: 'Given a correspondent BIC, currency, and origin country, returns the banks in that country that have a declared nostro at the correspondent for that currency.' It also advises when not to use it, directing users to call ssi_lookup for account numbers or intermediary details. Additionally, it notes that country and currency are required, and mentions subscription requirements and daily caps.

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

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

With no annotations, the description fully discloses that the tool returns a specific set of fields and requires a secret and grant. It is a read operation, and the description is clear on inputs and outputs, though it could mention idempotency.

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 extremely concise: two sentences plus a bullet list of return fields. No extraneous information; every part serves a purpose.

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

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

Given the tool's simplicity (one parameter, no nested objects, output schema exists), the description covers all essential aspects: purpose, parameter, return fields, and usage condition. It is fully 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 coverage is 0%, so the description must compensate. It provides an example IBAN format (KZ12345678901234567890) which adds value, but does not describe full validation rules or acceptable formats.

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

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

The description clearly states 'Get balance and status for a specific IBAN,' specifying both the action (get) and the resource (IBAN). This distinguishes it from siblings like bcc_list_accounts and bcc_get_statement.

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 includes a 'Per-user' note that only works with a provisioned BCC secret and allow grant, providing clear context on prerequisites. It implies usage when needing balance/status, but does not explicitly exclude alternatives.

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

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

With no annotations, description discloses auth requirement (BCC secret and allow grant) and return structure (statement v2 with inBalance, outBalance, transactions[]). Not covered: pagination, ordering, or error handling, but still fairly transparent.

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?

Extremely concise: one-line purpose, bullet-point args, return structure, and auth note. No redundant information, well-structured and front-loaded.

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

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

Covers purpose, parameters, return type, and prerequisites. Lacks edge cases (e.g., empty result) but still adequate for a tool with 4 params and output schema mentioned.

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

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

Schema coverage is 0%, so description fully compensates by documenting all 4 parameters with formats and examples: IBAN format, date format (dd-mm-yyyy), currency as optional filter.

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?

Description clearly states verb ('Get'), resource ('transaction statement'), and scope ('for an IBAN over a date range'). It distinguishes from siblings like bcc_get_balance (balance only) and bcc_list_accounts (list accounts).

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 clear context: use when you need a transaction statement for an IBAN over a date range. Includes a prerequisite condition (must have BCC secret and allow grant), but no explicit when-not or alternatives.

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

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

With no annotations, the description fully carries the burden. It discloses that the tool is read-only (list all accounts) and requires specific user credentials. It does not mention side effects because none exist. Minor missing detail: whether pagination or rate limits apply.

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

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

Two sentences, zero wasted words. The first sentence clearly states the primary function; the second adds return structure and usage constraint. Perfectly front-loaded.

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

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

Given zero parameters and an output schema, the description covers all necessary context: what it does, what it returns, and prerequisites. No gaps.

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

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

No parameters exist (input schema empty), so the description does not need to add parameter meaning. It correctly implies the tool requires no further input beyond credentials.

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

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

The description clearly states the tool lists all accounts accessible via BCC API credentials and specifies the return structure {iban, description}. It distinguishes from sibling tools like bcc_get_balance and bcc_get_statement by focusing on enumeration rather than balance or transaction details.

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 mentions the prerequisite (provisioned BCC secret and allow grant) but does not explicitly guide when to use this tool versus alternatives. No 'when-not' or sibling differentiation in usage context.

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

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

With no annotations, the description carries full burden. It discloses the experimental nature, the fact that no API key is required, and that it returns a list of registries and jurisdiction codes. It does not mention any side effects or limitations, but for a read-only list tool, this is sufficient.

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 extremely concise, using three short sentences and an example. It front-loads the experimental flag and the core purpose, with no wasted words.

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

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

Given the tool has zero parameters and an output schema (assumed present), the description is complete. It explains the output (list of registries and jurisdiction codes) and how to use it with related tools. No additional information is needed.

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?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter semantics beyond what the schema provides. A score of 4 is appropriate per the baseline for zero 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?

The description clearly states that the tool lists available company registries and supported jurisdictions. It uses specific verbs ('List') and resources ('company registries', 'jurisdiction codes'), and distinguishes from sibling tools like company_search_company and company_search_person by noting that the jurisdiction codes from this tool are used in those searches.

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 implies when to use this tool—before searching, to obtain jurisdiction codes. It mentions that no API key is required and provides an example call. However, it doesn't explicitly state not to use it under certain conditions or provide direct alternatives among 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?

No annotations provided, so description carries full burden. Discloses experimental status, sanctions screening, and automatic inclusion of officers/shareholders by default. Does not mention rate limits or error handling, but output schema likely covers return format.

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?

Structured with a first-line summary, then paragraph, bullet list of args, and examples. Front-loaded with purpose and essential constraint. Slightly lengthy but every sentence adds value.

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

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

Covers purpose, parameters, constraints, and examples. Given the presence of an output schema, the description is sufficiently complete for agent usage. Missing minor details like result limits but not critical.

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 0% schema description coverage, the description compensates fully: explains all 7 parameters, their defaults, and constraints (e.g., 'jurisdictions' must be individual country codes). Adds valuable context beyond the bare 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?

Clearly states 'Search company registries for a company with its officers and shareholders', specifying the verb, resource, and scope. Differentiates from siblings like 'company_search_person' by focusing on companies. Includes additional context about sanctions screening.

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 the requirement for at least one jurisdiction and that 'ALL' is not supported. Lists available jurisdictions and provides examples. Does not explicitly mention when to use alternatives, but the constraint is clear.

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

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

With no annotations provided, the description fully covers behavioral aspects: it mentions automatic sanctions screening, experimental status, and parameter defaults. It does not discuss pagination, rate limits, or response format, but output schema exists for that.

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 well-structured with a bolded intro, explanatory paragraph, bullet-point Args, and examples. Every sentence adds value, and it is front-loaded with the main purpose.

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

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

Given 5 parameters (2 required) and an output schema, the description covers all key behavioral aspects and parameter details. It could mention result ordering or limits, but overall it is nearly 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?

The description provides detailed parameter explanations beyond the schema: name, jurisdictions (with example values), include_sanctions_check, include_inactive_roles, and api_key. It compensates for 0% schema coverage effectively.

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

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

The description uses a specific verb 'search' and clearly identifies the resource: company registries for a person's directorships, officer roles, and shareholdings. It distinguishes from sibling 'company_search_company' by focusing on persons.

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 states the jurisdiction requirement, lists available jurisdictions, and notes that 'ALL' is not supported. Examples clarify typical usage. However, it does not explicitly contrast with sibling tools or state 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?

With no annotations, description carries full burden. It highlights 'EXPERIMENTAL' status, non-mutating nature (cached), and parameter alternatives. Could mention search_id expiration or error handling.

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

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

Description is well-structured with sections, concise, and every sentence adds value. No wasted words.

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

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

Given output schema exists, description doesn't need to detail returns. It covers purpose, usage, and parameters adequately for a retrieval tool.

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

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

Schema description coverage is 0%, but description adds clear meanings for both parameters beyond schema types, including optional api_key alternatives.

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

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

The description clearly states it retrieves cached company search results by search ID, distinguishing it from sibling tools that perform the initial 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?

It explains to use after a company_search_person/company_search_company call and that it avoids re-running. Lacks explicit when-not-to-use, but context is sufficient.

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?

Even with no annotations provided, the description fully discloses the tool's behavior: it returns country-specific banking rules, mentions the payment_requirements block for special codes, and implies idempotent read-only behavior through 'Get' verb and return type listing. No contradictions or hidden effects.

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

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

The description is well-structured with a concise summary, context for use, parameter details, and examples. Each sentence adds value without redundancy. At 120 words, it is efficient and front-loaded with critical 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?

Given the tool's simplicity (one parameter, output schema exists), the description covers all necessary aspects: purpose, usage, parameter format, examples, and linkage to sibling tool. No gaps remain for correct invocation.

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

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

The schema provides only a parameter name 'country_code' without description (0% coverage). The description compensates fully by specifying 'ISO 3166-1 alpha-2 code' and providing multiple examples ('DE', 'US', 'KZ', 'AE'), which adds significant semantic meaning beyond the schema.

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

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

The description clearly states 'Get banking rules and requirements for a country' with a specific list of return types (IBAN requirements, SEPA membership, etc.). It distinguishes itself from sibling tools like country_payment_codes by explaining the relationship and appropriate use case.

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

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

The description explicitly states when to use: 'check country-specific STP rules that could cause payment delays, repairs, or rejections'. It also provides guidance on when to use a sibling tool (country_payment_codes) for specific code values, and includes examples of usage for different countries.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns embargo status, sanctioned programs, control reasons, and a payment_jurisdiction_note. It also warns about the binding nature of controls and the importance of nexus, which is crucial for correct use.

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 well-structured with sections for purpose, important notes, arguments, examples, and use case. While it is somewhat lengthy, every sentence adds value, and the structure aids readability.

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

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

Given the tool's complexity (multiple jurisdictions, return fields), the description is thorough. It explains the payment_jurisdiction_note and provides examples. An output schema exists, so detailed return format documentation is unnecessary.

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 0% schema description coverage, the description fully compensates by providing clear parameter explanations: country_code is an ISO 3166-1 alpha-2 code with examples, and jurisdiction is an optional filter with examples. The examples show typical 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?

The description uses the specific verb 'Look up' with the resource 'export control restrictions for a specific country', clearly stating the tool's purpose. It distinguishes from sibling tools like sanctions_screen and country_banking_rules by focusing on export controls.

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 provides clear context on when to use the jurisdiction filter and includes an important warning about jurisdiction nexus. It gives a specific use case but does not explicitly mention when to use an alternative tool, though the context makes it clear.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool as performing a lookup with optional search, and notes that omitting the search parameter returns all codes (large response). This sufficiently conveys the operation and potential response size, though it could mention that it is a read-only operation.

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 concise: a one-line summary, a usage guideline sentence, parameter definitions, and examples. Every sentence adds value, and the structure is front-loaded with the most important information first.

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

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

Given the tool's complexity (3 parameters, links to sibling workflow, output schema exists), the description is complete. It covers input semantics, usage order, and example invocations, leaving no ambiguity for correct invocation.

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

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

All three parameters are described in the Args block with type, source, and usage details. 'code_type' is explained as coming from payment_requirements fields, and 'search' is explained as an optional keyword filter with examples. Since the schema has no descriptions (0% coverage), the description compensates fully.

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

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

The description clearly states the tool's purpose: 'Look up country-specific payment codes (KNP, purpose codes, etc.)'. This is a specific verb+resource, and by referencing the sibling tool 'country_banking_rules' as a preceding step, it distinguishes the tool's role.

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 advises using 'country_banking_rules' first to determine required code types, then using this tool to find code values. This provides a clear when-to-use context and links to a sibling tool, guiding the agent on the correct workflow.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool as a 'Pure reference tool,' implying read-only behavior. It specifies the return values (classification details, controlled jurisdictions, license requirements). However, it does not explicitly state that it is read-only or idempotent, nor does it mention error handling or data freshness. Still, the behavioral intent is clear.

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 well-structured with a clear action statement, a brief explanation of ECCN, parameter documentation, and examples. It is front-loaded with the purpose. It could be slightly more concise by removing the ECCN definition or integrating it more tightly, but it remains clear and efficient.

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

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

Given the tool's simplicity (single required parameter, reference function), the description provides complete context. It explains the domain (export control regimes), the parameter, and the return value categories. Since an output schema exists, detailed return format is not required. Examples complete the picture.

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 schema coverage is 0%, meaning the input schema has no description for the parameter. The description thoroughly explains the 'eccn' parameter, including its meaning, format (alphanumeric codes), and examples ('5A001', '3A001', '1C351'). This significantly adds value beyond the schema's simple type definition.

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

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

The description clearly states 'Look up an Export Control Classification Number (ECCN)' with a specific verb and resource. It explains what ECCN is and what the tool returns (classification details, controlled jurisdictions, license requirements). The examples further clarify the purpose, and it distinguishes itself from sibling tools like country_export_controls by focusing on classification numbers.

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 calls it a 'Pure reference tool' which implies when to use it, but it does not explicitly state when not to use it or provide alternatives. Given sibling tools like country_export_controls and sanctions_screen, some guidance on when to use this vs. those would improve clarity. The usage context is clear but lacks exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains what the tool returns (license required, risk level, policies, control reasons, flags) and highlights the critical jurisdiction nexus. It does not contradict any implicit assumptions about the tool's behavior. The description is transparent about the tool's read-only nature (screening) and the need for at least one goods identifier.

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 somewhat lengthy but well-structured. It front-loads the core purpose, then explains key caveats (jurisdiction nexus), lists parameters, gives examples, and ends with a use case. Every sentence adds value, but it could be slightly more concise by condensing the examples. Overall, it is efficient and well-organized.

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

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

Given the tool's complexity (5 parameters, no annotations, output schema exists), the description is remarkably complete. It covers all critical aspects: use case, parameter semantics, jurisdiction nuances, and return value summary. The existence of an output schema means the description doesn't need to detail every return field, but it still provides an overview. No gaps are apparent for an AI agent to use the tool correctly.

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

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

The input schema has 0% coverage for parameter descriptions, so the description compensates fully. The 'Args' section provides meaningful details for each parameter: format (e.g., ISO 3166-1 alpha-2 for destination_country, 4-8 digits for hs_code), optionality, default values, and even the requirement to provide at least one of eccn/hs_code/goods_description. It lists allowed jurisdiction values explicitly, adding 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 clearly states the tool's purpose: 'Screen goods for export-control restrictions to a destination country.' It specifies the verb 'screen' and the resource 'goods for export-control restrictions.' It also distinguishes itself from siblings like eccn_lookup, goods_classify, and sanctions_screen by combining classification with restriction status and returning a comprehensive output including license policies and control reasons.

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

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

The description provides clear guidance on when to use the tool and how to invoke it. It explains the jurisdiction nexus and offers examples for different scenarios. However, it does not explicitly contrast with sibling tools like country_export_controls, leaving some room for ambiguity. Still, the usage examples and the requirement to provide at least one goods identifier offer sufficient direction.

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

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

No annotations are provided, so the description bears full responsibility. It describes the output (Federal Register publications) and parameter ranges but does not mention potential errors, rate limits, or authorization requirements. The tool appears read-only, but that is not explicitly stated.

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 concise and well-structured: a one-line summary, a clear argument list with indentation, multiple examples, and a relevant use case. Every sentence adds value, and the organization aids quick comprehension.

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

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

The tool has an output schema, so return values need not be detailed. The description covers parameters, examples, and a use case. It lacks details on pagination, ordering, or error handling, which would be helpful for complete usage, but the current information is largely sufficient for a query tool.

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

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

The schema description coverage is 0%, but the description compensates fully by detailing each parameter (agency, category, severity, days, limit) with acceptable values, defaults, and meanings. This adds significant value beyond the schema's type and default definitions.

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 explicitly states the tool fetches recent US regulatory changes from BIS and OFAC, listing specific categories like entity list updates and rule changes. It includes examples and a use case, making the purpose immediately clear. No sibling tool appears to overlap directly, so differentiation is inherent.

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 provides examples and a concrete use case ('Any new entity list additions affecting China?'), which implies appropriate usage scenarios. However, it does not explicitly state when not to use this tool or mention alternatives like sanctions_screen or country_export_controls, so there is room for improvement.

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

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

With no annotations, the description explains cross-rate computation, requirement for exact pair, and error behavior for missing arguments. This is sufficient transparency for a simple rate tool.

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?

Concise, well-structured with sections for description, args, and examples. Every sentence serves a purpose; no waste.

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 presence of an output schema, the description covers purpose, inputs, behavior, and examples comprehensively. Nothing essential is missing.

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

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

Schema coverage is 0%, so description adds value by explaining both parameters with ISO 4217 format and examples. Meaning well beyond the bare 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 clearly states 'Get the latest ECB reference exchange rate for a currency pair,' specifying verb and resource. It distinguishes from siblings like fx_rate_history by focusing on current rates.

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 clear guidelines: both currencies required, no implicit defaults, and warns about error behavior. Examples illustrate usage. Lacks explicit when-not-to-use but context from siblings implies historical/volatility tools for other needs.

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?

Discloses ECB publishes only on weekdays (no weekends/holidays) and that errors occur for misnamed currencies. No annotations provided, so description carries burden. Missing rate limits or auth info, but for a read-only historical tool, this is adequate.

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 concise and well-structured: short intro, behavioral notes, args in a list, and examples. Every sentence adds value with zero redundancy.

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

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

Given an output schema exists (true), description not required to detail return values. Covers purpose, parameters, behavioral constraints, and usage guidance. Slight gap on error handling or rate limits, but overall sufficient for selection and invocation.

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

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

Schema has 0% description coverage. The description lists all three parameters (base, target, days) with ISO 4217 format, defaults, and examples, adding significant meaning beyond the bare 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 clearly states 'Get historical ECB exchange rates for a currency pair.' It specifies the data source (ECB) and action (get historical rates), distinguishing it from siblings like 'fx_rate' (presumably current rates) and others.

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 explicit guidance: 'BOTH currencies are required,' 'Always pass the exact pair you intend,' and warns of errors for misnamed currencies. Lacks explicit when-not-to-use vs alternatives, but the sibling list and implicit contrast are sufficient.

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

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

No annotations are provided, so the description carries full burden. It discloses that output includes market sessions and liquidity windows, mentions inbound_processing_note for restricted currencies, and warns about misuse for delay diagnosis. However, it does not explicitly state read-only behavior or other side effects, but the informational nature is clear.

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?

Despite length, the description is well-structured with bullet points, clear sections, and front-loaded purpose. Every sentence adds value, and the formatting aids readability. No wasted words.

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

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

The description is complete for a timing advisory tool: it explains inputs, outputs (market sessions, liquidity windows, inbound_processing_note), use cases, and limitations. The output schema exists (not shown but noted), so low need to explain return values. Subtle misuse scenarios are addressed.

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

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

The single optional parameter currency is well-documented: passing a code gets optimal window, omitting gets all sessions/overlaps. Examples demonstrate usage. Schema has 0% description coverage, so the description fully compensates, adding meaning beyond the raw 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 clearly states the tool's purpose: 'Get FX trading windows for FX execution timing and spread / rate optimization.' It specifies the output (market sessions and liquidity windows) and distinguishes from related siblings like fx_rate, fx_volatility, and country_banking_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?

The description explicitly differentiates between primary use (rate optimization) and cautionary use (delay diagnosis), advises against quoting hold durations, and directs to alternative tools (country_banking_rules) for specific scenarios. It provides clear when-to-use and when-not-to-use 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?

With no annotations, the description fully carries the burden. It details computation method (standard deviation of daily log returns, annualized by sqrt(252)), qualitative thresholds, and settlement risk note, providing comprehensive behavioral context without contradictions.

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 well-structured with a summary, detailed computation, bucket definitions, and Args section. It is slightly verbose but every sentence adds value; could be tightened without losing clarity.

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

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

Given an output schema exists, return values are covered. The description explains qualitative buckets, movement estimates, and settlement note. It lacks mention of data recency or caching, but overall adequate for the complexity.

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

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

Schema coverage is 0%, but the description specifies both parameters as ISO 4217 currency codes with examples (EUR, TRY). This adds meaning beyond the schema's type string and clarifies 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?

The description starts with a clear verb+resource: 'Get realized FX volatility for a currency pair.' It distinguishes from sibling tools like fx_rate (current rate) and fx_rate_history (historic rates) by focusing on volatility computation.

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 explains what the tool computes (30/90-day annualized volatility) and outputs (qualitative bucket, movement estimates, settlement risk note). It does not explicitly state when not to use it or mention alternatives, but the context is clear for a financial analyst.

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

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

With no annotations provided, the description carries full burden. It explains it returns HS code, ECCNs, control reasons, confidence score, and alternatives. It mentions bilingual auto-detection and minimum 2 char requirement. It is clear about the non-destructive classification, though it could explicitly state it does not modify data.

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 well-structured with examples and clear sections. It front-loads the purpose. Every sentence adds value, though it could be slightly more concise without losing information.

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

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

The tool has an output schema (not shown), so description need not explain return format in detail. It mentions key return values and covers complexity well. It provides adequate context given the sibling tool list and parameter 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 coverage is 0%, so description compensates. It explains description (required, min 2 chars, examples), hs_code (optional for direct lookup), language (optional hint). This adds meaning beyond the schema, such as the minimum length and behavior of hs_code for direct lookup.

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

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

The description clearly states the tool classifies goods for export control from a description or HS code, with specific verb 'classify' and resource 'goods for export control'. It distinguishes itself from siblings like 'export_controls_screen' and 'hs_code_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?

The description explains the tool is destination-agnostic and directs use of 'export_controls_screen' for license decisions. It provides examples for various use cases but does not explicitly state when not to use this tool or alternatives like 'hs_code_lookup'.

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

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

With no annotations, the description fully discloses behavior: returns investigation playbooks with causes, actions, and ISO reason codes for specific codes; returns full list when no code given. No contradictions.

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-structured with bullet points and scenario mappings, but lengthy. Information is valuable and front-loaded, though could be slightly more 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 the tool and 28 siblings, the description is complete: it covers when to use, what each call returns, examples, and mentions output schema content. No gaps.

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

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

Despite 0% schema description coverage, the description thoroughly explains the single optional 'code' parameter: its purpose, default behavior (null returns full list), and recommended values for different scenarios.

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

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

The description clearly states the tool explains SWIFT GPI tracking status codes and provides stuck-payment investigation guidance. It differentiates from siblings like track_payment and swift_lookup by focusing on status codes and diagnostic playbooks.

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 advises 'USE THIS TOOL FIRST' for stuck payments and maps scenarios to specific codes (ACSP, PDNG, etc.). Provides clear guidance on when to call without argument for a reference list.

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

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

With no annotations provided, the description must fully disclose behavior. It explains the tool is read-only and returns ECCN mappings with details like confidence levels and regimes. It also warns that an empty response does not guarantee uncontrolled goods. While adequate, it does not cover potential data freshness or rate limits.

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 well-structured with a summary, details, args, and examples. It is front-loaded with the core purpose. While informative, the args section slightly repeats schema information but adds value through explanations. Could be trimmed slightly but remains efficient.

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

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

Given the tool's modest parameter count and presence of an output schema, the description covers the input details, output summary, and important caveats (e.g., 4 vs 6-digit codes, empty mapping meaning). It does not detail the output schema but that is handled separately. Overall, it provides sufficient context for correct usage.

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 schema has 0% description coverage, so the description compensates by explaining the hs_code parameter (4-6 digit code, dots/spaces ok) and jurisdiction (optional filter with explicit values US, EU, UK, JP). Examples further illustrate usage. However, the default empty string for jurisdiction is not explicitly stated.

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

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

The description clearly states the tool performs a reverse-lookup from an HS code to export-control classifications (ECCNs), specifying the verb (reverse-lookup) and resource (HS code mapped to ECCNs). It distinguishes itself from sibling tools like eccn_lookup and goods_classify by focusing on this specific mapping.

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 specifies the target users (customs brokers/shippers) and the use case (determining export controls from an HS code). It provides guidance on input format and notes that empty mappings require confirmation via goods_classify. However, it lacks explicit when-not-to-use instructions or comparisons with alternatives.

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

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

No annotations exist, so description carries full burden. It discloses validation steps and that it returns country banking rules. Examples show input format flexibility. It is transparent about behavior, though could mention it is read-only.

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 concise with two short paragraphs and clear examples. Every sentence adds value, no redundancy.

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 one parameter and output schema existing, the description covers validation logic and input format. It doesn't detail return structure but output schema would handle that. Minor gap: no mention of error 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 0%, but description adds meaning by showing examples with and without spaces, and explaining that the IBAN string is validated for format and checksum. This compensates for lack of 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 clearly states 'Validate an IBAN number' and lists specific checks (format, length, checksum) and what it returns (country rules). This distinguishes it from sibling tools like country_banking_rules or is_business_day_check.

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 implies usage for IBAN validation through examples, but does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

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

No annotations provided, so description carries burden. It discloses return value structure (boolean, reason, next business day) but lacks details on side effects, permissions, rate limits, or performance expectations. Adequate but not comprehensive.

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-structured with summary, return details, parameter descriptions, and examples. No unnecessary words, but could be slightly more concise in return description. Mostly efficient.

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 existence of output schema, description covers input sufficiently. Mentions return values, but lacks fallback or error handling info. Complete enough for a straightforward check tool, but could note supported countries or data sources.

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

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

Schema coverage is 0%, but description fully explains both parameters: country_code as ISO alpha-2 code, check_date as ISO date format. Examples illustrate usage. Adds significant meaning beyond the bare 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?

Description clearly states the tool checks if a date is a business day in a country, accounting for weekends and holidays, and returns the next business day and reason. Verb and resource are explicit, and it distinguishes from sibling tools by focusing on a specific date check.

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

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

No guidance on when to use this tool versus alternatives like bank_holidays. No prerequisites or exclusions mentioned. Examples show usage but don't help agent decide between tools.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool sends an email with a verification code and requires accept_terms. It doesn't mention rate limits or failure behavior, but for a registration tool this is adequate.

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 well-structured with a purpose statement, process details, parameter list, and example. It is concise but covers necessary information; could be slightly tighter but is still effective.

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 that an output schema exists (context signal), the description correctly focuses on inputs and process. It explains the registration flow and points to mcp_verify for completion. No major gaps for this tool's role.

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 input schema has 0% coverage, so the description must explain all three parameters. It describes email, organization_name, and accept_terms (including the requirement that it must be true and links to terms). An example call is provided, adding significant 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?

The description clearly states the tool registers for an Ohmyfin API key to use paid tools, creates an account, and sends a verification code. It distinguishes itself from the sibling tool mcp_verify by specifying the subsequent 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?

The description explicitly says to call mcp_verify after receiving the code, providing a clear next step. It implies registration is a prerequisite for paid tools, though it doesn't explicitly list alternatives or when not to use.

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

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

With no annotations, the description carries full burden. It discloses the return of API keys and the subscription requirement, but lacks details on error handling (e.g., invalid codes), side effects, or edge cases. Adequate but not comprehensive.

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 concise but complete: purpose, prerequisite, outcome, subscription note, parameter descriptions, and an example. Every sentence adds value, and the structure is logical.

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

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

Given the tool's simplicity and the presence of an output schema (mentioned in context signals), the description covers all necessary aspects: purpose, parameters, outcome, and prerequisites. It is fully adequate for the tool's role.

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

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

Schema coverage is 0%, so the description provides all parameter meaning. It explains 'email' as the registered email and 'code' as the 6-digit verification code, with an example. This fully compensates for the missing 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 clearly states the tool's function: 'Verify your email and receive your API key.' It also specifies the prerequisite (after mcp_register) and the outcome (returns API keys), making the purpose unambiguous and distinct from sibling tools.

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

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

The description provides clear usage context by mentioning 'After calling mcp_register' and noting that subscription is needed for paid tools. However, it does not explicitly state when not to use the tool or list alternatives, which is acceptable given the straightforward nature.

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

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

No annotations are provided, so the description carries the full burden. It comprehensively explains DST handling, field meanings (season_now, operative_cutoff_today), and warns against defaulting to winter values. No contradictions.

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 well-structured with sections, Args, and Examples. While it is relatively long, every sentence adds value for a complex tool. Could be slightly more concise without losing info.

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

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

Covers all relevant aspects: system types, DST details, filtering strategies, and example calls. The output schema exists, so return value details are not required, but the description still references key fields.

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?

Although schema coverage is 0%, the description fully compensates by detailing the 'system' parameter (case-insensitivity, aliases like TARGET2/T2) and 'currency' parameter (ISO 4217 filter), plus concrete examples.

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

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

The description clearly states 'Get payment system cutoff times for major clearing systems', with a specific verb and resource. It distinguishes from sibling tools like 'fx_rate' or 'track_payment' by focusing exclusively on cutoff times.

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 actionable guidance (e.g., 'filter by currency="EUR" to retrieve all SEPA schemes plus T2') and examples. However, it does not explicitly state when to avoid this tool or compare to alternatives among 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?

With no annotations, the description carries full burden. It discloses that the tool returns cost, speed, requirements, charge options, and fee investigation guidance, and mentions explaining MT103 fields. However, it does not state if the tool is read-only, any authorization needs, or rate limits, leaving some behavioral aspects ambiguous.

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?

Description is well-structured with a bold purpose statement, bullet-like sections, and examples. It is slightly lengthy but every sentence adds value, and the key information is front-loaded.

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

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

Given the tool's complexity (fee investigation, multiple payment methods) and presence of an output schema, the description covers return values implicitly through the examples and explanation. It is fairly complete, though could mention edge cases or invalid inputs.

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

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

Schema coverage is 0%, so description compensates by explaining both parameters as ISO 3166-1 alpha-2 codes with examples (e.g., 'DE', 'US', 'GB', 'TR'). This adds significant meaning beyond the bare schema, though it could specify valid country codes or error handling.

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?

Description clearly states it compares payment methods and investigates fee deductions for a country pair, specifying SEPA, SWIFT, domestic options, and charge options. It distinguishes from sibling tools by focusing on payment method comparison rather than other banking functions.

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 explicit usage context: 'use this when the beneficiary received less than expected' and gives four distinct examples covering SEPA, non-SEPA, domestic, and fee investigation scenarios. Though it does not mention alternatives explicitly, the examples offer clear guidance on when to use.

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

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

With no annotations, the description carries the full burden. It discloses the sanctions lists checked, the optional API key, threshold range, and free tier limit. However, it does not mention rate limits beyond the free tier, error responses, or behavior when no match is found.

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 well-structured with clear sections (free tier, lists, args, examples). Every sentence adds value without redundancy. It is concise yet comprehensive.

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 presence of an output schema (not shown but noted), the description does not need to detail return values. It covers all necessary context: input parameters, authentication, limits, and examples. No gaps remain for an AI agent to infer.

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?

Although the input schema has 0% description coverage, the description thoroughly explains all three parameters: `name` (entity name), `api_key` (with alternative passing methods), and `threshold` (range 0-100, default 85). Examples further clarify 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?

The description clearly states 'Screen a name against global sanctions and watchlists' and lists specific sanctions lists (US SDN, EU, UK, etc.). It distinguishes itself from sibling tools, which focus on other domains like banking, company search, or FX, making the tool's purpose unambiguous.

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

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

The description provides usage context: free tier vs paid, parameter defaults, and authentication options. It does not explicitly compare to alternative tools, but sibling tools are sufficiently different that the usage is clear. Lacks explicit 'when-not-to-use' 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?

With no annotations provided, the description fully discloses behavioral traits: data gaps (missing account numbers, rarely populated is_preferred, empty intermediaries), subscription requirements, response components (clearing_note, account_availability_note, etc.), and the next_steps array for chaining calls.

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 a one-sentence summary, then organized into logical sections: return content, important data gaps, next_steps, subscription requirements, and examples. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity and the presence of an output schema, the description thoroughly covers response components, data handling notes, and chaining with other tools via next_steps. It leaves no significant gaps for an agent to misunderstand.

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 schema has 0% coverage, but the description adds meaning for all three parameters: swift format (8 or 11 chars, example), currency format (ISO 4217), and api_key format (prod-...). Examples illustrate usage, compensating for the lack of 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 clearly states the tool's purpose: 'Look up correspondent banking / settlement instructions (SSI) for a bank.' It specifies what it returns (nostro accounts, account numbers, intermediary chains) and differentiates from sibling tools like swift_lookup and country_banking_rules by explicitly mentioning when to use them.

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

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

The description provides explicit when-to-use context ('Essential for payment routing and pre-validation') and when not to use (e.g., do not invent account numbers, use swift_lookup instead). It also warns about data gaps and directs users to other tools via next_steps array.

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

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

No annotations provided, so description carries full burden. It details return fields (SWIFT/BIC, name, city, etc.) and notes the sanctions flag is coarse. Does not mention error handling or rate limits, but is otherwise transparent about capabilities and limitations.

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-structured with clear purpose first, then details and examples. Slightly verbose but each sentence adds value. Examples at end enhance clarity without being redundant.

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

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

Complete for a search tool with 3 parameters and an output schema. Explains scope (SWIFT + non-SWIFT), return fields, parameter usage, and caveats (coarse sanctions flag). Sibling tools are well-addressed with cross-references.

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

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

Schema coverage is 0%, so description must explain parameters. It explains 'query' can be a BIC or name, 'country' accepts ISO codes or full names, and shows default for 'limit' in example. Could briefly mention 'limit' parameter behavior, but overall adds meaning beyond 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 clearly states the tool searches banks and financial institutions by name, SWIFT/BIC code, or country, including non-SWIFT entities. It distinguishes itself from siblings like ssi_lookup and sanctions_screen by explicitly mentioning alternatives for related tasks.

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 explicit guidance on when to use this tool vs alternatives (e.g., refer to SSI tools for correspondent banking, use sanctions_screen for compliance verdict). Also includes example calls and explains parameter formats (e.g., country accepts ISO codes or full names).

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

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

No annotations are provided, so the description must disclose behavior. It explains that the tool returns full details with field info for a specific type, lists all types when omitted, and includes a tracing note for certain message types. This adequately sets expectations.

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 somewhat lengthy but well-structured: purpose statement, list of covered types, field-location use case, parameter description, and examples. It is front-loaded and each part contributes meaningfully.

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 moderate complexity and presence of an output schema, the description provides enough context: it explains the parameter behavior, the nature of results (details, field info, tracing note), and examples. No obvious gaps remain.

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 schema has one optional parameter with 0% description coverage. The description adds value by explaining the parameter is case-insensitive, provides examples, and states the behavior when omitted. This fully compensates for the lack of 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 clearly states the tool looks up SWIFT message types (MT and MX) and provides field-level details. It lists specific examples and coverage areas, distinguishing it from sibling tools which focus on other banking/payment functions.

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 explains when to pass a specific type versus omit it, and suggests using the tool to answer field location questions. It lacks explicit 'when not to use' guidance, but the context is clear enough.

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

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

No annotations provided, so description carries full burden. Discloses success rates, interpretation of bank details (role only known when self-reported), and that not_found_guidance contains concrete next steps. Also requires API key with active FI subscription. Fully transparent about behavioral traits.

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-structured with sections (basic purpose, important notes, scenario, args, returns, examples). Every sentence adds value, but length could be slightly reduced; however, the complexity justifies the 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?

Complete coverage given complexity: 6 parameters, no required (defaults provided), no enums, but output schema exists. Description explains return fields, edge cases (reference-only failure), and provides concrete next steps (not_found_guidance). Output schema details are not repeated, making it efficient.

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 has 0% description coverage, but description compensates fully: explains UETR format (UUID v4), reference meaning (MT103 Field 20), amount must match original, currency ISO 4217, date formats, and api_key handling. Provides examples for different parameter combinations.

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

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

The description clearly states the tool tracks SWIFT payments by UETR or reference number, with a specific verb and resource. It distinguishes from sibling tools like swift_message_reference and gpi_status_codes by focusing on tracking a specific payment's status.

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 explicit guidance: prefer UETR (~80% success) over reference (<1%), with detailed instructions for reference-only scenarios including required fields (amount, currency, date) and success expectations. Also tells when not to use the tool (e.g., if user has UETR, always provide it) and what alternatives exist (recover UETR from MT103).

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?

Since no annotations are provided, the description fully bears the burden of behavioral disclosure. It explains the logic based on holiday calendars, weekend conventions, currency holidays, and settlement conventions. While it doesn't mention side effects or authentication, the behavioral traits are well covered.

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 well-structured with a one-line summary followed by bullet points listing parameters and their explanations, then examples. It is appropriately sized and front-loaded with the key purpose.

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

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

Given the tool's complexity (6 parameters, conditional logic) and the absence of annotations, the description is complete. It covers all necessary aspects: parameter meanings, defaults, conditional requirements, and examples. An output schema exists, so return values need not be explained.

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 description provides detailed explanations for all 6 parameters, including formats, defaults, and conditional requirements (e.g., base_currency and target_currency needed for fx_spot). This adds significant value beyond the schema, which has 0% description coverage.

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

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

The description clearly states the tool calculates the value/settlement date for a payment, using a specific verb (calculate) and resource (value/settlement date). It distinguishes from sibling tools like bank_holidays and fx_rate by focusing on settlement date calculation.

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 provides clear context on when to use the tool (for payment settlement) and includes examples for various use cases. It does not explicitly state when not to use it or suggest alternatives, but the parameter explanations and settlement types guide appropriate usage.

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