Server Quality Checklist

Tool Scores

• generate_payment_linkC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not disclose what the tool returns (e.g., a URL), whether it creates a persistent record, expires, requires authentication, or has any side effects, making the tool's behavior largely opaque.

  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, compact sentence that front-loads the verb and object. It is appropriately sized and contains no filler or redundant information, making it easy to parse.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It does not explain the return value, expiration or sharing behavior, or how the 'customer' reference maps to the input parameters. The tool's complexity is moderate, but the description leaves major gaps that could lead to incorrect invocation.

  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 descriptions cover all four parameters, but the description introduces a 'customer' concept that is not represented in the schema, creating ambiguity about how a customer is specified. The description adds no additional semantic value beyond the schema's own parameter descriptions, and the mismatch reduces clarity.

  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 (generate) and the resource (shareable payment link for a customer), which is specific enough to convey the primary function. However, it does not explicitly differentiate from sibling tools like initiate_payment, which could also produce a payment URL, so it misses the top score for 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 initiate_payment or verify_payment. It also doesn't mention any prerequisites or context (e.g., whether a customer must exist). This leaves the agent without clear decision support.

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

• initiate_paymentC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full transparency burden. It discloses that a checkout URL is returned, but does not mention side effects, idempotency behavior, authentication requirements, or the asynchronous nature of the payment.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of two short sentences that directly state the action and the return value. No unnecessary words or repetition are present.

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

  Completeness2/5

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

  Given the tool's complexity (10 parameters, no output schema, no annotations, and multiple related sibling tools), the description is too minimal. It does not explain operational context, payment lifecycle, or edge cases, making it insufficient for an agent to fully understand the tool's role.

  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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific detail beyond what the schema provides, and its mention of 'any configured WariMCP provider' only restates the provider capability.

  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 initiates a payment and returns a checkout URL, using a specific verb and resource. However, it does not explicitly differentiate this from sibling tools like generate_payment_link or initiate_payout, relying mostly on the tool name and schema for distinction.

  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, nor does it mention exclusions or context. It simply states the action without explaining when it should be preferred over other payment-related tools.

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

• list_transactionsB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the obvious ('list') and does not explain what 'recent' means, sorting behavior, or whether the operation is read-only. It adds no context beyond the tool name.

  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 with no wasted words. It front-loads the core action and resource, making it easy to parse.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description is too sparse. It fails to clarify the meaning of 'recent', the structure of results, or how this tool fits into the payment workflow. The schema covers inputs but not outputs or behavioral expectations.

  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% description coverage, so baseline is 3. The description's 'optional filters' is redundant with schema fields, but it does not add any new semantic detail beyond what the schema already provides.

  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 specifies a clear verb ('list'), a distinct resource ('recent payment transactions'), and a scope ('with optional filters'). It distinguishes itself from sibling tools like initiate_payment and list_providers by clearly targeting transaction listing.

  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 contrast with payment initiation, verification, or provider listing, leaving the agent without decision support.

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

• verify_paymentB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'check the status', which implies a read operation, but does not disclose the return format, any limitations, authentication requirements, or potential side effects. This is a significant gap for a read tool with no output 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 one sentence, front-loaded with the core action, and contains no superfluous information. It is appropriately concise for the tool's simplicity.

  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 single parameter and no output schema, so complexity is low. However, without annotations or output schema, the description should ideally mention what the response will contain or any edge cases. The description covers the core purpose but misses the result shape, making it adequate but not fully complete.

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

  Parameters3/5

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

  The input schema has one parameter with a full description, achieving 100% coverage. The tool description does not add any parameter information, but the baseline of 3 is appropriate because the schema already documents the parameter adequately.

  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 ('check') and the resource ('status of a payment transaction'), which is specific enough to distinguish from sibling tools like list_transactions or initiate_payment. The resource is well-defined 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 Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context where a different tool should be used. This is a minimal viable description but lacks usage direction.

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

• refund_paymentB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It discloses only the 'completed payment' eligibility constraint, omitting refund-side effects, idempotency, or permission requirements. Limited behavioral detail.

  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?

  One clear, front-loaded sentence with no extraneous words. Efficiently communicates the core action.

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

  Completeness2/5

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

  The tool is a financial mutation with no output schema or annotations. The description is too brief to cover return behavior, side effects, or usage context, leaving significant gaps for an agent.

  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 describes all three parameters with meaningful descriptions (amount, reason, transactionId), achieving 100% schema coverage. The tool description adds no parameter-specific semantics 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 ('issue') and resource ('refund for a completed payment transaction'), clearly distinguishing it from payment initiation/verification siblings. The action and target are explicit.

  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 refunding completed payments but provides no explicit alternatives or when-not conditions. Sibling names suggest payment initiation/verification, but no direction is given.

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

• initiate_payoutA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden. It only states the action ('disburse funds') without disclosing side effects, idempotency requirements, or failure modes. The schema includes an idempotencyKey but the description does not highlight it, leaving the agent uninformed about critical behavioral aspects.

  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, front-loaded with the action verb, and includes a clarifying parenthetical. Every word contributes; there is no fluff 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?

  The schema fully documents all parameters, which mitigates the lack of detail. However, with no output schema and no annotations, the description does not explain return format, operational prerequisites, or potential errors. It is a minimal viable description for a 7-parameter mutation 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?

  Schema description coverage is 100% for all 7 parameters, so the baseline is 3. The description adds no extra meaning beyond the schema, except for implicitly mentioning the 'method' choice via 'mobile money or bank account'.

  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+resource combo ('Disburse funds to a mobile money wallet or bank account') and adds context ('seller payouts') that distinguishes it from sibling tools like initiate_payment or refund_payment. It clearly states 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 Guidelines3/5

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

  The description implies usage for seller payouts, but it does not explicitly state when to use this tool over alternatives or mention exclusions. There is no reference to sibling tools or scenarios where another tool should be used.

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

• verify_payoutA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Check the status of a payout,' which implies a read operation but does not disclose potential side effects, error behavior, or the nature of the returned status. The description is too sparse to convey meaningful behavioral traits.

  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 with no redundant words. It is appropriately sized and front-loaded, with every word contributing to the core meaning.

  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 is simple with one well-documented parameter, but there is no output schema and no annotations. The description does not explain what the response will contain or how to interpret the status, leaving a notable gap for a tool that is meant to return status information.

  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 of the single parameter (payoutId) with a clear description, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents.

  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 (check) and the resource (payout), and it distinguishes from sibling tools like verify_payment and initiate_payout by specifying payout status checks. This is a specific verb+resource combination.

  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 checking payout status, but it does not explicitly state when to use this tool versus alternatives like verify_payment or initiate_payout. No exclusions or preconditions are mentioned, so the guidance is only implied.

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

• list_providersA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool returns all providers, with configuration status and supported rails, which goes beyond the tool name. It does not mention performance, auth, or error behavior, but for a read-only list operation this is relatively transparent.

  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 front-loads the action and resource, includes the key output fields, and contains no superfluous 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 tool's simplicity (no parameters, no annotations, no output schema), the description adequately covers what it does and what information it returns. It could specify the exact response shape, but it already mentions the main fields (providers, status, rails), making it sufficient for agent decision-making.

  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 baseline is 4. The description adds no parameter details because none exist; nothing is missing.

  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 'all WariMCP payment providers', and further details the included attributes (configuration status and supported rails). It is distinct from sibling tools, which focus on payments, transactions, and payouts rather than provider enumeration.

  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 this tool is for discovering available payment providers and their capabilities, but it does not explicitly state when to use it versus alternatives or mention exclusions. As a simple enumeration tool, context is inferable, but there is no direct guidance.

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