Server Quality Checklist

Tool Scores

• peer_cash_orderA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description adds genuine value beyond them: the return envelope (state, amounts, fills, next actions), the transient ORDER_NOT_FOUND error semantics specifically after finalization, and the safety rule to retry the read rather than re-submitting a deposit. This idempotence- and consistency-revealing context enhances the annotations without contradicting 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?

  Two tight, front-loaded sentences: the first states exactly what the tool returns; the second delivers a concrete, actionable error-handling rule. Nothing is superfluous, and the most critical safety guidance ('never the deposit transaction') is positioned at the end for emphasis.

  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 one-parameter, read-only tool with no output schema and minimally semantic siblings, the description covers the essential ground: return contents and the primary failure mode with recovery steps. It could have expanded on the response structure or other error types, but the readOnly/idempotent annotations and the tool's simplicity mean little is lost.

  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?

  With schema description coverage at 0%, the burden falls on the prose, and the phrase 'from its deposit id' does clarify the parameter's role as the lookup key. However, the description doesn't explain the parameter's format (beyond the schema regex) or edge cases like malformed ids. For a single, well-named string parameter, this is adequate but not compensating for the coverage gap.

  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 begins with a specific verb ('Return') and resource ('one order'), enumerating exactly what's returned (state, amounts, fills, next actions) and the lookup key ('deposit id'). It implicitly separates itself from the plural sibling peer_cash_orders and the peer_cash_prepare* write tools by framing a single-order read, though it never names an alternative. This is clear, purposeful, and mostly distinguishes from siblings without explicit cross-referencing.

  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 offers no explicit when-to-use statement, nor does it name sibling tools for list/aggregate scenarios. Its value lies in the error-handling guidance (treat ORDER_NOT_FOUND after finalization as indexer lag and retry this read, never the deposit transaction), which imparts a strong usage rule for a specific condition. However, this is practical error-recovery context rather than tool-selection guidance, so it barely clears the implied-usage bar.

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

• peer_cash_prepare_top_upA
  4/5.0
  Behavior4/5

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

  Annotations provide no safety hints beyond the readOnly/idempotent/destructive flags, so the description carries the burden. It adds useful context by specifying that the transactions are 'unsigned' and that it prepares both 'approval' and 'addFunds' transactions, indicating this is a preparation step rather than an execution. It does not describe side effects or reversibility, but the 'unsigned' detail clarifies it does not modify the order directly.

  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 efficiently states the core action and context. It is front-loaded with the primary purpose and contains no filler or repetition.

  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 two-parameter tool without an output schema, the description gives sufficient high-level context ('prepare unsigned transactions', 'add Base USDC to a live order') but lacks parameter-level detail and explicit guidance on the expected return value or any prerequisites. It is adequate but leaves gaps in parameter understanding and does not mention any constraints or edge cases.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for explaining parameters. It mentions 'Base USDC' and 'live order' but does not explicitly explain the 'amount' parameter (only implies it is the USDC amount) or the 'depositId' parameter at all. The description adds no direct meaning beyond what the parameter names suggest, leaving ambiguity for the agent.

  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 purpose: preparing unsigned approval and addFunds transactions to add Base USDC to a live order. It uses a specific verb ('prepare') and resource ('top-up'), distinguishing it from sibling tools like peer_cash_prepare_withdraw, which focuses on withdrawals.

  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 usage for adding funds to an existing order via the phrase 'to add Base USDC to a live order,' but does not explicitly mention alternatives or when not to use it. It provides clear context for its intended scenario, though it lacks exclusions or comparison with sibling tools like peer_cash_prepare.

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

• peer_cash_capabilitiesA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds 'live' to indicate dynamic data. No side effects are disclosed, but they are not needed given the annotations. However, it doesn't describe response structure or potential variability, so a 3 is appropriate.

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

  Conciseness5/5

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

  Two sentences, front-loaded verb, no fluff. The second sentence provides essential usage guidance, making every word earn 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 read-only discovery tool with one optional parameter, the description covers what is returned and when to call it. Although no output schema exists, the description enumerates the return content, making it complete for the tool's complexity.

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

  Parameters3/5

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

  Schema covers 100% of the parameter with a clear description. The tool description does not add additional parameter semantics beyond the schema, so the baseline of 3 applies.

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

  Purpose5/5

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

  Clearly states it returns a specific set of live data (destination, payout platforms, fiat currencies, payee hints, amount bounds, pricing model). The verb 'Return' identifies it as an information retrieval tool, and the content distinguishes it from estimate/prepare/finalize siblings.

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

  Usage Guidelines4/5

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

  Explicitly says to call this before naming a rail or currency, providing clear temporal usage context. It doesn't name alternatives or exclusions, but implies a prerequisite role among siblings.

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

• peer_cash_estimateA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds that the rate is live and non-locking, and that the final rate depends on a buyer fill – valuable context beyond the annotations. It does not describe return format but provides meaningful behavioral nuance.

  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 purpose, and each sentence adds information. No fluff.

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

  Completeness4/5

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

  For a simple estimator, the description covers purpose, rate source, and binding limitation. However, without an output schema, it does not describe the exact return structure (e.g., estimated amount, rate), leaving a small 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 coverage is 100% with good descriptions for amount, currency, and platform. The tool description does not add parameter-specific details beyond mentioning Base USDC and fiat, but that is not necessary given the schema already covers it.

  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 'Estimate fiat received for Base USDC at the live Chainlink oracle rate' – a specific verb and resource. It distinguishes from sibling tools like peer_cash_prepare and peer_cash_order by indicating this is an estimate, not a binding operation.

  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 clarifies this is 'not a locked quote' and that the 'binding rate resolves when a buyer fills', implying this tool is for pre-transaction estimation. However, it does not explicitly name alternatives or state when not to use it, so it has clear context but no exclusions.

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

• peer_cash_ordersA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds behavioral context: orders are owned by a maker wallet and can be filtered to those needing attention. This goes beyond the annotations but doesn't fully describe default behavior (e.g., pagination, return format). 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?

  The description is a single, focused sentence that delivers the essence without excess. It is front-loaded with the action ('List') and includes optionality succinctly.

  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 listing tool with annotations and no output schema, the description is adequate. It explains the core scoping and filtering, which is sufficient for initial understanding. The lack of return type details is acceptable given the simplicity, though a mention of output structure would make it complete.

  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 description coverage is 0%, so the description must compensate. It maps 'owner' to 'maker wallet' and 'inFlight' to 'still need attention', providing meaning for two of three parameters. 'limit' is self-explanatory from the schema. This adds valuable semantics beyond raw parameter names.

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

  Purpose5/5

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

  The description states a specific verb ('List') and resource ('orders') with clear scope ('owned by a maker wallet'). It also mentions an optional filter ('that still need attention'), distinguishing it from sibling tools like peer_cash_order (singular). This fully clarifies the tool's purpose.

  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: use this to list orders for a maker wallet, optionally filtering by those needing attention. However, it does not explicitly mention when to avoid this tool or compare with alternatives (e.g., peer_cash_order for single order retrieval). There is clear context but no 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.

• peer_cash_prepare_withdrawA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint: true, but the description adds meaningful nuance: it discloses that the tool prepares unsigned transactions (not executing directly) and that omitting amount closes the entire order while providing an amount performs a partial withdrawal. This goes beyond the annotations and clarifies the 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?

  Two concise sentences: the first states the core purpose, the second explains conditional behavior for the amount parameter. No filler, 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?

  For a simple tool with two parameters and no output schema, the description covers purpose, usage nuances, and implies return type (unsigned transactions). It does not mention prerequisites or edge cases, but given the tool's narrow scope and the annotations, it 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?

  The description explains the 'amount' parameter in detail (omit to close, provide base-unit amount for partial withdrawal), adding value beyond the schema's pattern. However, it does not describe 'depositId' at all. With only 2 parameters and 0% schema coverage, the description partially compensates but leaves a required parameter unexplained.

  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 'Prepare unsigned transactions to withdraw unmatched funds' — a specific verb (prepare) and resource (withdrawal of unmatched funds). It distinguishes itself from siblings like peer_cash_prepare_top_up by focusing solely on withdrawal.

  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 usage context: 'Omit amount to close the order; pass a Base USDC base-unit amount for a partial withdrawal.' This explains how to invoke the tool in different scenarios. However, it does not explicitly mention when not to use it or alternatives, though the name and sibling list make the purpose obvious.

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

• peer_cash_finalizeA
  4.3/5.0
  Behavior4/5

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

  The description adds context beyond annotations by explaining what the tool reads (Base receipt) and what it resolves (deposit id). It aligns with readOnlyHint and idempotentHint, and no contradiction exists.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core function, followed by a precise usage constraint. No redundant wording.

  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/resolve tool with only one parameter and no output schema, the description covers the purpose, the temporal precondition, and the expected result (deposit id). It doesn't describe error handling, but with the read-only and idempotent annotations, this is acceptable.

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

  Parameters2/5

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

  The schema describes one parameter, transactionHash, with a regex pattern, but the description does not explicitly mention how this parameter maps to the transaction. With 0% schema description coverage, the description should compensate but does not, leaving the agent to infer that transactionHash is the hash of the createDeposit transaction.

  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 'Read' and specifies the resource 'confirmed Base createDeposit receipt' and the outcome 'resolve the resumable Peer deposit id'. It clearly distinguishes from siblings like peer_cash_prepare by referencing it as the prior step.

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

  Usage Guidelines5/5

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

  The description explicitly states the precondition: 'Call only after the host confirms the createDeposit transaction returned by peer_cash_prepare.' This tells the agent exactly when to invoke it, naming the prerequisite tool.

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

• peer_cash_prepareA
  4.3/5.0
  Behavior5/5

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

  The description discloses critical behavioral traits: 'never accepts a private key or submits a transaction' and 'obtain explicit approval before host-side signing'. These are not in annotations (which only have false hints). This adds significant safety-relevant context beyond 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?

  Two concise sentences, immediately stating the tool's purpose and critical safety behavior. No fluff, front-loaded.

  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 tool with no output schema, it mentions it prepares unsigned transactions and requires approval before signing, which covers the key usage context. It doesn't describe the return value or possible errors, but those are not strictly necessary given the action-oriented description. Slightly more could be said about the receive parameter structure, but the schema covers that.

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

  Parameters2/5

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

  The schema has a description for amount but not for receive. The description does not explain the parameters at all. Since schema coverage is only 50% (low), the description should compensate. It fails to clarify what 'receive' means or how it relates to the transaction. Thus the agent may struggle to populate the receive object correctly.

  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 explicitly states it prepares two specific transaction types (Base USDC approval and createDeposit), clearly distinguishing from sibling tools like prepare_withdraw or prepare_top_up. The verb 'prepare' plus resource 'cash-out' 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 says 'Show the plan and obtain explicit approval before host-side signing,' which indicates the tool's usage context. However, it doesn't explicitly contrast with sibling tools or state when not to use it. Still, the purpose is clear enough for an agent to choose it for cash-out preparation.

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

• peer_cash_prepare_access_policyA
  4.3/5.0
  Behavior4/5

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

  The description adds 'unsigned' transaction details and the conditional trigger, which goes beyond the annotations (idempotent, non-destructive). However, it doesn't mention auth requirements or what to do with the unsigned transaction, but given the annotations already cover safety, this is sufficient.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose, concise and well-structured. No fluff.

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

  Completeness4/5

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

  Provides essential context (after finalization, only when accessPolicyRequired=true) and notes the transaction is unsigned. However, it doesn't explain what happens with the returned transaction or how depositId relates, but given the simple parameter and sibling tool context, it's mostly complete.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description alone must explain the parameter. It mentions 'depositId' nowhere, and the parameter's role is only implied by the tool's purpose. The schema provides a pattern but no semantic explanation, leaving the parameter under-documented.

  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 identifies the action: 'Prepare the unsigned verified-buyer access-policy transaction'. It distinguishes from sibling tools by specifying 'for Venmo, Cash App, or PayPal orders' and ties it to a specific step in the flow (after finalization, when accessPolicyRequired=true).

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

  Usage Guidelines5/5

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

  Explicitly states 'Use only after finalization when peer_cash_prepare returned accessPolicyRequired=true', giving a clear precondition and indicating when NOT to use it. This provides strong usage guidance without ambiguity.

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