Server Quality Checklist

Tool Scores

• remediate_messageC
  2.7/5.0
  Behavior1/5

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

  Annotations declare readOnlyHint=true, implying no modification, but the description discusses applying operations and returning patched XML when apply=true, which contradicts the annotation. The description does not reconcile this inconsistency.

  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 with a clear summary and parameter list. No fluff, but structure is functional rather than optimized for quick scanning.

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

  Completeness2/5

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

  Given the contradiction and lack of detail about what remediation entails (e.g., adding tags, modifying content), the description feels incomplete. Output schema exists but doesn't compensate for behavioral gaps.

  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 schema fully documents parameters. The description adds context about the default policy and applying operations, but otherwise repeats schema info without significant added meaning.

  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 assesses and remediates every addressed party in a message. It distinguishes from sibling tools like assess_address and remediate_address by operating on the whole message, but it does not explicitly differentiate from assess_message or provide a sibling comparison.

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

  Usage Guidelines2/5

  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 such as assess_message or remediate_address. The description mentions default policy and assessment date but does not contextualize usage scenarios or prerequisites.

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

• explain_findingA
  3.5/5.0
  Behavior3/5

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

  Annotations already mark readOnlyHint and idempotentHint as true, and destructiveHint as false. The description adds that it also explains how to resolve the finding, which provides additional 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.

  Conciseness4/5

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

  Two sentences: one conveying the core purpose and one listing the parameter. Information is front-loaded and no waste, though the 'Args:' section is somewhat redundant with the schema.

  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 one-parameter tool with an output schema, the description adequately covers purpose and resolution behavior. Could mention prerequisites or data source but is sufficient given low complexity.

  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 clear description of the 'code' parameter including an example. The description's 'The finding code to explain' adds minimal new meaning, returning to baseline 3.

  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 specific verbs 'explain' and 'resolve' with the resource 'finding code', clearly distinguishing it from sibling tools that assess or remediate.

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

  Usage Guidelines2/5

  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 assess_address or assess_message. The description only states what it does without contextual usage hints.

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

• remediate_addressA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds what the tool returns (findings, before/after, patch operations) and explains parameters. No contradictions, but no additional behavioral traits 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?

  Description is short and front-loaded with the main purpose. The Args section is succinct. No unnecessary repetition.

  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?

  Output schema exists, so return values are covered. Annotations and schema provide safety context. However, usage guidance is missing, which would improve completeness.

  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 the description's Args section adds informal examples (e.g., address format with street_name, building_number). This adds some value, but the schema already provides detailed descriptions for all parameters.

  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?

  Clearly states it proposes the compliant form of an address with explained changes. Verb+resource is specific. However, it does not differentiate from sibling tools like assess_address which might also check compliance.

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

  Usage Guidelines2/5

  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 assess_address or classify_address. The description only explains parameters, not usage context.

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

• assess_addressA
  3.6/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. The description adds no behavioral traits beyond these, so it meets the baseline but does not exceed it.

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

  Conciseness3/5

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

  The description is structured and front-loaded, but the Args section is somewhat repetitive of the schema. At 165 words, it is adequately concise but not tight.

  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 existence of an output schema, the description does not need to explain return values. All parameters are documented, and the description adds useful context about defaults and address format. The complexity (4 parameters, nested objects) is well-covered.

  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 description's Args section largely duplicates schema info. It adds minor value like default values and address format hints, but not enough to raise the score above the baseline.

  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 'Score' and the resource 'a single address against a policy', and mentions 'return its findings'. This distinguishes from siblings like classify_address and list_policies.

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

  Usage Guidelines3/5

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

  The description implies usage for scoring addresses and mentions list_policies for policy reference, but does not explicitly state when to use this tool versus alternatives like assess_message or classify_address.

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

• preview_patchA
  3.6/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces this by explicitly stating it is a 'dry run', meaning no side effects. This adds behavioral context beyond annotations, clarifying the tool's non-destructive nature.

  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 short and to the point, with a clear one-sentence purpose followed by a bulleted list of arguments. No redundant information. It is appropriately sized and well-structured, though it could be slightly more concise by removing the 'Args:' label.

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

  Completeness3/5

  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), the description does not need to explain return values. However, the description does not hint at the output format (e.g., list of operations). For a tool that returns patch operations, some context on the structure would improve completeness. Overall adequate but not fully 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 description coverage is 100%, so the schema already documents all parameters. The description's parameter explanations closely mirror the schema descriptions (e.g., 'The ISO 20022 message document' vs 'An ISO 20022 message as XML'). The value added over the schema is minimal, so a baseline score 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 starts with 'Return the patch operations remediation would apply (a dry run).' This clearly states the tool provides a dry-run preview of remediation patches. The verb 'preview' and resource 'patch' are unambiguous, and the tool is distinguished from siblings like 'remediate_message' which applies the patch.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. Sibling tools like 'assess_message' and 'remediate_message' exist, but no comparison or context is provided. Users are left to infer the appropriate use case for a dry run vs actual remediation.

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

• parse_address_libpostalA
  4.1/5.0
  Behavior5/5

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

  The description adds substantial behavior beyond the annotations: it discloses the optional libpostal C library dependency, the fallback regex path, the 'parser' field that reports which path ran, and that it runs purely on CPU with no network or filesystem access. This is rich, useful context that the annotations alone do not provide.

  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 well-structured and front-loads the core purpose, with separate sentences for behavior, output mapping, and operational constraints. It is slightly longer than strictly necessary because the Args and Returns sections partially duplicate the schema and output schema, but every section remains readable and purposeful.

  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 strong annotations, full schema coverage, and existing output schema, the description is complete enough for an agent to call this tool correctly. It covers input requirements, fallback behavior, dependency constraints, and output shape, leaving no critical gap for safe 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 description coverage is 100%, so the schema already fully documents both parameters. The description's Args section largely restates the schema's meaning without adding significant new detail, so it does not elevate the parameter semantics beyond the baseline.

  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 a specific verb and resource: 'Parse a free-text address into ISO 20022 postal fields.' It also lists the concrete output fields (StrtNm, BldgNb, PstCd, TwnNm, Ctry), making the operation easy to understand. It does not explicitly contrast with sibling tools such as classify_address or assess_address, so it falls short of a 5.

  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 gives clear context: this tool is for parsing a free-text address into structured postal fields, and it explains that it can run with libpostal or fall back to regex heuristics. It does not explicitly state when to use this tool instead of sibling tools or when not to use it, so it lacks exclusions or alternative routing.

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

• assess_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, so the safety profile is clear. The description adds that it assesses every addressed party and specifies default behavior, which is consistent with annotations and provides context beyond them.

  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 extremely concise: three sentences for purpose and an argument list. It is front-loaded with the core action and contains no unnecessary words.

  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 simple parameter set and presence of an output schema, the description covers the essential aspects: supported message types, defaults, and core function. It does not mention preconditions or error handling, but this is acceptable given the output schema.

  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%, so parameters are well-described. The description adds value by specifying that the xml parameter must be a pacs.008 or pain.001 message, and clarifies defaults for policy_id and as_of. This complements the schema without redundancy.

  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 action ('assess'), the specific resource ('every addressed party in a pacs.008 / pain.001 message'), and distinguishes itself from siblings like assess_address (single address) and remediate_message (modification).

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

  Usage Guidelines3/5

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

  The description implies usage when assessing a pacs.008 or pain.001 message, but does not explicitly state when to use this tool versus siblings like assess_address or remediate_message. No when-not-to-use guidance is provided.

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

• classify_addressA
  4.3/5.0
  Behavior3/5

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

  Annotations already cover readOnlyHint, idempotentHint, destructiveHint. The description adds minimal new context ('quick shape check'), but does not contradict annotations. Since annotations are comprehensive, a score of 3 is appropriate.

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

  Conciseness5/5

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

  Description is short and front-loaded with the main purpose. It includes a clear usage guide and an Args section. Every sentence is essential; no wasted 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 the simple tool (one parameter, classification output), the description fully covers what an agent needs: purpose, usage context, and alternative. Output schema exists but is not required to be explained.

  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% with a detailed explanation of the 'address' parameter. The description simply restates 'The postal address to classify,' adding no new meaning. Baseline of 3 applies.

  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 'Classify a postal address as structured, hybrid, or unstructured.' The verb 'classify' and the specific categories make the purpose precise. It also distinguishes from sibling assess_address by indicating a quick shape check.

  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 says 'Use this for a quick shape check before deciding whether to remediate.' and contrasts with 'For specific compliance findings, use assess_address instead.' This provides clear when-to-use and an alternative, meeting the highest standards.

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

• split_street_and_buildingA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent annotations, the description discloses concrete parsing behavior: support for both numbering conventions, optional sub-building markers, null outputs when absent, and never returning an error for a missing building number. This is exactly the kind of non-obvious behavior an agent needs.

  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 compact, front-loaded with the operation, and uses a clear Args/Returns structure. Every sentence adds either input semantics, output semantics, or edge-case behavior.

  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 single-parameter pure function with full schema coverage and annotations, the description covers input, output shape, null conventions, and edge cases. The existing output schema also covers return values, so nothing necessary is missing.

  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% and the schema already names the parameter with examples. The description's Args line adds little beyond restating that street_line is free-text to split, so the baseline of 3 applies.

  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?

  States a specific verb ('split'), resource ('street line'), and the three output components. It clearly distinguishes itself from sibling address tools by focusing on splitting into street_name, building_number, and sub_building.

  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 gives clear context for when it applies by naming the two numbering conventions and the no-building-number case, so an agent can recognize the right input shape. It does not explicitly compare against siblings such as parse_address_libpostal, but no misleading guidance is given.

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

• get_cutover_dateA
  4.6/5.0
  Behavior5/5

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

  Beyond the readOnly and idempotent annotations, the description discloses that ``date`` is None, that null is intentionally preferred over a withdrawn date, and that ``status`` is deferred rather than withdrawn. This is valuable behavioral context that prevents the agent from fabricating a date or mischaracterizing the 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?

  The purpose is front-loaded in the first sentence, and the subsequent paragraphs earn their place by explaining the deferral, the null semantics, and the domestic-scope caveat. It is wordier than a simple lookup might need, but no sentence is filler given the nuanced context the agent must understand.

  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 zero parameters, existing annotations, and an output schema, the description supplies everything else needed: the current status, why the date is null, that the requirement stands, and how far the deferral extends. An agent can select, invoke, and interpret this tool correctly from the definition alone.

  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 input schema has zero parameters, so there is nothing for the description to enrich on the input side. The description's references to ``date`` and ``status`` concern the output, and the empty schema already has full coverage.

  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 first sentence, 'Report when the structured-address requirement binds, if it yet does,' names a specific action and resource, and the title ties it to the ISO 20022 cutover date. This clearly identifies what the tool does without ambiguity and separates it from the address-mutation and validation siblings.

  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 draws an explicit scope boundary: the deferral is Swift's and covers CBPR+, while domestic market infrastructures set their own timing. It advises checking the relevant schemes rather than assuming they moved with Swift, which gives the agent useful when-not guidance, though no alternative tool is named.

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

• list_policiesA
  4.7/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, so the safety profile is clear. The description adds the return format (list of objects with id, title, tier), which is useful. No side effects or auth needs are mentioned, but none are expected for a read-only list. 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 extremely concise: two sentences with a brief example list. Every sentence adds value, and the most important usage guidance is placed first.

  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 that there is an output schema (though not shown), the description provides a summary of return values. The tool is simple with no parameters, and the description covers purpose, usage, and output format sufficiently.

  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 input schema has no parameters and 100% description coverage. The description does not need to add parameter details. Baseline 4 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 that the tool lists all available address policies with their tier. It uses specific verbs ('list') and resource ('address policies') and distinguishes from sibling tools which are about classification, assessment, and remediation.

  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?

  It explicitly tells the agent to use this tool first to discover policy_id values for other tools, providing concrete examples like 'cbpr-2026' and 'sepa'. This offers clear when-to-use guidance.

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

• normalize_country_codeA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent annotations, the description discloses important behavior: matching is case-, accent-, and punctuation-insensitive, and unmatched input yields an error object rather than throwing or guessing. This gives the agent accurate expectations about edge cases.

  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: a one-sentence definition, accepted inputs, matching behavior, an Args section, and a Returns section. Every sentence earns its place and the most important purpose is 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?

  For a simple one-parameter lookup tool with annotations and an output schema, the description covers purpose, accepted input variety, normalization rules, and error behavior. Nothing needed for correct invocation is missing.

  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 schema already fully documents the single parameter with examples, so the baseline is 3. The description adds meaning by clarifying normalization behavior and by listing the broader categories of accepted aliases, which helps the agent craft valid inputs.

  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 opening sentence uses a specific verb and resource: 'Resolve a country name or code to its ISO 3166-1 alpha-2 code.' It clearly distinguishes itself from the address/message-related sibling tools by domain and by stating its exact transformation.

  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 clearly identifies what inputs are accepted (English names, local endonyms, aliases, 2/3-letter codes) and what happens on failure. It does not name an alternative tool or explicitly say 'use this when,' but its acceptance criteria make the intended use unambiguous.

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

• validate_postal_policyA
  4.7/5.0
  Behavior5/5

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

  The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: it states that only post_code is inspected, and that unknown country or missing post_code returns non-compliant with a descriptive error rather than raising. This is exactly the kind of extra behavioral context that helps an agent.

  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: a one-sentence summary, a compact list of supported policies, a scope note, and a clear Args/Returns breakdown. Every sentence contributes operational knowledge 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.

  Completeness5/5

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

  For a validation tool with two required parameters, full schema descriptions, rich annotations, and an explicit return format, the description covers all essential operational details: supported formats, input shape, return keys, and error behavior. There is no significant missing information an agent would need to invoke it correctly.

  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 schema has 100% parameter description coverage, so the baseline is 3. The description adds meaningful value by enumerating the exact country code formats (e.g., US 5-digit ZIP or ZIP+4, GB alphanumeric) and emphasizing that only the post_code field of the address is considered. This supplements the schema descriptions usefully.

  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 opens with a specific verb-resource pair: 'Validate an address's post_code against a country's format policy.' It also clarifies the exact scope (only post_code is inspected) and lists the supported country policies, making the tool's role distinct from siblings like assess_address or remediate_address.

  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 clearly states the supported policies (US, GB, DE, FR, JP) and the condition of the tool—it only inspects post_code, not other address fields. It gives adequate context for when to use it, but it does not explicitly mention alternatives or state when not to use it relative to sibling tools.

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