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?

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 carries full burden for behavioral disclosure. It reveals rates are from ECB, supports ~30 currencies, and cross-rates are derived via EUR. It does not mention update frequency, error handling, or unsupported currency behavior, but covers key operational details adequately.

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, front-loaded with the core purpose, then adds details and examples. Every sentence provides useful information without 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, return format details are unnecessary. The tool is simple (2 parameters, no required ones), and the description covers what it does, how it works, and provides examples. It is complete for its complexity, though a note on supported currencies and update frequency would enhance it.

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 add meaning. It identifies base and target as currency codes, provides defaults (EUR, USD), and gives examples (EUR/USD, GBP/JPY). This significantly aids understanding, though not listing all supported currencies is a minor gap.

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

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

The description clearly states the tool retrieves the latest ECB reference exchange rate for a currency pair. It specifies the verb 'Get', the resource 'ECB reference exchange rate', and the scope 'currency pair'. The mention of cross-rate computation and examples further clarifies its purpose, distinguishing it from siblings like fx_rate_history or fx_volatility.

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 explains how non-EUR pairs are computed, giving context on usage. However, it does not explicitly state when to use this tool versus alternatives like fx_rate_history or fx_timing_advisor. The guidance is clear but lacks explicit exclusions or when-not-to-use conditions.

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

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

With no annotations, the description provides behavioral context: rates are published on weekdays. It describes the parameter range and gives examples but does not mention output format or any limitations beyond the days range, though an output schema exists.

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 summary, a behavioral note, a parameter list with Args, and two examples. Every sentence adds value, and there is no unnecessary verbosity.

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 3 optional parameters and an output schema. The description covers purpose, parameters, and a behavioral note. It does not explain the output format, but the existence of an output schema mitigates that need. It is fairly complete for a simple data 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 coverage is 0%, and the description fully compensates by explaining each parameter: 'base' and 'target' as ISO 4217 currencies, 'days' as 1-365 with default 90. This adds significant meaning beyond the schema's type and defaults.

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,' specifying the source (ECB), resource (exchange rates), and action. This distinguishes it from siblings like 'fx_rate' (current rate) and 'fx_timing_advisor'.

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 notes that 'ECB publishes rates on weekdays only (no weekends/holidays),' which informs usage expectations. However, it does not explicitly state when not to use this tool or suggest alternatives like 'fx_rate' for current rates.

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 that payments arriving outside market hours are delayed, and that executing during peak windows reduces costs. It mentions restricted currencies. It doesn't cover potential side effects like network latency or cache behavior, but it is transparent enough for typical usage.

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 bullet points, clear sections, and examples. It is concise without being terse, and 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?

The tool has an output schema (evidenced by context signals), so return values are covered. The description provides a complete picture of purpose, usage, and behavior for a timing advisor 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?

Despite 0% schema coverage, the description fully explains the parameter: pass a currency code for optimal window, omit for all sessions and overlaps. Examples show usage with various currencies, compensating well for the lack of schema detail.

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: to get FX trading windows, essential for understanding conversion delays and optimal execution timing. It distinguishes itself from sibling tools like fx_rate and fx_volatility by focusing on timing windows rather than rates or volatility.

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 use the tool, with specific use cases (delay diagnosis and rate optimization). It contrasts passing a currency vs omitting it. However, it doesn't explicitly state when not to use it or provide alternatives, though the context is clear enough for an agent.

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, 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?

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?

With no annotations, the description discloses behavioral traits: case-insensitive parameter handling, alias resolution (T2/TARGET2), and that omitting system lists all or filters by currency. It does not explicitly state that it is a read-only operation, but the context implies it.

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, system list, usage guidance, parameter details, and examples. It is front-loaded and each sentence adds value, though it could be slightly more concise 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 the tool's complexity (multiple systems, optional parameters, existence of output schema), the description covers what the tool does and how to use it. It does not describe the output format, but an output schema exists to handle that. The examples and parameter explanations make it complete for agent 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 input schema has 0% description coverage, but the tool description compensates fully by explaining each parameter in detail, including examples and behavior (e.g., case-insensitivity, alias resolution). For parameters 'system' and 'currency', it provides clear semantics 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 starts with 'Get payment system cutoff times for major clearing systems,' which clearly states the verb and resource. It lists specific systems and distinguishes from sibling tools like 'bank_holidays' or 'fx_rate' by focusing 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?

The description provides explicit guidance on when to use specific filters (e.g., 'For same-day EUR guidance: filter by currency="EUR"') and explains parameter behavior (case-insensitivity, alias resolution). It lacks explicit when-not-to-use instructions but given the tool's focused purpose, the examples and parameter details adequately guide usage.

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?

No annotations are present, so the description carries the full burden. It thoroughly discloses what the tool returns, known data gaps, limitations (e.g., empty intermediaries), and authentication requirements. It also warns against inventing data or misinterpreting flags.

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: purpose, return value details, data gap warnings, next_steps, authentication, and examples. Every sentence adds value, and the length is justified by the tool's complexity.

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

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

Given the tool's complexity and the presence of an output schema (which need not be detailed in description), the description is fully complete. It covers all important aspects: behavior, data gaps, chaining, authentication, and examples, referencing siblings where appropriate.

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's 'Args' section adds crucial meaning: swift format and examples (e.g., 8 or 11 chars), currency ISO 4217 with examples, and api_key usage including alternative header passing. This fully compensates for the schema's lack of 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 correspondent banking / settlement instructions (SSI) for a bank, specifying that it returns correspondent banks, account numbers, and intermediary chains. It distinguishes from sibling tools like swift_lookup by noting when to use each.

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 guidance, including instructions for further lookups using ssi_lookup itself, data gap caveats (e.g., empty account numbers, preferred flags, intermediaries), and the need to inspect next_steps. It also mentions subscription requirements and how to get an API key.

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?

The description discloses the return values in detail: SWIFT/BIC code, name, city, country, institution type, GPI membership, sanctions status across 7 watchlists, and enriched bank profile. It also explains the behavior of the country parameter (accepts ISO codes or full names) and covers non-SWIFT institutions, providing full transparency without annotations.

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

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

The description is well-structured with a clear opening sentence, bullet points for return values, examples in code blocks, and no extraneous text. Every sentence serves a purpose, and the most important 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 3 parameters, no enums, and existing output schema, the description is comprehensive: it covers purpose, usage, parameters, return data, sibling differentiation, and provides illustrative examples. No significant 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 description adds significant meaning beyond the schema: it explains that 'query' can be a SWIFT/BIC, name, or partial name, and that 'country' accepts both 2-letter ISO codes and full English names. The examples demonstrate parameter usage. Although schema description coverage is 0%, the embedded parameter guidance is thorough.

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

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

The description opens with a clear statement: 'Search banks and financial institutions by name, SWIFT/BIC code, or country.' It explicitly distinguishes from sibling tools by advising to use SSI tools for correspondent banking relationships and settlement instructions, covering both SWIFT and non-SWIFT institutions.

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 guidance on when to use this tool versus alternatives (e.g., 'For correspondent banking relationships and settlement instructions, use the dedicated SSI tools instead.'). It includes multiple examples covering various use cases such as exact BIC lookup, name search, non-SWIFT institution search, and country-specific exploration.

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.