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 discloses that it executes a settlement (a mutating action) and that for non-test orders it returns guidance without changing anything. It also mentions prerequisites that may affect behavior (pending payment session, allowance). This goes beyond simply stating the action and provides useful context about side effects and network (preprod). However, it doesn't explicitly state whether the settlement is reversible or what exactly happens to the order after settlement, leaving some ambiguity.

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

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

The description is concise and well-structured, with the most critical information ('Test / QA only — do not use for customer orders') front-loaded. Every sentence adds necessary context: the exclusion, the alternative payment method, the specific action, prerequisites, and the fallback behavior. No redundant words or fluff, making it efficient for an agent to parse quickly.

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

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

Given the tool's moderate complexity and lack of output schema, the description covers the essential aspects: what it does, when to use it, prerequisites, and behavior for non-matching inputs. It does not explicitly describe the return value or output format, which might be important for an agent to know (e.g., success/failure status). However, for a test/QA tool, this might be less critical, and the description still provides sufficient context to decide whether to call it and what to expect in terms of side effects.

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

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

The input schema already describes both parameters (order_id with example format, customer_key as the test customer's key). The description adds the requirement that customer_key must belong to a test customer, but this is already in the schema. It also mentions that the payment session must be pending, which relates to the order_id indirectly. With 100% schema coverage, the description adds marginal value beyond the schema, 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.

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

The description clearly states the tool's purpose: it executes a Cardano preprod A→B→A settlement for a test customer's order. It explicitly identifies itself as test/QA only and distinguishes itself from customer payment flows (PromptPay QR) and from sibling tools like check_payment_status or create_payment by specifying its exact action and scope. The verb 'Executes' and the resource 'Cardano preprod A→B→A settlement' are 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.

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

The description gives explicit when-to-use guidance: only for test/QA, not for customer orders, and only when certain prerequisites are met (test customer's customerKey, pending payment session from create_payment, monthly auto-settle allowance). It also states the behavior for non-matching order_ids (returns PromptPay guidance and changes nothing), effectively saying when not to use it. While it doesn't name a specific alternative tool, it clearly indicates the condition for use and provides a fallback behavior.

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