Server Quality Checklist

Tool Scores

• refund_paymentC
  2.9/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 disclosing behavioral traits. It states the action but does not say whether the refund is irreversible, whether it mutates the transaction status, whether it requires special permissions, or what happens in error cases. This is a significant gap for a side-effectful payment operation.

  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 filler. Every word carries meaning, the core action is front-loaded, and the qualifying details ('full or partial', 'by transaction ID') are integrated efficiently.

  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 mutation tool with no annotations and no output schema, the description is incomplete for an agent to invoke it reliably. It lacks usage context, behavioral consequences, return information, and error handling. While the schema covers parameters fully, the overall context is not sufficient for a refund operation with meaningful financial side effects.

  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 describes all three parameters, including the meaning of Amount as the full or partial refund amount. The description restates 'by transaction ID' and 'full or partial', which adds minimal value beyond the schema. With 100% schema coverage, the baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states a specific action ('refund'), a resource ('payment'), and a scope ('full or partial') keyed by transaction ID. It reads as an unambiguous definition, but it does not explicitly distinguish itself from the sibling 'void_payment', which is a related but semantically different operation, so it falls short of full 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 gives no guidance on when to use this tool versus alternatives like 'void_payment', 'charge_payment', or 'auth_payment'. It implies the trigger (a transaction ID) but does not state the context, prerequisites, or exclusions that would help an agent choose correctly.

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

• update_subscriptionC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must carry the behavioral disclosure burden. It only says 'Update subscription parameters,' but does not disclose effects such as whether changes are immediately applied, whether confirmation is required, whether billing is prorated, or what the response contains. For a mutation tool, this is a notable gap.

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

  Conciseness4/5

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

  The description is a single concise sentence with no fluff, and the action is front-loaded. It could be slightly more structured by matching the schema parameter names exactly, but it is appropriately compact.

  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 has 8 parameters, no output schema, no annotations, and a modest description. The description omits half the parameters, provides no usage context, and does not mention required fields or operational effects, making it incomplete for an agent to confidently invoke 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%, so the schema already documents all parameters meaningfully. The description repeats a subset of parameter names ('amount, interval, period, description') but adds no additional semantic detail, 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.

  Purpose4/5

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

  The description states a specific verb ('Update') and resource ('subscription') and lists several updateable parameters. This clearly distinguishes it from sibling tools like create_subscription and cancel_subscription, though it omits several actual parameters from the schema.

  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 given about when to use this tool instead of create_subscription, cancel_subscription, or other siblings. There is no context about prerequisites, required fields, or situations where updating is appropriate versus creating a new subscription.

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

• auth_paymentA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the single most important behavior—funds are blocked, not charged, until confirmed. But it omits life-cycle facts such as whether the hold expires, that void_payment releases the hold, and what the call returns, leaving a meaningful transparency gap.

  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 short sentences with the core concept front-loaded: 'Two-step payment (authorize/hold)' followed by one clarifying sentence. There is no filler, and each sentence contributes distinct 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?

  For a mutating payment tool with 10 parameters, no annotations, and no output schema, the description covers the core mechanics but misses flow context: what the response contains (the payment ID needed by confirm_payment or void_payment) and the consequence of never confirming. Given the sibling list includes confirm_payment and void_payment, this follow-up knowledge matters for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter-level meaning beyond the schema; Amount is already documented as the authorization (holding) amount and CardCryptogramPacket as the card cryptogram.

  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 (authorize/hold) and the resource (payment funds): 'Two-step payment (authorize/hold). Funds are blocked but not charged until confirmed.' The wording positions it as the first stage of a two-step flow, semantically distinguishing it from siblings like charge_payment and confirm_payment, though no sibling is named explicitly.

  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 'two-step payment' framing implies this tool is for flows that require an authorization hold, and 'not charged until confirmed' hints that confirm_payment is the follow-up step. However, the description never explicitly says when to use this tool versus charge_payment, confirm_payment, or void_payment, so usage guidance is implied rather than stated.

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

• create_orderA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose a primary behavior beyond the name: the tool creates an invoice link and returns a URL. However, it does not mention side effects, permissions, idempotency, or how options like SendEmail and RequireConfirmation alter the flow, leaving meaningful behavioral gaps.

  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 short sentences with no filler or repetition. The core purpose is stated first, and the return value is given immediately, making the definition easy to parse and act on.

  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 description covers the core purpose and the primary return value, and the rich schema handles parameter documentation. However, with 10 parameters, no output schema, and no annotations, the description still leaves gaps around selecting optional behaviors, understanding edge cases, and distinguishing from payment siblings.

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

  Parameters3/5

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

  Schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds no parameter-level meaning 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.

  Purpose4/5

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

  The description uses a specific verb ('Create') and a specific resource ('payment order (invoice link)'), and states the key outcome (a URL the payer can open). It does not explicitly contrast with siblings like charge_payment or create_subscription, but the invoice-link wording strongly implies a deferred-payment flow.

  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?

  There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternatives are named. The phrase 'Returns a URL the payer can open to pay' implies this tool is for generating a payment link rather than an immediate charge, but the implication is left to the reader.

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

• charge_paymentA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does disclose the key behavior — immediate one-step charge — and specifies that the card cryptogram comes from the CloudPayments widget. However, it omits other important behavioral context such as response shape, idempotency/duplicate-charge risk, failure modes, or whether the charge is immediately captured.

  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 with no filler. It states the core behavior first and then lists the essential inputs, earning every word it uses.

  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 financial mutation tool with no annotations, no output schema, and 10 parameters, this description is too sparse. It does not explain return values, how it differs from auth_payment/confirm_payment in practice, error behavior, duplicate-charge safeguards, or what downstream actions (void/refund) might be needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description only restates the three required inputs (card cryptogram, amount, payer IP) without adding new format, constraints, or semantic detail beyond what the schema 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 clearly identifies a specific verb ('charge') and resource ('payment'), and the phrase 'one-step payment (immediate charge)' distinguishes it from sibling tools like auth_payment and confirm_payment, which imply a two-step flow. It also names the key inputs needed, leaving 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?

  The description gives clear context: use this tool when you need an immediate, one-step charge rather than an authorized-then-confirmed payment. It does not explicitly name alternatives or state when not to use it, so it stops just short of full routing guidance.

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

• confirm_paymentA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It does state the key behavior—this tool charges a held amount—and notes that partial confirmation is possible. However, it does not mention irreversibility, permissions, or what happens to the remainder of an authorization after a partial confirm.

  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: 'Confirm an authorized payment' immediately names the operation, and the parenthetical 'charge the held amount' explains the mechanism. Every word adds value and there is no redundant filler.

  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 three-parameter tool, the description conveys the core operation and the partial-amount option. However, it lacks explicit guidance on the required prior state beyond 'authorized,' the effect of partial confirmation on the remaining authorization, or what response or next steps the agent should expect.

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

  Parameters4/5

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

  The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds useful semantic context by clarifying that 'Amount' represents the held amount being charged and explicitly introduces the partial-amount possibility, which reinforces the schema's meaning.

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

  Purpose4/5

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

  The description clearly identifies the action: confirming an authorized payment and charging the held amount, with the optional nuance of a partial amount. This distinguishes it from authorization, void, and refund operations, though it does not explicitly name a sibling alternative.

  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 'Confirm an authorized payment' establishes the intended context: this tool is for payments that have already been authorized and have a held amount. It gives clear context but does not explicitly state when not to use it or direct the agent to alternatives like void_payment or refund_payment.

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

• create_subscriptionA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the disclosure burden. It does disclose the two most material behaviors — automatic recurring charges and the token prerequisite — but omits other facts relevant to a money-moving tool: whether the first charge is immediate, the two-step auth/confirm flow implied by RequireConfirmation, and failure/reversibility behavior.

  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?

  Three short sentences with zero filler. The primary action is front-loaded, and each subsequent sentence adds a distinct fact: the prerequisite, then the behavioral consequence of automatic charging.

  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 an 11-parameter financial tool with no annotations and no output schema, a two-sentence description is thin. Missing guidance includes what the response contains, whether StartDate triggers an immediate debit, and the confirmation workflow when RequireConfirmation=true — gaps an agent cannot safely infer when setting up recurring charges.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 11 parameters, including the Token source (Transaction.Token) and currency default. The description adds modest context by explaining why the token is required, but it does not compensate for anything the schema lacks, so the 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 states a specific verb ('Create') and a specific resource ('recurring subscription'), and reinforces scope with 'Charges automatically on schedule.' This distinguishes it from one-off payment siblings like charge_payment and from the subscription lifecycle siblings (update_subscription, cancel_subscription, list_subscriptions) without requiring the agent to open the schema.

  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 prerequisite is explicit: 'Requires a token from a previous payment,' which tells the agent this tool is only callable after a payment step has produced a token. It provides clear context for when to invoke it, but does not explicitly name alternatives or state exclusions (e.g., when to prefer charge_payment for one-time charges or update_subscription for modifying an existing plan).

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

• get_transactionA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does reveal that the tool returns status, amount, card info, and timestamps, which helps the agent understand the operation. However, it omits obvious behavioral specifics like what happens when the transaction does not exist, whether card info is masked, or any authorization requirements.

  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 short sentences with no filler. The core action is front-loaded, followed by a compact list of return fields. Every word earns its place; it is appropriately sized for a simple lookup 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?

  For a one-parameter read-only lookup with no output schema, the description provides the essential information: what it finds and what it returns. Minor gaps remain, such as error behavior when the ID is not found and whether card info is returned in full or masked, but nothing critical is missing for a basic fetch operation.

  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 the TransactionId parameter already described as 'ID транзакции' and having exclusiveMinimum 0. The description adds no further parameter semantics beyond confirming that the lookup is by ID, 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?

  The description uses a specific verb ('Find') with a precise resource ('transaction by ID'), and lists the returned fields (status, amount, card info, timestamps). This clearly distinguishes it from sibling tools like list_transactions or payment operation tools, leaving no ambiguity about what it 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 intended usage is implied: use this when you have a specific transaction ID and want its details. However, the description does not explicitly contrast it with alternatives such as list_transactions, nor does it state when not to use it. The guidance is adequate but leaves the routing to inference.

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

• list_transactionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It does usefully disclose that completed, authorized, and declined transactions are included, but it omits other behavioral details such as pagination, sorting, timezone handling implications, or whether the operation has any 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 short sentences with no filler. The core purpose is front-loaded, and the additional status detail is concise and relevant.

  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 two-parameter listing tool with no output schema, and the description covers the main behavior and returned status categories. Some details like pagination limits or result ordering are absent, but the description is adequate for an agent to invoke the tool correctly in common cases.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description's reference to 'a given date' aligns with the Date parameter but adds no additional semantic detail beyond the included YYYY-MM-DD format and timezone explanation already present in 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 states a specific verb ('List'), a clear resource ('transactions'), and a precise scope ('for a given date'). It also names the returned status types, which helps distinguish this tool from transaction-action siblings like void_payment, refund_payment, or get_transaction.

  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 a date-based listing use case, which is clear enough for choosing this tool over the mutation-focused siblings. However, it does not explicitly mention when not to use it or point to alternatives such as get_transaction for retrieving a single transaction.

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

• cancel_subscriptionA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the major side effect of stopping future charges, which is more than a tautological restatement. However, it does not mention reversibility, impact on the current billing period, permissions, or error behavior, so transparency is partial.

  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 short sentences with no filler. The action is stated first, followed by the key consequence. 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 one-parameter mutation with no output schema, the description provides enough information to select and invoke the tool correctly. It does not describe the return value or post-cancel subscription state, but these are not essential for correct invocation. Slight deduction for not explicitly routing away from payment-focused siblings.

  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 sole parameter is fully documented in the schema as 'Subscription ID to cancel', and the description reinforces the by-ID behavior. Since schema description coverage is 100%, the description does not need to add further parameter meaning; it simply meets the baseline.

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

  Purpose5/5

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

  Clearly identifies the operation (cancel), the target resource (subscription), the scope (active), and the identifier mechanism (by ID). The final clause 'Stops all future charges' adds a concrete consequence that distinguishes this from sibling tools like update_subscription, refund_payment, and void_payment.

  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 states the prerequisite ('active subscription') and the key outcome ('stops all future charges'), giving an agent clear context for when to use it. It does not explicitly name alternatives or exclusions, but the active-subscription qualifier and future-charges wording imply the appropriate use case.

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

• list_subscriptionsA
  4/5.0
  Behavior3/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 explaining behavior. The verb 'List' clearly implies a read-only operation, which is helpful, but the description does not disclose details such as whether canceled subscriptions are included, pagination behavior, or the shape of the returned data.

  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 with no wasted words. Every part contributes to understanding the tool's purpose and required input.

  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 listing operation, the description is nearly complete: it states what is listed, for whom, and identifies the required parameter. The only missing context is output or pagination behavior, but that is a minor gap for such a straightforward 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 schema already fully documents the required parameter AccountId with the description 'User ID to list subscriptions for.' The tool description repeats the AccountId reference but adds no new semantic information 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 uses a specific verb ('List') and resource ('subscriptions') and scopes it to a given user, which makes the tool's purpose immediately clear. It also distinguishes itself from sibling tools like create_subscription, update_subscription, and cancel_subscription even without naming them.

  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: this tool is for retrieving all subscriptions for a specific user identified by AccountId. It does not explicitly mention alternatives or exclusions, but the resource type and read-only nature imply when it should be used versus transaction or mutation tools.

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

• void_paymentA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses that the action releases a hold and is only valid before confirmation, which is useful, but it does not describe side effects, reversibility, error conditions, or required permissions.

  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 short sentences with no filler. The primary action is front-loaded and the critical constraint is stated immediately afterward.

  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 single-parameter, low-complexity tool, the description provides the essential context: what the tool does and when it applies. It lacks explicit guidance on post-confirmation alternatives, but the before-confirmation constraint is sufficient for correct selection in most cases.

  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 TransactionId fully with a description and constraint, so coverage is 100%. The tool description adds no parameter-specific detail, which is acceptable under the baseline for high schema coverage.

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

  Purpose5/5

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

  The description uses a specific verb ('Void') and resource ('an authorized payment') and clarifies the action with 'release the hold'. It also distinguishes this from siblings like refund_payment by noting it works only before confirmation.

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

  Usage Guidelines4/5

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

  The description gives a clear precondition: 'Works only before confirmation.' This tells the agent when to use the tool and implicitly when not to use it, though it does not explicitly name alternatives such as refund_payment for confirmed transactions.

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