Server Quality Checklist

Tool Scores

• repair_addressA
  4/5.0
  Behavior4/5

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

  Annotations indicate read-only, idempotent, non-destructive behavior. The description adds transparency about experimental status, country-specific heuristics, return structure (address/classification/is_structured/is_hybrid/error), and the need for auditing. No contradictions with annotations.

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

  Conciseness4/5

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

  The description is structured with a title, usage note, return information, and args list. It is informative but not overly verbose. Slightly longer than necessary, but front-loaded with key purpose and usage.

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

  Completeness5/5

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

  For a simple 2-parameter tool with full schema coverage and no output schema, the description comprehensively covers the return value, usage context, and behavioral notes. It is complete for an AI agent to understand and invoke correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% for both parameters. The description's parameter explanations largely mirror the schema, adding minimal extra meaning. Baseline 3 is appropriate as the schema already carries the descriptive burden.

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

  Purpose4/5

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

  The description clearly states it upgrades legacy unstructured address lines to hybrid/structured form, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like classify_address, though the transformation focus is different.

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

  Usage Guidelines4/5

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

  The description provides explicit usage guidance: use for pre-cliff data upgrade, audit output, and keep both versions. It also notes the experimental nature and country-specific heuristics. No explicit when-not-to-use or alternative tools mentioned, but the guidance is clear.

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

• validate_addressesA
  4/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only and idempotent. The description adds context about the return format (structured error list per (row, party)) and the policy enforcement date, enhancing transparency beyond annotations.

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

  Conciseness4/5

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

  The description is concise and well-structured, with a summary, usage note, and return format. The Args section is slightly redundant but does not detract significantly from clarity.

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

  Completeness4/5

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

  Given the tool's complexity (batch validation, multiple parties, policy implications), the description covers purpose, usage, and output format. It lacks edge cases but is sufficiently complete for the given context.

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

  Parameters4/5

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

  With 100% schema coverage, the description adds meaningful detail: it explains the address parameter expects columns like '{party}_address_{field}' and lists valid parties, and it clarifies the policy enum values in context of the validation cliff.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Batch-validate every party address across a list of payment rows.' It distinguishes from the singular 'validate_address' sibling by emphasizing batch processing, though it does not explicitly name the sibling.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance: 'Use this before generate_message to catch addresses that will be rejected at the rail.' It also explains the default policy and the November 14, 2026 cliff, but does not specify when not to use it or compare with other validation tools.

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

• parse_messageA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, which align with the description's parse/classify nature. The description adds behavioral details such as handling both bare Document and BAH-wrapped envelopes, and lists return fields, providing context beyond annotations.

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

  Conciseness5/5

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

  The description is concise (approx 100 words), front-loaded with the purpose, and well-structured with an intro and argument section. No fluff.

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

  Completeness4/5

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

  Despite no output schema, the description lists all return fields. It covers handling of both bare and BAH-wrapped messages. For a single-parameter parse tool with good annotations, this is fairly complete.

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

  Parameters3/5

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

  Schema coverage is 100% with a detailed description of the 'xml' parameter. The description's Args section repeats this information without adding significant new details. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'Parse and classify' and the resource 'inbound ISO 20022 XML message'. It lists specific output fields and distinguishes from siblings like generate_message and validate_xml by focusing on identification before processing.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use this on the receiving side to identify what a message is... before processing it.' This gives clear context. It implies not to use for generation or validation, but does not explicitly name alternatives.

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

• get_input_schemaA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds the 'flat' aspect of the input record and that it returns the full JSON Schema, but does not elaborate further on behavioral traits beyond what annotations provide.

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

  Conciseness5/5

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

  Concise: three main sentences plus an Args section. Front-loaded with purpose. No extraneous information; every sentence earns its place.

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

  Completeness5/5

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

  Given the tool complexity (single parameter, rich annotations, no output schema), the description is complete. It covers what the tool does, when to use it, and how it relates to siblings. The return value is implied as a JSON Schema object.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. Description provides a concrete example ('e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer') which adds some value beyond the enum list, but overall does not significantly enhance meaning beyond the schema.

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

  Purpose5/5

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

  Description states 'Return the full JSON Schema for a message type's flat input record' with specific verb and resource. It distinguishes from siblings such as get_required_fields and validate_records, clearly differentiating its purpose.

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

  Usage Guidelines5/5

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

  Explicitly states when to use ('to learn every field... or to drive a form/UI') and when not to use ('For just the required-field names use get_required_fields; to check records against this schema use validate_records'). Provides clear context and alternatives.

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

• validate_addressA
  4.3/5.0
  Behavior5/5

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

  Annotations indicate read-only and idempotent. The description adds behavioral context: it returns a structured result with policy, classification, acceptability, and findings, and explains the policy behavior and cliff rule. No contradictions with annotations.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose and well-structured. However, it is slightly verbose, especially the policy explanation, which could be shortened.

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

  Completeness4/5

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

  Given no output schema, the description compensates by listing the return fields and explaining the policy. It covers the main use case but lacks details on error handling and edge cases.

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

  Parameters3/5

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

  Schema coverage is 100%, so the description adds minimal extra meaning. It mentions 'snake_case fields' for the address and refers to enum values for policy, but these are already in the schema.

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

  Purpose5/5

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

  The description clearly states the tool validates a single postal address against a policy. It specifies the exact resource and action, and distinguishes from sibling tools like validate_addresses and classify_address by its singular focus.

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

  Usage Guidelines4/5

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

  The description explains when to use the tool ('decide whether an address will clear a rail') and mentions the default policy. However, it does not explicitly compare with siblings or state when not to use it, leaving some ambiguity.

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

• convert_mt103A
  4.4/5.0
  Behavior5/5

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

  Discloses that the tool parses MT103 text, always returns a single record, no file I/O, and error cases when mandatory fields are missing. Annotations already indicated readOnly and idempotent, but the description adds specifics about return format and 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.

  Conciseness4/5

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

  Description is front-loaded with purpose, followed by context and details. Slightly long due to background info on coexistence deadline, but every sentence is relevant. Could be trimmed slightly but still efficient.

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

  Completeness5/5

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

  Given the complexity of a conversion tool with no output schema, the description fully covers return format, error scenarios, and integration with sibling tools. No gaps are identified.

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

  Parameters3/5

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

  Single parameter mt103_text is fully described in the schema (100% coverage). The description repeats the parameter name and type ('The MT103 payload as a string') but adds no new details beyond the schema's already thorough description.

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

  Purpose5/5

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

  Clearly states it converts MT103 to pacs.008 records, specifying verb and resource. Distinguishes from siblings like validate_records and generate_message by mentioning these as downstream tools. No ambiguity.

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

  Usage Guidelines4/5

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

  Provides explicit context: SWIFT MT-to-MX migration path with a deadline (Nov 2025), and states the output feeds into validate_records/generate_message. Does not explicitly state when not to use or name alternatives, but the usage scenario is clear.

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

• validate_schemeA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds behavioral context by detailing the specific rules checked (charge bearer, UETR, remittance length, cardinality) and the return format including 'is_valid', 'total', and 'violations'. This adds value beyond the annotations.

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

  Conciseness5/5

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

  The description is concise and well-structured, with a clear introductory sentence, usage guidance, a bullet-like list of rule types, and an Args section. Every sentence adds value without redundancy.

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

  Completeness4/5

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

  Given the tool's complexity (2 params, high schema coverage, no output schema, good annotations), the description is nearly complete: it covers purpose, usage, return format, and parameter details. Minor gaps exist (e.g., error conditions, violation structure), but overall it adequately prepares the agent.

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

  Parameters4/5

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

  Schema coverage is 100%, with descriptions for both parameters. The description goes further by explaining the 'records' parameter as 'one or more flat payment records' and the 'scheme' parameter as a registered profile name from 'list_schemes'. It also lists example rule types, adding context beyond the schema enum.

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

  Purpose5/5

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

  The description clearly states the verb and resource: 'Validate payment records against a scheme's usage-guideline rules.' It distinguishes from the sibling tool 'validate_records' by noting it is complementary. The purpose is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly says to 'Use this to check a batch against a rail's rulebook' and lists example schemes. It also mentions it is complementary to 'validate_records', providing context for when to use this tool over alternatives. However, it stops short of explicitly stating 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.

• validate_xmlA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety profile is clear. The description adds valuable behavioral context: that validation is against a bundled XSD, and it specifies the return format. 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.

  Conciseness5/5

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

  The description is concise, with two short paragraphs that front-load the purpose and usage guidelines, followed by return format and args. Every sentence adds value with no redundancy or fluff.

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

  Completeness4/5

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

  For a simple two-parameter validation tool with full schema coverage and safety annotations, the description is quite complete. It specifies the return format, which is helpful given no output schema. Minor omission: no mention of error behavior (e.g., if XML is malformed), but this is not critical for a validation tool returning a boolean.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters are well-described in the schema with detailed enum and description. The description's Args section essentially repeats the schema information without adding new meaning, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'Validate' and the resource 'raw XML string against a message type's bundled XSD'. It differentiates itself from the sibling tool 'generate_message' by explicitly contrasting validation with generation.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool ('check an externally produced XML document against the official ISO 20022 schema') and when not to ('To generate a document that is already XSD-validated, use generate_message instead'). This provides clear guidance with an alternative.

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

• get_schemeA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral detail by listing the specific rule attributes returned (e.g., UETR mandatory, charge bearers), which is valuable for an AI agent even though no 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.

  Conciseness5/5

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

  The description is concise and well-structured: a one-line summary, a detailed usage paragraph, and a parameter section. Every sentence adds value, and it is front-loaded with the core purpose.

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

  Completeness5/5

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

  Given the tool's simplicity (1 parameter, no nested objects), the description is complete. It explains the return content (rule attributes), references a sibling (list_schemes) for getting scheme names, and provides sufficient context for an AI agent to use it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description in the tool adds a cross-reference to list_schemes and restates the parameter's purpose, providing slight extra value but not substantially beyond the schema.

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

  Purpose5/5

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

  The description clearly states it returns 'the rule attributes of a scheme / usage-guideline profile' and lists specific constraints (UETR mandatory, charge bearers, etc.). It distinguishes from siblings like list_schemes (which returns names) and validate_scheme (which validates) by specifying it inspects the rail's constraints before assembling or validating.

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

  Usage Guidelines5/5

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

  The description explicitly says when to use this tool: 'Use this to inspect a rail's constraints... before assembling or validating a batch.' It also provides an alternative by referencing 'list_schemes' for getting registered scheme names.

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

• validate_recordsA
  4.5/5.0
  Behavior4/5

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

  Description adds row-by-row error report and scope (JSON-Schema shape only) beyond annotations (readOnly, idempotent). No contradiction; transparency is strong.

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

  Conciseness5/5

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

  Concise two-paragraph structure with front-loaded purpose and bullet for return format. Every sentence adds value.

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

  Completeness5/5

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

  With full schema coverage, annotations, and clear return format description, the tool is fully specified for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline 3. Description repeats parameter info from schema but adds no significant new meaning; minimal added value.

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

  Purpose5/5

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

  Description clearly states it validates flat payment records against a message type's JSON Schema. The verb 'validate' and resource 'records' are specific. It distinguishes from siblings like generate_message and validate_scheme.

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

  Usage Guidelines5/5

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

  Explicitly advises using this before generate_message and mentions validate_scheme as alternative for rail-level checks. Provides clear context for when to use.

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

• classify_addressA
  4.7/5.0
  Behavior4/5

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

  Annotations already indicate safe read-only behavior; the description adds return structure and classification meanings. Could detail error triggers, but sufficient for typical use.

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

  Conciseness5/5

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

  Well-structured: brief purpose sentence, then two concise paragraphs covering usage and return. No unnecessary words.

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

  Completeness5/5

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

  Given no output schema, description fully specifies return fields (classification, bools) and error payload. Contextual completeness is high.

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

  Parameters4/5

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

  Schema provides 100% coverage with description of the address dict; the tool description adds a practical example, enhancing understanding beyond the schema alone.

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

  Purpose5/5

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

  The description clearly states the tool classifies a postal address into structured, hybrid, or unstructured, and distinguishes it from siblings like validate_address and repair_address.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use (assess against SWIFT cliff) and when-not-to-use (acceptability: validate_address; upgrade: repair_address) with precise definitions.

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

• get_required_fieldsA
  4.7/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds context that this tool is a safe, read-only operation that returns field names. No contradictory information.

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

  Conciseness5/5

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

  The description is concise: one line for purpose, clear usage guidance, and parameter explanation. It is front-loaded and every sentence adds value.

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

  Completeness5/5

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

  For a simple tool with one parameter and an output schema (indicated), the description adequately covers purpose, usage, and parameter. No gaps.

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

  Parameters4/5

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

  Schema coverage is 100% with an enum and description. The description adds value by explaining the message_type parameter's purpose, providing an example format, and referencing list_message_types for available types.

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

  Purpose5/5

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

  The description states 'List only the required input field names for a pacs message type', which clearly identifies the verb (list) and resource (required field names). It distinguishes from the sibling tool get_input_schema by specifying that this tool only provides required fields, not full type/format constraints.

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

  Usage Guidelines5/5

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

  Explicitly provides when to use: 'Use this for a quick checklist of the mandatory columns before building payment records.' Also tells when not to use and directs to an alternative: 'For full type/format constraints... call get_input_schema instead.'

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

• list_message_typesA
  4.7/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by specifying the return format a list of dictionaries with message_type and name, and implies no side effects. 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.

  Conciseness5/5

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

  Four sentences, each serving a purpose: main action, usage guidance, alternate tool references, and return structure. No extraneous content, properly front-loaded.

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

  Completeness5/5

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

  Given the tool's simplicity (no parameters, read-only listing) and the existence of an output schema, the description is complete. It summarizes the return structure and how to use the tool in a workflow.

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

  Parameters4/5

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

  The tool has zero parameters, so the input schema is trivial. Schema description coverage is 100% (no parameters). Baseline for 0 parameters is 4, and no additional param information is needed.

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

  Purpose5/5

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

  The description clearly states 'List every supported ISO 20022 pacs message type and its human name,' using a specific verb ('List') and resource ('pacs message types'). It distinguishes from sibling tools by noting that for required fields or schema, one should use other tools.

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

  Usage Guidelines5/5

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

  Explicitly advises to use this tool first before generation or validation to discover accepted message_type strings. It also directs to get_required_fields or get_input_schema for further details, providing 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.

• list_schemesA
  4.7/5.0
  Behavior5/5

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

  Describes alias collapsing behavior and uniqueness of profiles, adding context beyond annotations (readOnlyHint, idempotentHint). No contradiction with annotations.

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

  Conciseness5/5

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

  Four concise sentences with front-loaded purpose, efficient use of examples, and no redundant information.

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

  Completeness5/5

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

  Given no parameters and presence of output schema, the description fully covers tool behavior, return format, and purpose without gaps.

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

  Parameters4/5

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

  No parameters exist (schema coverage 100%). Description adds value by explaining return format and behavior, meeting the baseline for 0-parameter tools.

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

  Purpose5/5

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

  Explicitly states 'List every registered scheme / usage-guideline profile' and elaborates with examples of scheme profiles. Clearly distinguishes from sibling tools by noting it discovers scheme names used by get_scheme and validate_scheme.

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

  Usage Guidelines4/5

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

  Directly advises to use this tool to discover scheme names accepted by get_scheme and validate_scheme. Implicitly distinguishes from other siblings like validate_scheme itself, but does not explicitly 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.

• verify_bic_onlineA
  4.7/5.0
  Behavior5/5

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

  Adds extensive behavioral context beyond annotations: two-stage process, offline check details, directory lookup being read-only HTTP GET, no free authoritative directory, never fabricates bank name, graceful error handling, and pip install requirement.

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

  Conciseness4/5

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

  Description is longer but well-structured with clear sections. Front-loaded with purpose. Each sentence adds necessary detail; no redundancy.

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

  Completeness5/5

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

  Covers all operational aspects: malformed input, offline-only mode, missing online extra, endpoint errors, return value structure. No output schema needed given the detailed description.

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

  Parameters5/5

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

  Schema coverage is 100% but description adds significant value: bic stripping/uppercasing, directory_url usage with query parameter and env var fallback, and clear note about no default/public directory.

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

  Purpose5/5

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

  Title and first sentence clearly state it verifies a BIC structurally and optionally with directory lookup. Distinct from sibling tools (no other BIC verification tool).

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

  Usage Guidelines4/5

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

  Describes two-stage verification, conditions for online lookup, dependency on optional extra and environment variable, and fallback behavior. Lacks explicit exclusion statements or named alternatives, but context is clear.

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

• generate_messageA
  5/5.0
  Behavior5/5

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

  Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns validated XML as a string or error payload, and that no file is written, providing further behavioral context beyond annotations.

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

  Conciseness5/5

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

  The description is well-structured with a clear purpose, bullet-like usage guidelines, and an Args section. Every sentence adds necessary information without redundancy.

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

  Completeness5/5

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

  Given the tool's complexity, the description covers prerequisites (validate_records, list_message_types), behavior (no file written), output (XML string or error), and parameter usage. Output schema exists but description still clarifies return value.

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

  Parameters5/5

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

  Schema coverage is 100% with descriptions for both parameters. The description adds value by clarifying that records must be flat payment records and advising to run validate_records first, complementing the schema info.

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

  Purpose5/5

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

  The description uses a specific verb ('Generate') and resource ('validated ISO 20022 pacs XML message from in-memory records'), clearly distinguishing it from sibling tools like validate_records and list_message_types.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: after running validate_records and list_message_types. Also clarifies that no file is written, guiding the agent on behavioral expectations.

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