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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description details the tool's behavior: it walks the payload, reports issues, returns a structured dictionary with error envelopes for malformed input, and specifies the pre-flight checks (DOCTYPE/ENTITY/oversized). 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.

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

The description is detailed and well-structured with bullet points and bold text, but it is somewhat lengthy. Every sentence adds value, but it could be slightly more concise without losing 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?

With no output schema, the description fully explains the return structure (dictionary with keys like cbpr_ready, schema_version, issues, etc.) and covers error cases. The single parameter is well-documented, and all behavioral aspects are addressed.

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

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

The schema description coverage is 100%, but the description adds value by explaining the pre-flight rejection criteria and the audit context (e.g., 'audited against the CBPR+ Nov 2026 acceptance rules'). This goes beyond the schema's simple 'raw XML document' description.

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 checks a camt.053 statement against CBPR+ Nov 2026 acceptance rules. It uses a specific verb-resource pair ('check a statement') and distinguishes itself from related tools like validate_statement and get_cbpr_cutover_date.

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

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

The description explicitly states when to use this tool (audit for business-rule changes) and provides alternative tools for other cases (validate_statement for XSD validity, get_cbpr_cutover_date for cutover date alone). It gives clear, actionable guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe. The description adds crucial behavioral context: the registry is a curated convenience layer, not a verbatim reproduction; always defer to source_url; the disclaimer field repeats this. This goes beyond annotations to explain limitations and usage boundaries.

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-organized into paragraphs with clear sections. It is concise (about 150 words) with no redundant sentences. Every sentence adds value: purpose, usage context, parameter guidance, and caveats. Front-loaded with the core action.

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 3 required params with full schema coverage, annotations, and no output schema, the description compensates by explicitly listing the return dict fields ('a citation dict {scheme, version, clause, title, summary, source_url, as_of, disclaimer}'). This gives the agent a complete picture of what to expect.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying case sensitivity for 'scheme', giving examples for 'version', and explaining that 'clause' should be a kebab-case identifier from list_rulebook_clauses. It connects parameters to the sibling tool, making the API more intuitive.

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: 'Return a curated payments-rulebook citation for a single clause.' It distinguishes itself from the sibling tool 'list_rulebook_clauses' by instructing the agent to use that first to discover clauses, showing a specific usage path.

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 this tool ('once you know the scheme/version/clause') and when not to ('To discover which clauses exist first, call list_rulebook_clauses'). It also provides guidance on deferring to the source URL for authoritative wording, which is critical for compliance.

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 provides significant behavioral context: it explains the open-world, non-idempotent nature, the delegation to the client via MCP Sampling (with privacy/billing/audit implications), the error envelope format, and the success/failure return structure. Annotations already provide openWorldHint=true, idempotentHint=false, and readOnlyHint=true, which the description aligns with and expands upon (e.g., mentioning the error envelope and the need for client support). The description adds value beyond annotations but does not explicitly cover failure modes like rate limiting or retry behavior, which is minor.

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 comprehensive but well-organized: it starts with a one-sentence summary, then adds usage context, a detailed protocol explanation, and finally structured Args/Returns sections. Every paragraph adds meaningful information without redundancy. The structure with clear section headers makes it scannable.

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

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

Given a 2-parameter tool with nested objects, complex behavioral implications (delegating to client via Sampling, error cases), and no output schema, the description covers everything an agent needs: input expectations, prerequisites, failure modes, return format, and the non-idempotent nature. The description is thorough and leaves no critical gaps 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 description coverage is 100%, with detailed descriptions for both parameters. The description adds significant context on top: it specifies the exact shape of 'entry' (as returned by parse_statement / list_entries), explains the meaning of 'categories' (including the default None behavior and the built-in default list), and describes the return payload structure. It also clarifies the relationship with list_classify_entry_categories. This goes well 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 verb (classify), the resource (one statement entry), and the mechanism (via MCP LLM Sampling). It distinguishes this from deterministic rule matching and explicitly contrasts with sibling list_classify_entry_categories. The purpose is immediately understandable.

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 this tool ('when you want a semantic, model-driven label rather than a deterministic rule match'), mentions an important prerequisite (call list_classify_entry_categories first to get the fixed categories), and describes fallback behavior for clients without Sampling support. This is exemplary 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?

Description adds value beyond annotations: explains library delegation, no disk I/O, error return format with specific examples. Annotations already declare read/hint/idempotent; description reinforces safety and adds technical detail.

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

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

Front-loaded with purpose, well-structured into migration context and technical details. Slightly verbose but every sentence earns its place. Could be tightened slightly.

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

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

Covers all relevant aspects: purpose, usage context, error handling, relationship to siblings, technical implementation. Lacks detailed output structure but references parse_statement's shape and mentions return type.

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

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

Schema coverage is 100% with a detailed description for the single parameter. Description's Args section mostly repeats the schema but adds context about expected MT940 fields. Baseline 3 appropriate.

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?

Verb 'convert' + specific resources 'legacy MT940' and 'camt.053' clearly state the tool's function. Distinguishes from sibling 'parse_statement' by framing as a migration wedge for legacy format.

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 recommends use as Phase-1 migration wedge with retirement date November 2028. States that downstream tools work on result unchanged, implying alternatives like 'parse_statement' for native camt.053.

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

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

Annotations declare idempotent, read-only, non-destructive. Description adds significant details: wraps library, delegates parsing, returns dict or error, no disk access, and documents the model limitation with proprietary type_code values.

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, front-loaded purpose. Slightly long due to detailed proprietary type_code explanation, but each 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?

Comprehensive for a tool with parsing complexity and model limitation. Covers output format, error cases, and integration with downstream tools despite no output schema.

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 covers 100% of the single parameter. Description adds meaning: specifies raw text format, lists expected field tags, and explicitly says no file path.

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 the tool converts MT942 to camt.052, with a specific verb-resource pair. Distinguishes from sibling tool convert_mt940_to_camt053 by explaining the mapping and use as a migration wedge.

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 describes the context as Phase-1 migration wedge for intraday reporting during the MT94x phase-out. Notes downstream tools. Lacks explicit when-not-to-use, 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.

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

Beyond the readOnly/idempotent annotations, the description adds meaningful behavioral detail: it never calls a model or network, is deterministic, applies three fixed heuristics with severity levels, and returns an error payload on unparseable XML. This gives the agent a precise model of what the tool will and will not do.

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 detailed but tightly organized: purpose, usage context, deterministic guarantee, three bulleted heuristics, and return shape. Every sentence adds necessary information, and the bullet list makes the heuristic rules easy to scan.

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 no output schema, the description fully specifies the return payload shape, including the empty-anomalies case and the error case. It also references list_entries for context and documents the single input parameter via the schema, making the tool complete 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 already covers the single parameter fully, including the requirement for raw XML with a root camt <Document> element and the exclusion of file paths. The description's Args section mostly restates this, adding no new parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Screen a camt.05x statement for deterministic, rule-based anomalies.' It clearly distinguishes this from sibling tools like parse_statement, validate_statement, and classify_entry by framing it as a fast, explainable first-pass anomaly detector over parsed entries.

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 it: 'as a fast, explainable first pass over an incoming statement before deeper review or reversal.' It does not name specific alternative tools or state when not to use it, but the context is clear enough for an agent to select it appropriately.

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 adds significant behavioral detail beyond annotations: it clarifies the tool does not call external APIs nor write files, describes the per-target output structure (Xero BankTransactions, QBO JournalEntry), explains placeholder fields, and notes unsupported targets. This fully compensates for the lack of detailed 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 structured with a clear purpose first, followed by usage note, target details, and return format. It is slightly lengthy but every sentence contributes value. No unnecessary repetition.

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 two parameters and lack of output schema, the description fully specifies the input, output structure (including fields like placeholder_count), constraints (unsupported targets), and prerequisites. It leaves no ambiguity for an agent invoking the 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 100%, so baseline is 3. The description adds value by explaining the behavior per target, the placeholder concept, and that valid target values can be discovered via a sibling tool, going beyond the enum list in the schema.

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

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

The description clearly states it exports a camt.053 statement as journal-entry payloads. It distinguishes itself by noting it does not call external APIs or write files, and it references the sibling tool 'list_export_journal_targets' for discovering valid targets, differentiating from that tool.

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

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

The description indicates when to use the tool (to reshape statements into payloads for Xero or QBO) and advises calling 'list_export_journal_targets' first. It implicitly excludes actual posting, but doesn't explicitly state when not to use it or list alternatives beyond the sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds critical behavioral details: the effect of limit=None (returns full list) vs non-None (pagination envelope), and error payload for negative offset/limit. This adds 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.

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

Approximately 150 words, well-structured: purpose sentence, usage tip, pagination behavior explanation, then bullet-like Args. Front-loaded with key info, no fluff.

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 4 params (1 required), output schema exists, and annotations cover safety, the description fully documents both output modes (full list and paginated envelope) and error conditions. It also relates to sibling tools. 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?

Schema covers all 4 params with descriptions (100% coverage), baseline 3. The description's Args section adds practical usage details: explains xml as 'raw statement XML', reason_code default 'AC04', and clarifies pagination behavior for offset and limit. This adds moderate value beyond schema.

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

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

Description clearly states 'List only the statement entries carrying a given return reason code.' It distinguishes from sibling 'list_entries' (all entries) and directly relates to 'generate_reversal' (preview before reversal). This is a specific verb+resource+scope.

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

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

Explicit usage advice: 'Use this to preview exactly which entries a reversal would touch before calling generate_reversal' and 'For every entry regardless of reason code use list_entries instead.' 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.

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns validated XML or error, and that no data is written to disk. Some redundancy but adequate transparency.

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 contains duplication: the 'headline one-shot workflow' is stated twice with similar wording. The Args section repeats schema info. Could be 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?

For a tool with 2 parameters and output schema, the description explains input, output format, and workflow well. It references sibling tools. Minor gap: no mention of input validation or prerequisites.

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

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

Schema coverage is 100% with detailed descriptions. The description adds minimal extra context (ISO reason code, default AC04, reference to list_return_reasons). Baseline 3 is appropriate.

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 generates a validated camt.053.001.14 reversal document from a statement. It distinguishes from sibling tools like filter_entries (preview) and list_return_reasons.

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

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

Explicitly states it's a one-shot workflow: pass xml and reason_code to get reversal XML, nothing written to disk. Recommends using filter_entries for preview first. Provides clear guidance.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it returns the specific date (2026-11-16), explains its enforcement significance, and notes that payments failing after that date are rejected. This enriches the agent's understanding beyond the annotations.

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

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

The description is concise, front-loaded with the core purpose, followed by usage guidelines and background context. Every sentence adds value 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?

The tool is simple (no parameters, no output schema), yet the description provides complete context: the date's format, its role in enforcement, differentiation from the readiness tool, and the rationale for its existence. Nothing essential is missing.

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

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

The tool has zero parameters, so schema coverage is effectively 100%. Baseline is 4, and the description does not need to add parameter details. It appropriately focuses on the output and 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 the verb (Return), resource (official CBPR+ / Nov 2026 cutover date), and output format (ISO 8601). It distinguishes itself from the sibling tool check_cbpr_readiness by noting that this tool returns the date for quoting purposes, not for auditing.

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

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

Explicit guidance is provided: 'Use this to quote the enforcement date directly, without parsing a document.' and 'To actually audit a statement against the rules that take effect on that date, call check_cbpr_readiness instead.' This clearly tells when and when not to use the tool.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context about returning a 'full JSON Schema for a flat input record', but does not disclose any additional 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.

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

Two concise sentences front-load the purpose, followed by clear usage guidance and parameter description. No superfluous content.

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 single parameter, no output schema, and low complexity, the description fully covers what the tool does, when to use it, and the parameter's meaning, leaving 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?

Schema coverage is 100%, with the schema already describing the 'message_type' parameter. The description adds value by referencing 'list_message_types' for valid values and clarifying its use in the context of ISO 20022 camt.05x messages.

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 verb 'Return' and the resource 'full JSON Schema for a message type's flat input record'. It distinguishes from siblings by mentioning 'get_required_fields' and 'validate_records'.

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 tells when to use ('to learn every field... or to drive a form/UI') and when not to ('For just the required-field names... to actually check records...'), naming alternative tools directly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the behavioral safety is clear. The description adds context about returning only field names, which is transparent. 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 concise: two sentences plus a pointer to the alternative tool. It is front-loaded with the action and resource, and every sentence 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 low complexity (1 parameter with full enum, output schema exists), the description covers purpose, usage, and alternatives completely. No 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?

Schema coverage is 100% with a detailed enum description. The description adds the usage purpose (for building reversing-entry records) but essentially restates the parameter type. This provides marginal added value beyond the schema.

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

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

The description clearly states the tool lists required input field names for a camt message type. It distinguishes from the sibling get_input_schema by explaining the difference, making the 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 explicitly tells when to use this tool (quick checklist for reversing-entry records) and when to use the alternative get_input_schema (for full type/format constraints). This gives clear guidance to the AI 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?

The description goes well beyond the annotations, which already declare read-only, idempotent, and non-destructive hints. It adds concrete behavioral details: the operation is deterministic for a given request, validates nothing, mutates nothing, and touches no external system. It also explains the transport-specific behavior (header vs. None) and the audit-log stamping. This rich context significantly aids the agent in predicting the tool's behavior and side 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 succinct yet comprehensive. It front-loads the purpose in the first sentence, then systematically covers usage, transport behavior, side-effectfulness, the argument, and the return format. Every sentence earns its place, and there is no redundancy or filler. The structure is logical and easy to parse.

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

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

For a zero-parameter, read-only tool with no output schema, the description is fully complete. It specifies the exact return payload ({"service": "camt053-mcp", "tenant": str | None}), the behavior under different transports, and the audit-log relationship. An agent has all the information needed to invoke the tool correctly and interpret its result without any further lookup.

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

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

The tool has zero parameters, and the schema is empty. The description explicitly notes that the 'ctx' argument is auto-injected and carries the underlying HTTP request when present, which clarifies the only (implicit) input. Since there are no user-supplied parameters to document, this is complete. The description adds meaning beyond the empty schema by explaining the auto-injected context, so a baseline of 4 is appropriate.

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 precise verb-resource pair: 'Return the multi-tenant scoping context of the current call.' This clearly identifies the tool's function and distinguishes it from the sibling tools, none of which deal with tenant context retrieval. The purpose is unambiguous, so an agent can easily recognize when to use this tool.

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

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

The description provides a clear use case: 'Use this to confirm which tenant/account scope the server attributes the session to.' It also explains transport-dependent behavior and how the value maps to the audit log, giving an agent context on when this tool is relevant. However, it does not explicitly mention when not to use it or name alternatives, though no sibling appears to serve a similar purpose. Since the guidance is clear but lacks explicit exclusion language, it earns a 4.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context that the tool is a static list lookup with no model call, and that it exposes the default list. 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.

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

Three sentences, no redundant information, front-loaded with main purpose, then usage context and clarification against sibling tool. Every sentence earns its place.

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

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

Given zero parameters, an existing output schema (not shown), and low complexity, the description covers purpose, usage, and behavioral traits completely. It explains why you would call this tool and how it fits with classify_entry.

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, and the input schema has 100% coverage. The description explains what the tool returns (list of default categories), which adds meaning beyond the schema. Baseline of 4 for zero params is appropriate.

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 the default candidate categories used by classify_entry, with specific verb 'list' and resource 'default candidate categories'. It distinguishes itself from the sibling classify_entry by noting it's a static lookup versus a model call.

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

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

Explicitly states when to use: 'Use this to quote the built-in category vocabulary to a user before running the LLM classifier.' Also clearly excludes its use for classification: 'to actually classify an entry, call classify_entry.' Provides context about operator overrides.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds pagination mechanics, envelope structure, error handling for negative offset/limit, and default limit behavior.

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

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

Concise and well-structured: purpose sentence, usage guidance, then parameter behavior with Args section. 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?

Covers pagination modes, error handling, and key parameter defaults. With output schema present, no need to explain return values further. Complete for this 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 100%, so baseline is 3. Description adds value by detailing the paginated envelope format ('{"total","offset","limit","entries"}') and explaining default behavior.

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 states 'List every booked entry across all statements in a camt.05x document' with a clear verb and resource. It explicitly distinguishes from sibling tools filter_entries and parse_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?

Provides explicit guidance: 'Use this to get the flat, paginable entry list' and distinguishes from filter_entries and parse_statement for specific use cases.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds that it returns a sorted list of currently two values, and notes future support tracking, providing 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.

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

Five concise sentences, each adding value: purpose, usage guidance, differentiation, return details, and future outlook. Front-loaded with main action.

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 no parameters and presence of output schema (though not detailed), description covers purpose, usage, and return format adequately. Does not need to elaborate on return structure due to output schema.

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 in schema, baseline score 4 applies. Description adds no parameter explanation needed and correctly implies no arguments required.

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 identifies verb 'list' and resource 'accounting-platform targets'. Distinguishes from sibling tool 'list_classify_entry_categories' by specifying its different purpose (category vocabulary vs. export destinations).

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 to use before invoking export_journal to inform user of valid target values. Contrasts with sibling tool but does not explicitly state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only, idempotent operation. The description adds the return format (list of dictionaries with 'message_type' and 'name' keys) and example value ('camt.053.001.14'), which is useful but does not contradict or significantly extend behavioral disclosure beyond the annotations.

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

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

The description is four sentences long. Each sentence serves a distinct purpose: (1) states the primary action, (2) gives workflow placement, (3) distinguishes from a sibling, (4) describes the return format. There is no redundant or extraneous text. The information is front-loaded and well-organized.

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

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

Given the tool's simplicity (no parameters, annotations covering safety and idempotency, and an existing output schema), the description fully explains what the tool does, when to use it, and what it returns. It also references a related tool for completeness. No 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?

This tool has zero parameters and schema coverage is 100%, so the schema already fully documents the input. The description adds meaning about the return format and usage context, which is sufficient for a parameterless tool. Baseline for zero parameters is 4, and the description meets that bar.

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 verb ('list') and the resource ('every supported ISO 20022 camt.05x message type and its name'). It distinguishes from the sibling tool 'list_return_reasons' by specifying that this tool is for message types, not return-reason codes. The purpose is precise and 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 explicit guidance: 'Use this first, before any validation or generation call, to discover the exact ``message_type`` strings this server accepts.' It also tells when to use an alternative: 'For the return-reason codes rather than message types, call ``list_return_reasons`` instead.' This leaves no ambiguity about the tool's role in the 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?

Description adds return format (list of {code, name} dictionaries) beyond annotations that already indicate readOnly, idempotent, non-destructive. 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?

Four short sentences, front-loaded with main purpose, no fluff. Each sentence adds value (purpose, usage, alternative, return format).

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

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

For a zero-parameter tool with output schema, description fully explains what is returned with example. 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, so baseline is 4. Description does not need to add parameter info.

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 it lists ISO return reason codes with names, and distinguishes from sibling tool list_message_types by specifying different use cases.

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 tells when to use (to discover reason_code values for filter_entries and generate_reversal) and when not (use list_message_types for message types). Includes concrete example.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds that the tool returns the full registry optionally filtered, and that the output feeds into another tool. No contradictions, and adds moderate 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.

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

Extremely concise and well-structured: first sentence states purpose, then usage context with workflow, then parameter args. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema, the description need not detail return structure. It sufficiently covers purpose, usage, parameter details, and its role in a broader workflow, making it complete for a simple listing 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 100%, baseline 3. The description adds value by explaining how parameters filter the listing and that 'None' returns all, and explicitly links the output clause values as input to cite_rulebook, enhancing semantic understanding.

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 verb 'List' and the resource 'curated rulebook clauses', with optional filtering. It distinguishes itself from sibling tools like cite_rulebook by positioning itself as a precursor to obtain clause IDs for that tool.

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

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

Explicitly instructs when to use: 'Use this to browse the citation registry and pick a clause id; then pass that id to cite_rulebook'. Provides a clear workflow and mentions the return type.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds return format (JSON-serialisable dict or error) and clarifies input constraints (no file path). 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 front-loaded with purpose, alternatives, and return value. No redundant sentences. Very concise and well-structured.

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 no output schema, the description adequately explains the return structure and error handling. It covers the main use case. Could mention potential size limits or performance, 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?

Schema coverage is 100%, so baseline is 3. The parameter description adds meaning beyond schema: it specifies the XML must have root element, is verbatim from bank, and rejects file paths. Adds clear 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?

Clearly states the verb 'Parse' and resource 'camt.05x statement XML' and distinguishes from siblings like 'list_entries' and 'validate_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?

Explicitly tells when to use this tool (to get structured data) and when to use alternatives like list_entries or validate_statement, with specific names.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint=false) already cover safety, and the description adds substantial behavior beyond that: deterministic/reproducible ranking, offline operation with no network call, no neural embedding model, and the graceful error when the optional [vector] extra is missing. It even explains the BLAKE2b/256-dim vector mechanics that guarantee identical results across processes. No contradiction with annotations — the deterministic claim aligns with idempotentHint.

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

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

Well front-loaded: the one-line purpose and usage guidance come first, followed by behavioral detail and args. It is longer than average, with the technical vector/hashing explanation verging on verbose, but that detail earns its place by substantiating the determinism and offline guarantees an agent needs to trust the tool.

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

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

With no output schema, the description compensates fully: the Returns section details the payload shape (query/top_k/returned/method/results/disclaimer), the ranked-clause format with added score, and both error modes (bad argument, missing [vector] extra). Combined with sibling routing and dependency caveats, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the input schema already documents both query and top_k richly, including the default 5 and clamping behavior. The description's Args section merely mirrors the schema without adding new meaning, which matches the baseline-3 rubric for high schema 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 first sentence states a specific verb, resource, and method: 'Search the curated rulebook clauses by lexical-vector similarity.' It also distinguishes itself from siblings by naming cite_rulebook (full citation after finding the id) and list_rulebook_clauses (browse everything), so an agent can immediately tell them apart.

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

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

Explicitly states when to use it: 'Use this when you know *what* a rule is about but not its exact scheme/version/clause id'. It then routes to the exact alternatives (cite_rulebook for citation, list_rulebook_clauses for browsing). This is textbook when/when-not guidance with named 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?

Annotations already declare read-only, idempotent, and non-destructive. The description adds return format (JSON with kind, value, valid) and emphasizes clear pass/fail outcome. 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 concise, well-structured with clear sections, and every sentence adds value. No superfluous text.

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

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

For a simple two-parameter tool with no output schema, the description covers purpose, usage, return format, and argument details. Complete and sufficient for an agent to use correctly.

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

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

Schema coverage is 100% and includes detailed descriptions (e.g., case-insensitivity for kind, examples for value). The description's Args section adds minimal new information beyond schema.

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

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

The description clearly states the tool validates a single financial identifier (IBAN, BIC, or LEI), using specific verbs and resources. It distinguishes itself from the sibling validate_records by specifying single vs batch.

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

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

Explicitly says when to use (one-off check) and when not to (batch), and provides the alternative validate_records. This meets the criteria perfectly.

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

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

Annotations already indicate read-only, non-destructive, idempotent behavior. Description adds return format ('report with valid, total, valid_count, errors'), which provides useful 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.

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

Three concise paragraphs: purpose, usage guidance, return format, then parameter descriptions. No fluff, well-organized.

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

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

For a 2-parameter tool with no output schema and clear annotations, the description covers purpose, usage, return structure, and parameter details. Complete and sufficient.

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

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

Schema coverage is 100%. Description adds context for both parameters: message_type explains supported values and references list_message_types; records explains they are flat and per row. This adds value beyond the schema.

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

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

The description clearly states 'Validate flat records against a message type's input JSON Schema,' specifying action and resource. It distinguishes from sibling 'validate_statement' by noting that tool is for documents.

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

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

Explicitly says when to use ('in-memory reversing-entry records per row before generation') and when not ('whole document... use validate_statement'), providing clear alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds details about detecting message type, validating against matching schema, and return format including error payload. No contradiction.

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, efficient, and front-loaded. First sentence gives the main action. Uses clear formatting for the return value. No unnecessary sentences.

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?

Fully explains input, behavior, output format, and error cases. No output schema but the return structure is described clearly. Complete for the tool's purpose given annotations.

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

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

Schema coverage is 100% with a clear description for the single parameter 'xml'. Description reinforces what the parameter is but adds no additional semantics beyond the schema. Baseline 3 is appropriate.

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 verb 'Validate' and the resource 'incoming camt.05x statement XML against its XSD schema'. It distinguishes from siblings by explicitly naming alternatives like check_cbpr_readiness and parse_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?

Explicitly says when to use: 'to confirm a document is well-formed and schema-valid before processing it'. Also states what it does not do and provides alternatives: 'for the Nov 2026 CBPR+ business rules use check_cbpr_readiness, and to extract the data use parse_statement'.

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