agentic-commerce

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

The description adds value beyond annotations by stating the tool 'Returns unsigned transaction data', explaining that it does not directly submit the transaction. Combined with destructiveHint:true, the agent understands this is a state-changing operation that requires further steps. No contradictions.

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 extremely concise with only two sentences. The first sentence clearly defines the action, and the second provides essential usage context. No wasted words.

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 has 5 parameters, no output schema, and a destructive hint, the description covers the core purpose, prerequisite relationship with siblings, and return type. It could optionally mention the need to send the returned transaction via send_signed_transaction, but this is inferable from sibling tools. Overall complete enough for an agent.

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?

Input schema has 100% coverage with detailed descriptions for all 5 parameters. The tool description does not add additional parameter semantics beyond what the schema provides. Baseline 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 grants ERC-20 allowance to the Boson Protocol contract, specifying the verb 'grants' and the resource 'allowance'. It distinguishes itself from sibling tools like commit_to_offer and deposit_funds by indicating it's a prerequisite.

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 explicitly says 'Must be called before commit_to_offer or deposit_funds when using non-native exchange tokens', providing clear usage context. It does not mention when not to use or alternatives, but the guidance is sufficient for an agent to decide when to invoke.

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

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

Annotations indicate destructive behavior, and the description adds specific details: the caller forfeits a penalty, remainder refunded, and returns unsigned transaction data. This provides beyond-annotation context.

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?

Two concise sentences cover purpose, caller identity, penalty/refund, and output. No extraneous info. Could be slightly more structured but highly efficient.

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?

For a cancellation tool with no output schema, the description adequately covers action, caller requirement, financial impact, and return type. Lacks explicit note on prerequisites like 'must have a committed voucher' but implied.

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?

Schema coverage is 100% with detailed parameter descriptions. The tool description does not add new parameter semantics beyond summarizing the effect. Baseline 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 action ('cancels a committed voucher'), specifies the caller role ('buyer'), and notes the financial consequence ('forfeits buyerCancellationPenalty; remainder is refunded'). This uniquely identifies it among sibling tools like revoke_voucher.

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 imposes a clear usage condition ('Caller must be the buyer') and describes the financial outcome. It does not explicitly state when not to use or compare with alternatives, but the context is sufficient for an agent.

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

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

Annotations already indicate destructive (destructiveHint=true). The description adds that it returns unsigned transaction data, requiring further signing and sending. No contradiction with annotations.

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

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

Four short, direct sentences each conveying essential information: purpose, caller requirement, collateral requirement, and return type. No wasted words.

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?

While the description covers key aspects, it leaves out details about how to provide matching collateral, the significance of the unsigned transaction data, and the overall workflow. For a tool with 7 parameters and no output schema, more context would be beneficial.

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 provides comprehensive descriptions for most parameters (71% coverage). The tool description adds no additional meaning beyond what is in the schema, so baseline score of 3 applies.

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 it fulfils a buyer-initiated offer by the seller, with explicit mention of 'creator='BUYER'', distinguishing it from sibling tools like commit_to_offer and commit_to_conditional_offer.

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 provides clear context: caller must be the seller and must provide matching collateral. It does not explicitly exclude other scenarios or name alternatives, but the precondition is helpful.

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

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

Annotations already indicate destructiveHint=true. Description adds 'Returns unsigned transaction data' and the token-holding requirement, but does not detail side effects, reversibility, or gas costs. Adequate but not rich.

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

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

Three concise sentences, front-loaded with the main action. No unnecessary words.

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?

No output schema, but description states return type. Covers purpose, usage, and prerequisite. Lacks mention of subsequent steps (e.g., need to send transaction), but sibling tools handle that.

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?

Schema coverage is 100% with detailed descriptions. The overall description adds context by linking parameters to the gating concept and specifying the use case, going beyond the schema.

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?

Clear verb 'commits to', specific resource 'token-gated (conditional) offer', and directly distinguishes from sibling commit_to_offer by stating 'use this instead of commit_to_offer for offers created via create_offer_with_condition'.

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?

Explicitly states when to use (conditional offers from create_offer_with_condition) and provides alternative (commit_to_offer). Also includes prerequisite: caller must hold the gating token.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the operation is atomic and returns unsigned transaction data, but does not detail side effects or additional behavioral traits beyond what annotations convey.

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?

Two sentences that efficiently communicate the purpose, atomicity, prerequisite, and output. No redundant information; front-loads the core action.

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?

The description lacks details about the returned transaction data format and how to use it with sibling tools like send_signed_transaction. However, given the context of sibling tools and annotations, it is adequate for an agent to infer next steps.

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?

Schema coverage is 100%, and the description does not add significant meaning beyond the parameter descriptions in the schema. The mention of 'gating tokenId' is already present in the tokenId description.

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?

Description clearly states the tool atomically commits to a token-gated offer and redeems the voucher in one transaction, distinguishing it from siblings like commit_to_conditional_offer and commit_to_offer_and_redeem_voucher.

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 provides a clear prerequisite: buyer must hold the gating token. It implicitly suggests use when you need atomic commit+redeem for conditional offers, but does not explicitly mention when not to use or compare to alternatives.

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

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

Adds behavioral context beyond annotations: mentions that it creates an exchange and mints a voucher NFT (consistent with destructiveHint=true), and notes that it returns unsigned transaction data. No contradiction with annotations.

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

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

Two sentences, front-loaded with purpose, no redundant information. Every word serves a purpose.

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?

Lacks details about the return format or how to use the unsigned transaction data with sibling tools like send_signed_transaction. Does not cover error scenarios or lifecycle after commit. Adequate but could be more complete.

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?

Adds value over the 100% schema coverage: explains buyer parameter optionality and interaction with executionMode, provides configId format example, and clarifies signerAddress must match the wallet. Enhances understanding beyond schema descriptions.

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 action ('commits to an offer, creating an exchange and minting a voucher NFT') and specifies who calls it (buyer). However, it does not explicitly differentiate from sibling commit tools like 'commit_to_buyer_offer' or 'commit_to_conditional_offer'.

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?

Provides clear guidance: caller is buyer unless 'buyer' param is set, and for ERC-20 offers, 'approve_exchange_token' must be called first. Lacks explicit advice on when not to use this tool or alternatives.

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

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

Description adds behavioral context beyond annotations: atomicity, skipping voucher transferability, immediate start of dispute period, and return of unsigned transaction data. Annotations already indicate destructiveHint=true, which is consistent.

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?

Description is three front-loaded sentences covering action, prerequisite, behavior, and return type without extraneous detail. Each sentence adds value.

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?

For a tool with 4 parameters (3 required) and no output schema, description adequately explains purpose, prerequisites, and return type. Could mention offer must be active but schema implies it. Overall sufficient.

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?

Schema covers all parameters with descriptions (100% coverage). Description reiterates signerAddress requirement but adds no new semantic details beyond what schema provides. Baseline of 3 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?

Description clearly specifies atomic commit and redeem in a single transaction via OrchestrationHandler. It distinguishes from sibling tools like commit_to_offer (commit only) and redeem_voucher (redeem only) by combining both actions.

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?

Explains prerequisite (must hold ERC-20 allowance via approve_exchange_token) and behavioral implications (skips transferability, starts dispute clock). While not exhaustively listing alternatives, it provides enough context for when to use this combined operation.

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

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

Annotations already declare destructiveHint=true, so the description's mention of releasing funds and returning transaction data adds moderate context. It does not detail side effects, permissions, or error states, but the combination with annotations gives a baseline understanding of behavior.

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 two sentences with no extraneous information. It front-loads the core action and condition, then adds caller constraints and return value. Every sentence is necessary and efficient.

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 has 4 parameters, no output schema, and is destructive, the description covers the essential context: when to call, who can call, and what is returned. It could mention the need for subsequent signing/transaction sending, but the sibling tools (e.g., send_signed_transaction) imply that flow. Overall, it is mostly complete.

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?

Schema description coverage is 100%, with each parameter already described. The description does not add new meaning beyond the schema's parameter descriptions, so the baseline of 3 applies.

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 action ('completes an exchange'), the resource ('exchange'), and the condition ('after the dispute period expires, releasing funds to the seller'). It distinguishes callers (seller vs. buyer) and mentions the return value ('unsigned transaction data'), making the purpose distinct from sibling tools like raise_dispute.

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 provides clear context on when to use the tool: seller after dispute period, buyer anytime post-redemption. It implicitly suggests not to use before the dispute period. However, it does not explicitly exclude alternative tools or state when not to use, but the context is sufficient for a typical user.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by revealing that the tool does not execute the transaction but instead returns unsigned transaction data, which is critical behavioral context. It also clarifies there are no prerequisites, adding further transparency.

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 extremely concise with three clear sentences covering purpose, usage context, and return value. No unnecessary words.

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 simplicity (2 parameters, no output schema), the description adequately covers the context: what it does, when to use it, and what it returns. It could hint at next steps (e.g., sending the transaction), but is functionally complete.

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?

Schema coverage is 100% and both parameter descriptions in the schema are detailed. The description does not add additional meaning beyond restating the signerAddress. Therefore, baseline score of 3 is appropriate as the schema already handles parameter semantics.

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 verb 'Creates', the resource 'buyer account', and the target 'for signerAddress', distinguishing it from sibling tools like 'create_seller'. It provides the specific purpose: required before a buyer can commit to seller-initiated offers.

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 explicitly states when this tool is needed ('Required before a buyer can commit to seller-initiated offers for the first time') and that there are no prerequisites ('No prerequisites'). It provides clear context for usage without listing alternatives, which is sufficient given the specific prerequisite role.

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

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

The description is consistent with the readOnlyHint annotation, adding that it returns a typed data structure and requires local signing. This provides useful behavioral details beyond the annotation alone.

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 two sentences with no filler, front-loading the core purpose and then adding necessary usage details. Every sentence adds value.

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 complexity (4 required params, no output schema), the description covers its purpose, output type, and prerequisites. Lacks error conditions or exact structure, but sufficient for typical use.

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?

All parameters are described in the schema, and the description adds critical context about buyerPercentBasisPoints needing mutual agreement and configId format. This fully covers meaning beyond the schema.

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 generates EIP-712 typed data for a mutual dispute resolution proposal, specifying the resource and action. It distinguishes itself from siblings like resolve_dispute, which consumes the signed data.

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 explains that both buyer and seller must sign the same value before calling resolve_dispute, providing usage context. However, it does not explicitly state when not to use the tool or mention alternatives, leaving room for ambiguity.

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

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

Discloses that the tool returns an unsigned transaction, requires local signing or metaTx, and mentions the important constraint that all dates are in milliseconds and amounts as strings in wei. Annotations already indicate destructiveHint=true, but description adds crucial details beyond annotations.

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?

Two sentences that pack essential information: purpose, prerequisites, data formats, and execution modes. No wasted words; front-loaded with the most critical details.

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 complexity (25 params, 15 required) and no output schema, the description adequately covers the high-level workflow and return type ('unsigned tx'). Could mention that some parameters depend on each other, but overall complete enough for an agent to use correctly.

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

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

Schema coverage is 96%, so parameters are well-documented. The description adds value by explaining the wei format, timestamp units, and the relationship between parameters like voucherValidDurationInMS vs voucherRedeemableUntilDateInMS. Some parameters like royaltyInfo are nested and need further clarity, but overall good.

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?

Clearly states 'Creates a product offer' with specific verb and resource. Distinguishes from sibling tools by mentioning prerequisites and flow, and contrasts with tools like 'create_offer_and_commit'.

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?

Explicitly states prerequisites (seller account, metadata) and two execution modes. While it doesn't exhaustively contrast with all siblings, it provides clear context for when to use this tool.

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

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

Annotations provide destructiveHint=true and readOnlyHint=false. The description adds that the operation is atomic, returns unsigned transaction data (so not a direct on-chain execution), and outlines the prerequisite workflow. This adds behavioral context beyond annotations, though more detail on side effects (e.g., exact state changes) would improve transparency.

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 three sentences, each essential: core function, prerequisite, and usage scope. It is front-loaded with the primary action. No redundant words; ideal length for a complex tool.

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 33 params, no output schema, and high schema coverage, the description covers the key behavioral details: atomicity, prerequisite, return type, and usage context. It does not explain error conditions or post-operation steps, but for a tool with rich schema, it is sufficiently complete.

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?

Schema coverage is 94%, so the schema already documents most parameters well. The description adds high-level context about the signature workflow and return type but does not elaborate on individual parameters beyond what the schema provides. Per guidelines, baseline is 3.

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 atomically creates a private offer and commits a buyer, using the verb 'creates' and 'commits'. It specifies 'private/bilateral trades', which distinguishes it from siblings like commit_to_offer (for public offers) and create_offer (just creation). The resource and action are unambiguous.

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

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

The description includes a prerequisite ('call sign_full_offer, sign...') and indicates usage for 'private/bilateral trades'. It does not explicitly list when not to use or compare alternatives, but the context signals many sibling tools for different scenarios. The guideline is clear enough for agents to infer appropriate use.

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

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

Annotations indicate destructiveHint=true, but the description adds valuable behavioral context: atomicity, the OrchestrationHandler, and that it returns unsigned transaction data. No contradictions with annotations.

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

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

The description is three sentences, front-loaded with the core purpose, then prerequisites and usage, then return type. No superfluous words.

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 complexity (33 parameters, 20 required, nested objects) and no output schema, the description only says 'Returns unsigned transaction data.' More detail on the return format or error conditions would improve completeness.

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?

Schema description coverage is 94% (very high), so the baseline is 3. The description does not add additional parameter-level meaning beyond what the schema already provides; it merely mentions prerequisites.

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 it atomically creates an offer, commits a buyer, and redeems the voucher in one transaction. It distinguishes from siblings like 'create_offer_and_commit' and 'commit_to_offer_and_redeem_voucher' by specifying the combined operation and 'instant-fulfilment private trades'.

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 explicitly states 'Use for instant-fulfilment private trades' and references the same prerequisites as 'create_offer_and_commit', giving clear guidance on when to use. It lacks explicit exclusions or when-not-to-use scenarios but is still strong.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. Description adds that the tool returns unsigned transaction data and references prerequisites, but does not elaborate on behavioral details beyond annotations.

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?

Two sentence description, front-loaded with purpose, no redundant words.

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?

High number of params (26) but schema coverage is high. Description covers return value but could mention common errors or prerequisites for the referenced create_offer. Overall adequate.

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?

Schema coverage is 92%, so params are well-defined in schema. Description mentions condition parameters (gate token, method, threshold) but adds only marginal context beyond the schema.

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?

Clearly states the verb 'Creates' and the resource 'offer gated by token-ownership'. Distinguishes from sibling create_offer by specifying the added condition object.

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?

States 'Same prerequisites as create_offer plus a condition object', implying when to use this over create_offer. Does not explicitly exclude use cases or mention alternatives.

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

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

Annotations indicate destructive operation (destructiveHint: true) and not read-only. Description adds that signerAddress is auto-set as admin/assistant/treasury and returns unsigned transaction data, providing useful behavioral context beyond annotations.

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?

Two sentences, no filler. Essential information is front-loaded: action, protocol, prerequisite, key behaviors, return type.

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 18 parameters and no output schema, the description is adequate but not thorough. It covers purpose, prerequisite, key parameter behavior, and return type, but lacks details on other parameters, error conditions, and full response structure.

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?

With only 39% schema description coverage, the description adds some value by mentioning 'seller metadata' and 'royaltyPercentage', but does not explain all 18 parameters. The signerAddress auto-assignment is helpful but incomplete coverage.

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?

Clear verb+resource: 'Creates a seller account on Boson Protocol' with prerequisite context. Distinguishes from sibling tools (e.g., update_seller, create_buyer).

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?

States 'Required before creating any offers', giving clear prerequisite context. Does not explicitly list alternatives or when not to use, but usage context is clear.

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

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

Annotations indicate destructiveHint=true (mutation). Description adds that the action decides a dispute and returns unsigned transaction data. No contradiction. Could elaborate on irreversibility, but adequate.

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?

Two sentences packed with key information: purpose, caller requirement, parameter detail, and return type. No fluff, front-loaded with main action.

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?

For a tool with no output schema, it specifies return is unsigned transaction data. That is sufficient for a blockchain tool. Could mention consequences or state changes, but context is reasonable.

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?

Schema coverage is 100% with descriptions. Description adds context for buyerPercent (basis points, range 0-10000) and reiterates caller condition. Additional value beyond schema, but not extensive.

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 explicitly states the tool decides an escalated dispute, specifies caller requirements (dispute resolver), and mentions output (unsigned transaction data). This distinguishes it from sibling dispute tools like resolve_dispute or escalate_dispute.

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?

Provides a clear condition for who can call (must be the dispute resolver). Explains buyerPercent range in basis points. Does not explicitly list when to use versus alternatives, but the condition is actionable.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=true, establishing the tool as state-changing and potentially destructive. The description adds value by noting it 'Returns unsigned transaction data' and the prerequisite call, but does not elaborate on the nature of the destruction or other behavioral traits beyond what annotations provide.

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 extremely concise with two sentences. The first sentence immediately conveys the core purpose, and the second adds essential operational details (prerequisite and return type). No filler or redundancy.

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 6 parameters (5 required), no output schema, and comprehensive schema descriptions, the description covers the main operation, prerequisite, and return type. It doesn't explicitly guide the agent on how to handle the returned unsigned transaction (e.g., calling send_signed_transaction), but the schema's executionMode parameter covers that. Overall, it's largely 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.

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

The input schema has 100% description coverage for all 6 parameters, so the schema already documents them thoroughly. The description adds minimal extra meaning (e.g., mentions the prerequisite again and the return type), which is sufficient to maintain the baseline of 3.

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 verb 'Deposits' and the resource 'ERC-20 or native tokens into an entity's protocol treasury', specifying the action and scope. It indirectly distinguishes from sibling tools like `withdraw_funds` and provides a prerequisite relationship with `approve_exchange_token`, making the purpose unambiguous.

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

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

The description provides clear context for when to use the tool (depositing tokens) and includes a crucial prerequisite ('For ERC-20, call approve_exchange_token first'). However, it does not explicitly state when not to use it or mention alternatives beyond the prerequisite, stopping short of a 5.

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

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

The description adds behavioral context beyond annotations: it states who can call (buyer) and a necessary condition (fee covered). The output ('unsigned transaction data') is disclosed. No contradictions with annotations (destructiveHint=true is consistent with 'escalates').

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 three sentences, each adding value: purpose, caller constraint, fee condition, output type. No superfluous words. The most critical information is front-loaded.

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 no output schema, the description explains the return value (unsigned transaction data). It could be improved by noting that the transaction must be signed and sent subsequently, but the broad context is sufficient for a mutation tool with 4 parameters.

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?

Schema coverage is 100%, so the schema already describes all parameters well. The description does not add parameter-specific meaning; it only mentions the output. Baseline 3 is appropriate as the description does not reduce ambiguity beyond the schema.

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 verb 'Escalates', the resource 'stale dispute', and the target 'third-party dispute resolver'. It distinguishes this tool from siblings like 'raise_dispute' or 'expire_dispute' by specifying the escalation action and prerequisites.

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 provides context: caller must be the buyer, and the resolver's fee must be covered. These conditions help the agent know when to use this tool. However, it does not explicitly list alternative tools or when not to use it, leaving some room for ambiguity among dispute-related siblings.

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

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

Describes permissionless execution and return type (unsigned transaction data), adding value beyond annotations that indicate destructiveness and mutation. No contradictions with annotations.

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

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

Three sentences, each providing essential information without verbosity. Front-loaded with the core action.

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?

Covers purpose, condition, and return type adequately. Lacks details on irreversible effects and exact return format, but sufficient for a straightforward mutation tool with good annotations.

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?

Schema coverage is 100% with each parameter described. Description adds no further parameter details, so baseline score of 3 applies.

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?

Description clearly states the action 'marks a dispute as expired' and identifies the resource. It is specific and actionable, but does not explicitly differentiate from sibling tools like expire_dispute_batch or expire_escalated_dispute.

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?

Provides context on when to use ('Exchange must be in Disputed state past its timeout') and notes permissionless access, but lacks guidance on when not to use or mention of alternative sibling tools.

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

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

Beyond annotations (destructiveHint: true), the description adds that it returns unsigned transaction data (indicating a two-step process) and is permissionless. No contradictions with annotations.

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

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

The description is a single sentence plus a concise note; it is front-loaded with the verb and resource, with zero wasted words.

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?

The description covers what the tool does, prerequisites, permissionless nature, and return type. Without an output schema, it explains return value adequately. Could mention the unsigned transaction implies local signing.

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?

Schema coverage is 100% with detailed parameter descriptions. The description adds no new semantic value for parameters beyond repeating the exchange state condition, which is baseline.

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 marks multiple expired disputes in one transaction, specifying the resource (disputes) and batching action. It distinguishes itself from sibling tools like expire_dispute (singular) and expire_escalated_dispute.

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?

It provides a prerequisite (exchanges must be in 'Disputed' state past their timeouts) and notes it's permissionless. However, it does not explicitly contrast with alternatives or when not to use it.

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

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

The description discloses that the tool returns unsigned transaction data and is permissionless. The destructive nature (matching the destructiveHint annotation) is implied by 'expire,' but no further details on side effects or reversibility are given.

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 extremely concise, using only three sentences with no superfluous information. The key action and constraints are front-loaded in the first sentence.

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?

The description includes the trigger condition, accessibility ('permissionless'), and return type (unsigned transaction). For a simple transactional tool without an output schema, this covers the essential context.

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?

All three parameters are fully described in the input schema with 100% coverage. The description does not add additional context or examples beyond what the schema already provides, so baseline score applies.

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 expires an escalated dispute after the resolver's response period expires. It specifies the action ('expire') and resource ('escalated dispute'), distinguishing it from other dispute tools like 'expire_dispute' or 'resolve_dispute'.

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 provides the condition for use ('once the resolver's response period passes without a decision') and states it is permissionless. While it does not explicitly exclude alternatives, the context is clear enough for an agent to infer when to use this tool.

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

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

The description discloses that the tool is destructive (matching destructiveHint annotation) and returns unsigned transaction data, implying a write operation. It also explains caller permissions (either party). The annotations already indicate destructive, so the description adds value with state requirement and return type.

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 a single sentence of 20 words with no extraneous information. It is highly concise and front-loaded with the key action.

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 complexity (5 parameters, no output schema), the description covers the essential aspects: action, state requirement, caller eligibility, and return type. It could mention that the returned unsigned transaction must be signed and sent, but the schema parameters (executionMode, signerAddress) imply that step.

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 covers 100% of parameters with descriptions. The tool description does not add additional parameter-specific information beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('extends the deadline of an active dispute'), specifies the required state ('Dispute must be in 'Resolving' state'), and mentions the return type ('Returns unsigned transaction data'). It differentiates from sibling tools like raise_dispute or escalate_dispute by focusing on extending the timeout.

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 provides clear when-to-use guidance by stating the dispute must be in 'Resolving' state and that either party can call. It doesn't explicitly state when not to use or list alternatives, but the condition is sufficient for correct usage.

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

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

The description adds that the tool 'Supports pagination and ordering', which is beyond the read-only info already provided by annotations. However, it does not disclose details like rate limits, data freshness, or permission requirements, leaving some transparency gaps.

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 three concise sentences, front-loaded with the main action and key features (pagination, ordering, read-only). Every sentence adds value with no unnecessary words.

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?

Despite the tool having 6 parameters and no output schema, the description omits details about return values, error handling, or parameter semantics. It provides a high-level overview but leaves significant gaps for an agent to use the tool correctly.

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?

With only 17% schema description coverage, the description does not compensate by explaining parameters like productsFilter or orderBy beyond mentioning pagination and ordering. Agents lack semantic meaning for most parameters, making correct usage harder.

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 states a specific verb and resource: 'Reads product groupings with at least one non-voided variant', which is clear. However, it does not explicitly differentiate from the sibling 'search_products', potentially causing confusion for agents needing to choose between them.

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 phrase 'Useful for storefront displays' implies a use case, but there is no explicit guidance on when not to use this tool or which alternative tool to use for different scenarios (e.g., searching by arbitrary criteria via search_products).

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

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

Annotations already mark readOnlyHint=true. Description adds that no auth is required and that it returns 'all valid configId values', which goes beyond what annotations provide.

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?

Two sentences, each serving a purpose: first states the function, second gives usage guidance. No unnecessary words.

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?

For a simple tool with no params and no output schema, the description adequately explains purpose and usage. Could mention what a configId represents, but not necessary.

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 tool has zero parameters and 100% schema description coverage, so description does not need to add param info. It implicitly covers output by stating what is returned.

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 it returns all valid configId values for the server, using specific verb 'returns' and resource 'configId values'. It distinguishes itself from siblings by noting it should be called first for discovery.

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 explicitly says 'Call first to discover which network/deployment to use', providing clear context and when to use. However, no explicit exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces 'Read-only' and adds behavioral context by listing return fields ('state, timeout, buyerPercent'). No contradictions.

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?

Two sentences plus a brief return fragment. Key information is front-loaded, no unnecessary words. Highly concise and well-structured.

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?

For a simple read-only tool with three parameters (one optional) and no output schema, the description covers the input mapping, read-only nature, and return fields. It is adequate, though the optional queryVars parameter is not elaborated on but is described in the schema.

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?

Schema description coverage is 100%, so baseline is 3. The description restates the note that disputeId equals exchangeId, but this is already in the schema. No additional semantic value beyond what the schema provides.

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 'Reads a single dispute by its ID' with the specific verb 'reads' and resource 'dispute'. It also clarifies that the ID equals the exchangeId, distinguishing it from sibling tools like get_disputes for searching.

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 advises to 'Use get_disputes to search first', providing clear context on when to use this tool versus an alternative. However, it does not explicitly state when not to use this tool or mention prerequisites.

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

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

The description states 'Read-only' and 'Returns: array of resolvers with ID, fees, escalationResponsePeriod, and supported tokens.' This adds value beyond the readOnlyHint annotation by specifying the return structure and fields.

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?

Two sentences, front-loaded with purpose, no filler. Every sentence adds value.

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?

No output schema exists, so the description should provide comprehensive return and parameter details. It only briefly mentions return fields and omits parameter guidance for 6 complex parameters, including nested objects and enums.

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?

Schema coverage is only 17% (configId has a schema description). The description does not explain any of the 6 parameters, including enums and nested objects. It fails to compensate for low coverage.

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 verb (reads) and resource (registered dispute resolver entities). It also specifies the use case: finding a valid disputeResolverId for create_offer, distinguishing it from sibling tools like get_dispute_by_id or get_disputes.

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?

Description provides explicit when-to-use guidance: 'Use this to find a valid disputeResolverId for create_offer.' It does not explicitly rule out alternatives, but the context is clear enough for an agent to determine appropriate usage.

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

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

Annotations include readOnlyHint=true, and the description confirms read-only behavior. It adds details about the data source (subgraph), supported operations, and return format (array with fields), which go beyond the annotations. No contradictions.

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 extremely concise: two sentences that cover purpose, source, capabilities, and return format. No unnecessary words or redundancy.

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 complexity (6 parameters, low schema coverage, no output schema), the description adds useful context but does not fully explain all parameters or the nested object structure. However, for a read-only tool with annotations, it is fairly complete.

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?

Schema coverage is low (17% with only configId described). The description mentions pagination, ordering, and filtering but does not explicitly map each parameter to its function. Some guidance is provided, but it's not comprehensive.

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 reads dispute records from the Boson subgraph, lists supported operations (pagination, ordering, filtering), and mentions it is read-only. It distinguishes itself from sibling tools like get_dispute_by_id by focusing on listing/filtering.

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 implies usage for querying disputes with pagination/filtering but does not explicitly state when to use this tool versus alternatives like get_dispute_by_id. No when-not or alternative guidance is provided.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this by stating 'Read-only'. The description adds value by specifying the data source (Boson subgraph) and the return structure (array of exchanges with specific fields), which goes beyond what annotations provide.

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 three sentences with no fluff. It front-loads the purpose, then adds filtering and output details. Every sentence earns its place.

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 complexity (6 params, nested objects, no output schema), the description covers core purpose and filtering but omits pagination, ordering, and filter structure. It is adequate but leaves the agent needing to infer details from the schema or examples.

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?

Schema description coverage is low (17%), but the description adds meaning by mentioning filtering by buyer/seller/state, which maps to the exchangesFilter object. However, it does not detail how to use the filter object or explain the skip/first/order parameters, leaving significant gaps.

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 explicitly states it reads exchange records from the Boson subgraph, supporting filtering by buyer/seller/state. It clearly distinguishes itself from sibling tools like get_offers or get_disputes by focusing on exchanges.

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 implies usage for reading exchange records with optional filters, but it does not specify when to use this tool versus alternatives (e.g., get_offers), nor does it provide explicit when-not or prerequisite guidance.

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

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

Annotations already provide readOnlyHint=true. Description adds that signerAddress is not required and mentions pagination/ordering/filtering support, enhancing behavioral context beyond annotations.

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?

Three concise sentences covering action, features, read-only note, and return format, with no wasted words.

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?

For a read query tool with 6 parameters and no output schema, the description covers source, return structure, and key behavioral traits. Missing details on filter object structure and default pagination values, but adequate given complexity.

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?

Schema coverage is only 17% (only configId described). The description explains configId format and references get_config_ids, but other parameters (skip, first, filter, orderBy, orderDirection) are only vaguely mentioned as 'pagination/ordering/filtering' without specifics, partially compensating for schema gaps.

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 it reads treasury fund balances, specifies the source (Boson subgraph), and distinguishes from sibling write tools like deposit_funds/withdraw_funds by emphasizing read-only and no signerAddress required.

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?

Explicitly states read-only and that signerAddress is not required, providing usage guidance. While not listing alternatives, the contrast with mutation siblings is implicit.

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

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

Adds behavioral info beyond annotations: pagination, ordering, filtering, and return structure. Annotations only indicate read-only; description expands on capabilities. No contradictions.

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?

Two sentences, front-loaded with purpose and key features. No unnecessary words; every sentence adds value.

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?

For a complex tool with 12 parameters, no output schema, and many enum fields, the description is minimal. It covers essential purpose but lacks details on pagination behavior, filter semantics, and ordering options. Adequate but with clear gaps.

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?

Only 8% schema description coverage; description mentions filtering by sellerId but does not explain most parameters (12 total, many with enums). Fails to compensate for low schema coverage.

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?

Clearly states it reads offer listings from Boson subgraph, with pagination, ordering, filtering, and return shape. Distinguishes from sibling tools that are write or other read operations (e.g., get_disputes, get_exchanges).

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?

Implies read-only usage but does not explicitly differentiate from other read-only get tools or provide 'when-not-to-use' guidance. Contextually clear that it's for reading offers, but lacks explicit alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the description's value lies in adding that no authentication is required and specifying the output content (agents, protocol entities, roles). This provides useful context beyond the annotations.

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 consists of two concise sentences front-loaded with the core purpose, followed by a key permission note. Every word contributes meaning without redundancy or extraneous detail.

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?

For a read-only tool with one parameter and no output schema, the description adequately explains what is returned (all dACP agents with protocol entities and roles) and notes permission. However, it lacks detail about the response structure (e.g., list vs. object) or any pagination/limits, which would enhance completeness.

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?

Schema coverage is 100% and the input schema already contains a detailed description of the configId parameter. The tool description does not add any additional parameter-level information, 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.

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

The description clearly states the verb 'Returns' and the specific resource 'dACP agents registered with this MCP server instance', including what is returned (associated protocol entities and roles). This sufficiently differentiates it from sibling tools like register_agent or get_sellers.

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?

No explicit guidance on when to use this tool versus alternatives. Sibling tools include register_agent, get_dispute_resolvers, etc., but no comparison or exclusion criteria are provided. The only usage hint is 'No auth required', which is a permission note, not a conditional usage guideline.

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

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

Annotations already indicate readOnlyHint=true. The description adds value by stating 'Read-only', specifying optional includes (offers, exchanges, funds, logs), and explicitly describing the return format as an array of seller entities with addresses and metadataUri. This provides behavioral context beyond the annotations.

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 three sentences, front-loaded with the main purpose, followed by optional features and return format. Every sentence adds essential information without redundancy or filler. It is extremely concise and efficient.

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 has 10 parameters and no output schema, the description covers the core purpose, return type, and optional includes, but lacks details on pagination, filtering, and ordering. The required configId parameter is well-documented in the schema, but the description does not mention it. For a complex tool, the description is adequate but not fully complete.

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?

Schema description coverage is only 10% (only configId is detailed). The description mentions the boolean include parameters (offers, exchanges, funds, logs) but does not explain pagination parameters (sellersSkip, sellersFirst) or filtering/ordering (sellersFilter, sellersOrderBy, sellersOrderDirection). It partially compensates for low schema coverage but leaves many parameters undocumented.

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 it reads seller account entities from the Boson subgraph, which is specific and action-oriented. It mentions optional includes of related data, but does not explicitly differentiate from the sibling tool 'get_sellers_by_address', which likely filters by address. Overall, the purpose is clear but could be more distinctive.

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?

No guidance is provided on when to use this tool versus alternatives like 'get_sellers_by_address'. The description only states it is read-only, but does not explain the use case or prerequisites. There is no explicit when-not or comparison with siblings.

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

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

Annotations already declare readOnlyHint=true, so description's 'Read-only' adds little. Returns type mentioned but no behavior details beyond that.

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?

Three sentences, no filler. Purpose first, then usage guidance, then safe/return info. Highly efficient.

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?

With 11 parameters and no output schema, description is too brief. Lacks explanation of pagination, filtering, ordering, and return structure. Agents would struggle to use optional parameters correctly.

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?

Only 9% of schema parameters have descriptions. Description does not explain any of the 11 parameters, including required ones like 'address' (only implied as Ethereum address) and 'configId' (already described in schema). No additional semantic help.

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?

Clearly states it reads seller entities by Ethereum address, explicitly distinguishing from create_seller sibling. Verb 'Reads' and resource 'seller entities' are specific.

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?

Provides explicit use case: check if signerAddress has an account before creating a seller. No alternatives mentioned but context is clear given sibling tools.

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

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

Annotations already declare readOnlyHint=true. The description adds value by specifying the return format (array of {address, name, symbol, decimals}) and the context of accepted exchange tokens, which is beyond the annotation.

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?

Three short sentences: purpose, usage guidance, and return format. No superfluous words, front-loaded with the key action.

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?

With one parameter and no output schema, the description fully covers: what is returned (ERC-20 tokens), structure (array of objects with fields), and how to use the result. No gaps.

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?

Schema coverage is 100% for configId with a detailed description. The tool description only reinforces 'on the given configId deployment' without adding new meaning, so baseline 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 verb 'Returns' and the resource 'ERC-20 tokens accepted as exchange tokens', with context of the deployment. It is specific and distinct from sibling tools like create_offer or approve_exchange_token.

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?

Explicitly tells when to use the output: 'Use returned addresses in exchangeTokenAddress fields of create_offer.' It also states 'Read-only' to imply safe usage, but lacks when-not-to-use or alternatives.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, aligning with raising a dispute. The description adds critical behavioral details: the caller restriction, time limit, and that it returns unsigned transaction data. No contradictions.

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?

Three concise sentences that front-load the core action, then add essential conditions. No superfluous text.

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 has 4 parameters and no output schema, the description covers the key behavioral context (caller, timeframe, return type). It does not explain failure modes but is adequate for an agent to understand invocation requirements.

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?

Schema coverage is 100% with detailed parameter descriptions. The description does not add additional parameter information beyond what the schema provides, so baseline 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 'Raises a dispute on a redeemed exchange' with a specific verb and resource. It distinguishes itself from sibling tools like 'resolve_dispute' and 'escalate_dispute' by focusing on the initial raising action.

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?

Explicitly states caller must be the buyer and must be called within a specified time frame. Provides clear context but does not explicitly list when not to use or alternatives, though the information is sufficient for correct usage.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false. Description adds context: returns unsigned transaction data, effect on dispute period. 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.

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

Three efficient sentences, front-loaded with purpose and key constraints. No unnecessary words.

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?

Adequately covers purpose, preconditions, and output. No output schema, but mentions return type. Could add more on how to handle the returned unsigned transaction.

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?

Schema coverage is 100% with good parameter descriptions. Description does not add further parameter-specific details, but baseline is 3 for high schema coverage.

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?

Description clearly states the action ('Redeems a voucher') and its purpose: signalling physical receipt and starting dispute period. This distinguishes it from sibling tools like cancel_voucher, revoke_voucher, etc.

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?

Specifies caller must be buyer and explains consequence (dispute period starts). Does not explicitly mention when not to use or list alternatives, but context is clear.

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

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

Annotations indicate destructiveHint=true. The description adds that the escalation fee is returned to the buyer and the dispute resets to 'Resolving' state, and that unsigned transaction data is returned. No contradictions.

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?

Two sentences, no redundant words, front-loaded with purpose and effects. Highly efficient.

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?

For a mutation tool with 3 parameters and no output schema, the description covers behavior and return value. However, it does not mention prerequisites (e.g., dispute must be in escalated state). Still largely complete.

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?

Schema coverage is 100% and the description adds meaningful context: exchangeId is obtained from get_exchanges, configId format is explained, signerAddress must match the signing wallet. This goes beyond the schema descriptions.

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 refuses an escalated dispute, returns the escalation fee, resets dispute state, and returns unsigned transaction data. It distinguishes from siblings like decide_dispute and resolve_dispute.

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 implies when to use (when you want to refuse an escalated dispute) but lacks explicit guidance on when not to use or alternatives. It could mention that decide_dispute is the complementary action.

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

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

Annotations set readOnlyHint=false and destructiveHint=false, consistent with a registration mutation. The description adds value by explaining that signatures prove control of signer addresses and that state is server-local. It also mentions the return is a confirmation, though it omits details on failure modes or idempotency.

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 highly concise with three short sentences. It front-loads the core purpose, adds a behavioral detail, and provides a return statement. No unnecessary words.

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 complexity (3 required params, no schema descriptions, no output schema), the description is insufficient. It lacks guidance on constructing signatures, interpreting return values, or handling errors. The 'registration confirmation' is vague. A more detailed description would improve agent understanding.

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?

With 0% schema description coverage, the description must compensate, but it only generically mentions 'Ethereum identities and roles' and 'signature'. It does not explain individual parameters like name, description, or the entities array structure beyond what the schema already shows. Critical details about signature format or entityId are missing.

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 uses a specific verb ('Registers') and resource ('dACP agent'), clearly distinguishing it from sibling tools like create_buyer and create_seller by specifying Ethereum identities and roles. It also notes server-local state and lack of required context, making the purpose unambiguous.

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

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

The description indicates when to use this tool by stating 'no configId/signerAddress context needed', implying it's a simple registration without prior setup. However, it does not explicitly contrast with create_buyer/create_seller or provide when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, so the description adds little beyond stating the function and return type. It says 'Renders... and returns rendered agreement string', but does not disclose potential performance or data size implications.

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?

Description is three sentences, front-loaded with purpose and usage. No superfluous text, but could be more structured (e.g., bullet points for return value or prerequisites).

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 complexity (nested objects, no output schema), the description is too sparse. It does not explain the format of the rendered agreement, error handling, or any constraints (e.g., timeouts, required field formats beyond what's in schema).

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?

Schema description coverage is 40% and the description does not explain any parameters. While schema has descriptions for configId and signerAddress, many nested properties are undocumented. The description offers no guidance on how to populate offerData or offerMetadata.

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?

Description clearly states it renders a contractual agreement from offer data and metadata, with specific verb 'renders' and resource 'legal contractual agreement'. Distinguishes from sibling tools which are mostly about modifying or querying exchanges, offers, and disputes.

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?

Description mentions 'Use to preview or store the agreement' which gives context, but does not specify when not to use it or alternative tools. No exclusions or conditions provided.

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

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

Annotations indicate destructiveHint=true, and the description adds context by explaining the multi-step workflow and that the tool returns unsigned transaction data, consistent with a write operation requiring further action.

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 with two sentences and a bullet-point workflow, front-loading the purpose and using no unnecessary words.

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?

With no output schema, the description notes 'Returns unsigned transaction data,' which is sufficient given sibling tools for sending transactions. The workflow context compensates for missing output details.

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?

Schema coverage is 100%, so the baseline is 3. The description adds workflow context but does not significantly enhance parameter understanding beyond the schema definitions.

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 action 'Resolves a dispute by mutual agreement' and outlines a specific workflow, distinguishing it from sibling tools like 'decide_dispute' or 'escalate_dispute'.

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 explicitly lists prerequisite steps (create_dispute_resolution_proposal, local signing) and specifies who can submit (either party). It does not directly mention when not to use, but the workflow implies conditions for usage.

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

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

Annotations indicate destructiveHint=true, so description does not need to redundantly state destructiveness. The description adds value by explaining what happens (deposit released, completion flow restored) and the return type (unsigned transaction data). No contradiction with annotations.

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

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

Two sentences, no wasted words. The first sentence states the core action and effect; the second adds caller constraint and return type. Information is front-loaded and easy to parse.

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?

With 4 parameters (3 required, 1 has enum), destructive hint, and no output schema, the description adequately covers the tool's purpose, effect, and caller restriction. It does not detail the unsigned transaction data handling, but that is likely covered by sibling tools. Minor gap, but overall sufficient for an agent to use correctly.

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

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

Schema description coverage is 100%, with each parameter already well-documented (e.g., configId format, exchangeId numeric, signerAddress requirement). The tool description does not add parameter-specific details beyond the schema, which is acceptable given the exhaustive schema documentation.

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 action ('retracts'), the resource ('a raised dispute'), the effect ('releasing seller deposit and restoring completion flow'), and the caller restriction ('buyer who raised it'). It distinguishes itself from sibling tools like 'raise_dispute' and 'escalate_dispute'.

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 explicitly states the prerequisite that the caller must be the buyer who raised the dispute. It implies when to use (only if you are that buyer) but does not explicitly mention alternatives or when not to use. However, the context among siblings provides sufficient differentiation.

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

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

Annotations already indicate destructiveHint=true. The description adds that the tool returns unsigned transaction data and returns funds to the buyer, which provides additional behavioral context beyond the annotations.

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?

Two concise sentences that front-load the action and effect, then add caller requirement and return type. No extraneous words; every sentence adds value.

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?

Despite no output schema, the description states the return type (unsigned transaction data) and effect (return funds). For a 4-parameter tool with 100% schema coverage, this is adequate but could hint at next steps like signing the transaction.

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 covers all parameters with descriptions (100% coverage). The tool description does not add new meaning to the parameters beyond what is in the schema, so baseline score applies.

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 action (revoke), resource (voucher), and context (committed but not redeemed, seller behalf, returns funds). However, it does not differentiate from the sibling 'cancel_voucher' tool, leaving some ambiguity.

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 specifies that the caller must be the seller assistant, which is a useful condition. However, it does not provide guidance on when to use this tool versus alternatives like cancel_voucher or redeem_voucher, nor does it mention any prerequisites.

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

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

Annotations already declare `readOnlyHint: true`. The description adds context by stating the tool is read-only, explaining the `includeInvalidOffers` flag and its default (false). It also notes the return type (array of product search result fragments). No contradictions.

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?

Two efficient sentences with essential information front-loaded. No wasted words. The structure is clear and easy to parse.

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?

With 8 parameters, nested objects, and no output schema, the description covers main purpose and a key flag but omits details like the structure of productsFilter and possible ordering fields. For a complex tool, more completeness would be beneficial.

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?

Schema description coverage is only 38%, so the description should compensate. It explains keywords, includeInvalidOffers, and gives a format example for configId. However, it does not describe the complex productsFilter object or the details of enum values for ordering. The description adds partial value but not enough to fully compensate for the low schema coverage.

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 it searches products by keywords against multiple fields (title, description, brand, category, tags). It specifies pagination, ordering, filtering, and the includeInvalidOffers flag. This distinguishes it from sibling mutation tools, though a sibling 'get_all_products_with_not_voided_variants' exists but has a different scope.

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 mentions 'Read-only' and defaults for includeInvalidOffers, but does not provide explicit guidance on when to use this tool versus alternatives like 'get_all_products_with_not_voided_variants'. No exclusion criteria or use-case examples are given.

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

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

Annotations already indicate destructiveHint=true, and description adds that it returns relay transaction data, confirming it is a write operation. No contradiction, but limited additional 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.

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

Two efficient sentences with no redundancy, directly stating action and requirement.

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?

Covers the main action and return type, but given the complexity of nested parameters and lack of output schema, more context about the relay process and prerequisites would be beneficial. Adequate but not fully comprehensive.

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?

Schema coverage is only 50%, and the description only mentions two key parameters (request and domainSeparator) without detailing the other four. Does not compensate for the schema's lack of description for all properties.

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?

Clearly states it relays a Biconomy forwarded meta-transaction for ERC-20 gas payment, distinguishing from sibling tools like send_meta_transaction and send_native_meta_transaction.

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?

Only implicitly says it requires a complete request and signature, but does not specify when to choose this over other meta-transaction tools or provide exclusion criteria. Basic context without explicit guidance.

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

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

Annotations already indicate destructiveHint=true. The description adds that it requires a pre-signed payload and returns relay transaction data. It does not elaborate on failure modes or gas implications, but it provides useful context beyond annotations without contradiction.

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 three sentences, each adding value: the core action, the requirement, and the usage condition. No redundant words, good front-loading.

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 complexity (8 required parameters, no output schema), the description provides a high-level understanding but omits details on parameters like functionName, nonce, and configId. It explains the process in general terms but leaves gaps that an agent would need to infer from the schema.

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?

Schema coverage is only 25% (2 of 8 parameters have descriptions). The description only mentions sigR, sigS, sigV, ignoring five other required parameters (functionName, functionSignature, nonce, configId, signerAddress). Since coverage is low, the description should compensate but fails to explain the purpose or format of those parameters.

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 relays a pre-signed meta-transaction via Biconomy to save gas. It specifies the required signature components and when to use it. However, it does not explicitly differentiate from sibling tools like send_forwarded_meta_transaction, though the mention of Biconomy provides some distinction.

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 includes a usage guideline: 'Use when the target operation requires metaTx relay.' It also implies that the user must have locally signed an EIP-712 payload. However, it does not specify when not to use the tool or mention alternatives.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it returns relay transaction data, which is helpful, but does not elaborate on failure modes, fees, or confirmation details.

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?

Two sentences with no fluff; every word adds value. Well-structured and front-loaded.

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 7 required params, destructive nature, and no output schema, the description is too minimal. It lacks details on return format, side effects, prerequisites, and parameter dependencies.

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?

Schema description coverage is only 43% (3 of 7 params described). The description repeats parameter names but does not add meaning beyond the schema, failing to compensate for low coverage.

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 it relays a native meta-transaction via Biconomy, specifying verb and resource. However, it does not differentiate from sibling tools like send_forwarded_meta_transaction or send_meta_transaction, leaving some ambiguity.

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 implies use when you have a locally-signed EIP-712 payload and provides required components, but lacks explicit guidance on when not to use or alternatives among siblings.

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

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

Annotations already indicate destructive hint; description adds return values (hash, block number, gas used). Could mention prerequisites like gas balance.

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?

Three concise sentences covering purpose, constraint, and return; no redundant information.

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?

Covers purpose, parameter details, and return; missing error scenarios or prerequisites like sufficient gas, but adequate for basic usage.

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?

Both parameters are described with additional context: signedTransaction includes origin example, configId includes format and reference to get_config_ids.

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 explicitly states the verb 'Broadcasts' and the resource 'signed raw Ethereum transaction', distinguishing it from sibling meta-transaction tools.

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?

Provides clear format requirement and example for signedTransaction, but does not explicitly compare to sibling transaction tools or state when not to use.

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

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

The description adds significant behavioral context beyond the readOnlyHint annotation: it clarifies that the tool generates typed data that must be signed by the offer creator, and that this is an offline signing step. This is valuable information for an agent deciding how to process the output. There is no contradiction with annotations since readOnlyHint=true aligns with generating data without any on-chain write.

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 extremely concise with two well-structured sentences. The first sentence states the action and result; the second provides workflow context and output handling. Every word adds value, fitting the requirement of being front-loaded and efficient.

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 complexity (32 parameters, nested objects), the schema does the heavy lifting. The description completes the picture by explaining the tool's role in a multi-step process and the nature of the output. It is complete enough for an agent to understand the tool's purpose and how to proceed after calling it. A higher score would require more detail about edge cases or error states, but the current level is sufficient.

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 has 94% description coverage, so the schema already documents most parameters comprehensively. The tool description does not add new parameter-level information; it only mentions the high-level purpose and return value. Baseline of 3 is appropriate since the schema carries the weight, and the description provides no extra parameter guidance.

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 that the tool generates EIP-712 typed data for a non-listed offer and that it is a prerequisite step. The verb 'Generates' combined with the specific resource 'non-listed (private) offer' makes the purpose unambiguous. It also distinguishes itself from sibling tools by specifying the workflow sequence, calling out create_offer_and_commit and void_non_listed_offer explicitly.

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 explicitly tells when to call this tool: 'Call before create_offer_and_commit or void_non_listed_offer.' It also explains what to do with the output: sign it locally and use the signature in the next step. While it does not cover when not to use it or list alternatives, the workflow context is clear and sufficient for an agent to decide when to invoke it.

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

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

The description fully discloses the tool's behavior: it generates typed data for local signing, does not submit any transaction, and returns a data structure. This aligns with the readOnlyHint annotation and adds context about the meta-tx flow and default spender. There is no contradiction between description and annotations.

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 three sentences, front-loading the core action and purpose. It avoids redundancy and fluff, with each sentence providing essential information.

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 rich schema and readOnly annotation, the description is largely complete: it describes the output type, usage context, and default behavior. However, it lacks guidance on how to obtain the tokenDomainName and does not mention any edge cases or prerequisites, which would improve completeness for a signing tool.

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?

With 100% schema description coverage, the schema already documents all 7 parameters. The description adds value by explaining the default for 'spender' (protocol diamond) and the role of the output in meta-tx flows. However, it does not elaborate on 'tokenDomainName' beyond the schema's example.

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?