Server Quality Checklist

Tool Scores

• create_quoteB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering safety traits. The description adds that it returns exchange rate, fees, and delivery estimate, which is useful context, but does not disclose side effects, persistence of the quote, or permission requirements. With annotations present, this is adequate though not rich.

  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 two sentences, front-loaded with the main purpose, and every sentence conveys essential information. It is concise and well-structured without 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?

  Given there is no output schema, the description appropriately summarizes return values (exchange rate, fees, delivery estimate). It also clarifies the mutually exclusive amount input. However, it does not mention whether the quote is temporary or persistent, nor any side effects, though annotations mitigate some gaps. Overall, it is fairly complete for this tool's 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?

  The input schema has 100% parameter description coverage. The description reinforces the 'sourceAmount OR targetAmount (not both)' rule, which is already embedded in the schema's property descriptions, so it adds marginal value beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool creates a quote for a money transfer, with a specific verb and resource. It also mentions the key input constraint and outputs. However, it does not distinguish itself from sibling tools like get_quote or get_temporary_quote, so it lacks sibling differentiation.

  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 provides no guidance on when to use this tool versus alternatives such as get_quote or get_temporary_quote. It implies use for creating a quote but does not state exclusions or compare with other quote-related tools, leaving the selection decision underspecified.

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

• fund_transferA
  3.5/5.0
  Behavior3/5

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

  The description adds the PSD2 regulatory limitation beyond the annotations, which already indicate a destructive, non-read-only operation. However, it doesn't disclose the financial consequences (e.g., irreversible deduction from balance) or that the transfer must be in a fundable state. No contradiction with annotations.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action, and the caveat is clearly separated. Every word earns its place, making it highly concise and scannable.

  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?

  For a simple two-parameter tool with no output schema, the description is adequate but leaves gaps: it doesn't state prerequisites (transfer must exist, be in a fundable state), or what happens upon success/failure. The PSD2 note is useful, but overall completeness is average.

  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 minimal descriptions ('Profile ID', 'Transfer ID'). The tool description adds no extra meaning about how profileId and transferId relate to the funding operation, so it falls at the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Fund a transfer') and the resource ('your Wise balance'). It distinguishes from sibling tools like create_transfer by focusing on funding an existing transfer, though it doesn't explicitly say the transfer must already exist.

  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 PSD2 note gives a specific when-not-to-use condition for EU/UK personal tokens, but there is no explicit guidance on when to use this tool vs alternatives (e.g., after create_transfer, before the transfer is executed). The context is implied at best.

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

• get_balanceA
  3.6/5.0
  Behavior2/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 covered. The description adds no independent behavioral context, such as response format, error behavior, or authentication needs. The 'by ID' phrasing simply reflects the balanceId parameter already present in the schema.

  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 a single short sentence that fully conveys the purpose without waste. It is front-loaded and easy to scan, achieving maximum conciseness.

  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?

  The tool is simple, with only two parameters and clear annotations. The description, combined with the schema and readOnlyHint, provides enough context for a straightforward get-by-id operation. A minor gap is the lack of return value details, but the operation type makes this largely inferable, and no output schema exists.

  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 both parameters have descriptions in the schema. The description's mention of 'ID' adds no additional meaning beyond what the schema already provides, so the 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 'Get a specific balance account by ID' clearly states the action (get), the resource (balance account), and the scope (a specific one by ID). This distinguishes it from list_balances, which would return multiple balances, and aligns with the tool name.

  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 you have a known balance ID and need a single record, but it does not explicitly state when to use this versus list_balances or any exclusions. No alternatives are named, so guidance is only implied, not explicit.

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

• get_delivery_estimateA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds no further behavioral context, such as how the estimate is calculated or whether it depends on transfer status. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single, succinct sentence: 'Get the estimated delivery date for a transfer.' It contains no filler or redundant information and is well-structured for quick scanning.

  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 read-only tool with one parameter, the description adequately conveys the purpose. However, since there is no output schema, it would be helpful to clarify the format of the estimated date (e.g., ISO string or timestamp). This is a minor gap in otherwise sufficient 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?

  The schema description for transferId is 'Transfer ID', which is complete, giving 100% coverage. The description does not add any additional meaning or nuance to the parameter beyond what the schema already provides, so the baseline score 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?

  The description uses a specific verb 'Get' and clearly states the resource ('estimated delivery date') and the object ('transfer'). It distinguishes itself from siblings like get_transfer, which would return full transfer details.

  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 is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where another tool would be more appropriate. The description only states the function, leaving the agent to infer usage context.

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

• get_exchange_rateA
  3.6/5.0
  Behavior2/5

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

  The annotations already declare `readOnlyHint: true` and `destructiveHint: false`, covering safety aspects. However, the description adds no behavioral context beyond 'current', such as the data source, update frequency, or how rate values are calculated. For a read-only tool, this is minimal transparency.

  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 a single, focused sentence of ten words. It is front-loaded with the verb 'Get' and immediately states the resource and scope, with no redundant information.

  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?

  This is a simple tool with a clear schema and good annotations. Without an output schema, the description could have explained the return format, but the operation is conventional enough that an agent can infer the response (a numeric rate). The overall context is sufficient for correct invocation, though slightly thin on response details.

  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?

  The input schema provides 100% coverage with clear descriptions for both `source` and `target` (including examples). The description does not add any additional parameter semantics, so it stays at the baseline of 3 for schema-heavy tools.

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

  Purpose5/5

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

  The description uses a specific verb 'Get' and a clear resource 'current exchange rate' with the scope 'between two currencies'. It also distinguishes the tool from the sibling `get_exchange_rate_history` by emphasizing 'current', 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.

  Usage Guidelines3/5

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

  The description implies usage for retrieving current exchange rates, but does not explicitly state when to use it versus alternatives like `get_exchange_rate_history` or `create_quote`. No exclusions or prerequisites are mentioned, leaving the agent to infer the appropriate context.

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

• get_transferA
  3.6/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already provide. Annotations declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read. But the description does not describe return format, error handling, or any additional operational traits, making it minimal.

  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?

  A single, front-loaded sentence that states exactly what the tool does without wasted words. It is appropriately sized for a simple getter and earns its place.

  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 read-only getter with one parameter and good annotations, the description is nearly complete. It doesn't explain return values, but for a get operation the response is reasonably inferred. The lack of an output schema and any mention of errors or edge cases prevents a perfect score.

  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?

  The schema covers the transferId parameter with a description 'Transfer ID', achieving 100% schema_description_coverage. The description's 'by ID' adds no new meaning beyond the parameter itself. Baseline of 3 is appropriate since schema does the heavy lifting.

  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 (get), resource (specific transfer), and scope (by ID), distinguishing it from list_transfers and create_transfer. It is a specific verb+resource phrasing that leaves no ambiguity.

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

  Usage Guidelines3/5

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

  The usage is implied: one needs a transferId to use this tool. However, there is no explicit guidance on when to prefer this over list_transfers or other getters, nor any mention of alternatives. The context is clear but lacks direct exclusions or alternatives.

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

• get_profileA
  3.8/5.0
  Behavior3/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 no additional behavioral context beyond the basic get operation, but it is consistent with annotations and does not contradict 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 a single sentence of six words, conveying the essential information with no unnecessary words. It is extremely concise and well-structured.

  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?

  The tool is simple with one parameter and strong annotations. The description is adequate for a getter, though it does not specify the return format or error behavior in the absence of an output schema. Still, the minimal context is sufficient given the tool's simplicity.

  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?

  The schema fully describes the single parameter profileId with 'Profile ID' (100% coverage). The description does not add any extra meaning beyond the schema, so baseline 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?

  The description uses the specific verb 'Get' and identifies the resource 'profile' with the qualifier 'by ID', clearly distinguishing it from list_profiles which lists all profiles. The resource and action are unambiguous.

  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 a specific profile ID is known, but it does not explicitly state when to use this tool over alternatives like list_profiles, nor does it mention exclusions or conditions. The guidance is only implicit.

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

• get_recipientA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, providing a clear safety profile. The description's verb 'Get' aligns with this and adds no additional behavioral context (e.g., error behavior, auth requirements, or return format). Since annotations cover the safety aspect, the description does not need to restate it, but it also adds no extra transparency value.

  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 a single, concise sentence that front-loads the action and object. Every word is necessary, and there is no fluff or repetition. It is appropriately sized for a simple get-by-ID tool.

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

  Completeness4/5

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

  Given the tool's simplicity (one required parameter, no output schema, and strong annotations), the description is essentially complete for invoking the tool. It clearly states what it retrieves. A minor gap is the absence of any indication of what the returned object looks like, but for a standard get-by-ID resource, this is largely implied and not critical.

  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%: the parameter accountId is described as 'Recipient account ID'. The tool description's 'by ID' adds minimal additional meaning; it essentially echoes the schema. No extra semantics (format, constraints, source of ID) are provided, so the description does not significantly enhance parameter understanding.

  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 the specific verb 'Get' and clearly identifies the resource as 'recipient account' with a unique identifier ('by ID'). This distinguishes it from sibling tools like list_recipients (plural, all) and create_recipient, 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.

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool compared to alternatives. The usage is implied through the phrase 'by ID'—use when you have a specific recipient account ID—but it doesn't contrast with list_recipients or mention when not to use it. No explicit exclusions or alternative recommendations are provided.

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

• list_recipientsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the 'all' behavior but does not disclose potential pagination, ordering, or response size. It does not contradict annotations.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the verb and resource. It contains no filler or redundant information.

  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 read-only list tool with good annotations, the description is largely complete. It clearly states what it does and the optional filter. However, with no output schema, it could mention the return format (e.g., list of recipient objects) or any limits, but this is a minor gap.

  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 clear descriptions for profileId and currency. The description only reiterates the currency filter, adding no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly specifies the verb 'List' and the resource 'recipient accounts for a profile', and the scope 'all' distinguishes it from get_recipient, which presumably fetches a single recipient. It is specific and non-tautological.

  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 when to use it (when you need all recipients for a profile), but it does not explicitly mention alternatives like get_recipient for single-recipient lookups or create_recipient for adding. It provides context without exclusions or alternative references.

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

• list_transfersA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context (e.g., pagination behavior, return format, rate limits) beyond what annotations provide, 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence: 'List transfers for a profile with optional filters.' Every word is useful, with no filler or redundancy, making it appropriately concise.

  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 list operation with six well-documented parameters and clear annotations, the description is adequate. It does not explain return values, but no output schema exists, and the nature of a list operation implies transfer objects. It could benefit from noting pagination defaults, but those are already in the schema, so the description is sufficiently 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%, with all six parameters documented (profileId, limit, offset, status, createdDateStart, createdDateEnd). The description's phrase 'optional filters' aligns with the parameters but adds no additional meaning beyond the schema, so the baseline score 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?

  The description uses a specific verb ('List') with a clear resource ('transfers') and scope ('for a profile'). It distinguishes itself from sibling tools like get_transfer (single transfer) and create_transfer, making the purpose immediately clear.

  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 listing transfers with optional filters, but it does not explicitly state when to use this tool versus alternatives like get_transfer. No exclusions or alternative guidance is provided, so usage is implied rather than explicit.

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

• create_recipientA
  3.9/5.0
  Behavior3/5

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

  The description adds context that the 'details' object varies by currency/type, which is a useful behavioral trait not fully captured by the annotations. However, it does not disclose other important traits like idempotency, duplicate handling, or what the response returns, leaving gaps beyond the minimal annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, and contains no redundant information. Every sentence serves a purpose.

  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?

  The tool has a nested object and no output schema, so the description should compensate by explaining response or error behavior. It provides the essential prerequisite (get_account_requirements) but lacks details on return values, idempotency, or failure modes, making it minimally adequate for a creation tool.

  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?

  The input schema already provides descriptions for all six parameters, achieving 100% coverage. The tool description adds minimal new meaning beyond the schema, mostly repeating the get_account_requirements guidance already present in the 'details' parameter description.

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

  Purpose5/5

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

  The description clearly states the action ('Create') and resource ('a new recipient account'), distinguishing it from sibling tools like list_recipients, get_recipient, and delete_recipient. The verb+resource combination is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly instructs to use get_account_requirements first, providing a clear precondition for correct usage. It does not mention alternatives, but as the only creation tool for recipients, this is sufficient context for when to use it.

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

• delete_recipientA
  4/5.0
  Behavior4/5

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

  The description adds 'deactivate' which clarifies that the destructive operation may be a soft delete rather than a permanent removal, providing nuance beyond the annotations (destructiveHint=true, idempotentHint=true). It doesn't detail side effects or reversibility, but the deactivation clarification is valuable.

  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 a single sentence of five words: 'Delete (deactivate) a recipient account'. It is front-loaded with the action and contains zero redundant content.

  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 single-parameter delete tool with annotations covering destructive and idempotent behavior, the description is largely complete. The 'deactivate' nuance adds useful context, though it omits any mention of return values or post-deletion effects, which is acceptable given the lack of an output schema.

  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?

  The schema already documents accountId with 'Recipient account ID' (100% coverage), and the description adds no additional parameter semantics. The baseline of 3 applies because the schema carries the full burden.

  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 'Delete (deactivate)' and the resource 'recipient account', using a specific verb and noun. This distinguishes it from sibling tools like create_recipient, get_recipient, and list_recipients.

  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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage is implied by the operation name and sibling context, but there's no direct guidance.

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

• get_exchange_rate_historyA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds that the tool returns rates over a specified time period but does not disclose return format, grouping behavior, or any limitations. Given the annotation coverage, the description provides minimal but not rich additional behavioral context, warranting a 3.

  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 a single concise sentence that fully conveys the tool's purpose without redundancy. Every word earns its place, and it is front-loaded with the key verb and resource.

  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?

  The tool is relatively simple with 5 parameters, full schema descriptions, and annotations indicating read-only behavior. The description explains the core functionality and is sufficient to guide invocation. However, it does not clarify the return shape (e.g., whether it returns a list of rates at intervals), which would be useful given no output schema. Still, overall completeness is good.

  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?

  The input schema covers all 5 parameters with descriptions and examples (e.g., 'source' as currency code, 'from'/'to' as ISO timestamps, 'group' as enum). The description itself adds no extra parameter meaning beyond what the schema already provides. With 100% schema coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it retrieves historical exchange rates between two currencies over a time period. It uses a specific verb ('Get') and resource ('exchange rate history'), and the word 'historical' distinguishes it from the sibling tool get_exchange_rate, which likely returns the current rate.

  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 implies when to use this tool (when historical rates are needed) through the word 'historical' and 'over a time period'. It does not explicitly mention alternatives, but the context of sibling tools (get_exchange_rate) makes the usage context clear. It lacks an explicit exclusion statement, so it falls short of a 5.

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

• list_profilesA
  4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true and destructiveHint=false, establishing the read-only safety profile. The description adds context about the scope (personal and business) and account association, but does not disclose additional behavioral traits such as pagination, sorting, or response format. With annotations covering the key safety aspects, the added value is moderate.

  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 a single sentence that is clear, direct, and free of any superfluous information. It front-loads the action ('List all profiles') and immediately provides the relevant scope and context.

  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 that this is a zero-parameter, read-only list operation with no output schema, the description adequately covers the tool's purpose and scope. It could be improved by mentioning the response format or explicitly noting what data is returned for each profile, but the description is sufficient for straightforward usage.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema provides no parameter details. According to the rubric, a baseline of 4 is appropriate when there are no parameters. The description does not need to explain parameter semantics, and it correctly implies that no arguments are required.

  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 specifies the action (List), the resource (profiles), and the scope (all personal and business profiles associated with the Wise account). This distinguishes it from sibling tools like get_profile and list_balances, making the tool's purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies that the tool is for listing all profiles, but it does not explicitly state when to use it versus alternatives like get_profile for a single profile. There are no exclusion criteria or alternative tool mentions, so usage guidance is only implicit.

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

• get_quoteA
  4.1/5.0
  Behavior3/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 known. The description adds no additional behavioral context beyond 'existing', with no mention of response format, errors, or other 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.

  Conciseness5/5

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

  Six-word single sentence, entirely front-loaded, with zero waste. Every word earns its place.

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

  Completeness5/5

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

  For a simple one-parameter retrieval with good read-only annotations and no output schema, the description is sufficient. It tells exactly what the tool does and how to invoke it, leaving no critical 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 covers the single parameter with 100% description coverage. The description merely restates 'by ID' without adding format, constraints, or relationship to other parameters, so it adds no semantic value beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb ('Get'), names the resource ('quote'), and specifies scope ('existing', 'by ID'), clearly distinguishing it from create_quote or get_temporary_quote. It leaves no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  Provides clear context: retrieve an existing quote using its ID. However, it does not explicitly name alternatives like get_temporary_quote or state when not to use this tool, so it lacks explicit exclusions.

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

• cancel_transferA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the description carries less burden. It adds meaningful context beyond annotations by noting cancellation only works pre-completion, which is a behavioral constraint not evident from schema or annotations. 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.

  Conciseness5/5

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

  Description is a single sentence that front-loads the action ('Cancel a transfer') and includes a necessary condition in a compact parenthetical. No wasted 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?

  For a simple one-parameter mutation tool, the description provides sufficient context: what it does and a critical precondition. With annotations covering the destructive nature and no output schema required, the description is adequately complete for agent decision-making.

  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?

  Input schema fully documents transferId with description 'Transfer ID' (100% coverage). The description adds no additional parameter-level detail, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  Description uses the specific verb 'Cancel' with the resource 'transfer', clearly distinguishing it from transfer retrieval tools like list_transfers and get_transfer. The parenthetical adds a key condition (not yet completed) that makes the action unambiguous.

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

  Usage Guidelines4/5

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

  Explicitly states when cancellation is possible ('only possible if not yet completed'), giving the agent a clear precondition and implicitly telling it not to use this tool for completed transfers. Does not name alternative tools, but the condition is enough for basic guidance.

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

• create_transferA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate side effects and idempotency, and the description adds concrete guidance on how idempotency works (reuse customerTransactionId) plus the PSD2 restriction. It does not contradict annotations, though the destructiveHint remains unexplained.

  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 two concise, front-loaded sentences that efficiently convey purpose, prerequisites, idempotency, and a regional caveat with no wasted 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?

  For a creation tool with 4 parameters and no output schema, the description covers the core purpose, prerequisites, idempotency, and a regional restriction. It omits response shape and the funding step, but the schema and sibling list partially compensate.

  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?

  The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description reiterates the required parameters and explains customerTransactionId's idempotency, but this adds little beyond the schema's existing explanations.

  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 'Create a new transfer' with a specific verb and resource, and it distinguishes itself from siblings like fund_transfer and cancel_transfer by emphasizing the need for a quote ID and recipient account ID.

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

  Usage Guidelines4/5

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

  The description provides clear context for use: requires a quote ID and recipient account ID, and includes a regional restriction for EU/UK. It does not explicitly name alternative tools or exclusion scenarios, but the prerequisites imply a proper workflow.

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

• get_account_requirementsA
  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 destructiveHint=false, and the description aligns by saying 'Get'. It adds behavioral context by stating that it returns 'field definitions with validation rules', which goes beyond the annotation's safety profile and explains what the agent can expect from the response.

  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 consists of two concise sentences that front-load the primary action and immediately state the return type. Every word earns its place, with no redundancy or information repetition from 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 read-only requirements tool with well-documented parameters and no output schema, the description sufficiently explains the tool's purpose and return value. It could explicitly mention its role as a preliminary step to create_recipient, but it is otherwise complete for the complexity level.

  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?

  The input schema covers all three parameters with clear descriptions (source, target, sourceAmount) at 100% coverage, so the baseline is 3. The description does not add additional parameter-level semantics beyond referencing a 'currency route', which lightly relates to source/target but is not detailed.

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

  Purpose5/5

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

  The description clearly states the tool gets required fields for creating a recipient, with the specific context of a currency route. It distinguishes itself from sibling tools like create_recipient and get_recipient by focusing on requirements rather than execution or retrieval of an existing recipient.

  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 context is clear: use this tool to retrieve required fields before creating a recipient. It implies the pre-creation flow but does not explicitly state exclusions or alternatives, such as when not to use it or when to use a different tool.

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

• get_temporary_quoteA
  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 destructiveHint=false, so the safety profile is clear. The description adds behavioral context by emphasizing the temporary, non-stored nature of the quote, which goes beyond the annotations and helps the agent understand the tool's side effects (none persisted).

  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 a single, front-loaded sentence that conveys the essential information without any filler or repetition. Every word earns its place.

  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 read-only tool with comprehensive schema descriptions and annotations, the description adequately covers purpose and behavior. It hints at the return content ('rates and fees'), though it does not detail the response structure. Given the absence of an output schema, a slightly more explicit note on the returned data would make it perfect, but it is still complete enough 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.

  Parameters3/5

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

  Schema description coverage is 100%, with all four parameters individually described. The description itself does not add any parameter-level meaning, but the schema already covers the semantics, 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 clearly states the tool's action ('Get'), resource ('a temporary (non-stored) quote'), and purpose ('to check rates and fees'). It distinguishes itself from related tools like create_quote by explicitly noting it does not create a stored quote.

  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 phrase 'without creating one' implies this tool is for quick checks where persistence is not needed, which provides clear context. However, it does not explicitly name alternative tools (e.g., create_quote) or state when not to use it, so it falls short of a full 5.

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

• list_balancesA
  4.4/5.0
  Behavior4/5

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

  With annotations already indicating a safe read operation (readOnlyHint=true), the description adds useful behavioral context: it lists accounts, returns currency balances with available amounts, and explains the structural difference between STANDARD (one per currency) and SAVINGS (multiple jars). 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.

  Conciseness5/5

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

  Two sentences: first states the action and scope, second explains return value and types. No redundant wording, front-loaded with the most important information.

  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 low parameter count (2), full schema coverage, and no output schema, the description reasonably covers the return format (currency balances with available amounts) and type semantics. Could mention pagination or error handling, but not critical for a simple list operation.

  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 covers both parameters at 100%, so the baseline is 3. The description adds semantic meaning to the types parameter by clarifying that STANDARD is one per currency while SAVINGS includes multiple 'jars' per currency, which enhances understanding beyond the schema's basic enum-like description.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and resource ('balance accounts for a profile'), clearly stating the scope. It distinguishes from sibling tools like get_balance by emphasizing 'all balance accounts' and explains the STANDARD vs. SAVINGS distinction.

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

  Usage Guidelines4/5

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

  Provides clear context that this is for listing all balances for a given profile, with an optional types parameter to filter STANDARD or SAVINGS. Does not explicitly mention alternatives (e.g., when to use get_balance), but the scope is unambiguous.

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