agentic-commerce

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

Annotations already indicate this is a mutation (readOnlyHint=false) and potentially destructive (destructiveHint=true). The description adds that it 'returns unsigned transaction data', which is key behavioral info not in 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. Each sentence provides essential information: purpose, prerequisite, and return 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?

Covers purpose, prerequisite, and return type. However, it could mention that the returned unsigned transaction must be sent via send_signed_transaction or send_meta_transaction depending on executionMode, and that the allowance is for the Boson Protocol diamond. Minor gap.

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 5 parameters with detailed descriptions (100% coverage). The description does not add extra parameter-level info; it remains at the tool level. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: granting ERC-20 allowance to the Boson Protocol contract. It distinguishes itself from siblings by specifying it is a prerequisite for commit_to_offer and deposit_funds when using non-native exchange tokens.

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: must be called before commit_to_offer or deposit_funds when using non-native exchange tokens. Provides clear context without 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?

Description adds value beyond annotations by stating the tool returns unsigned transaction data, indicating it does not submit the transaction directly. It also details the cancellation effect (penalty forfeiture, refund). Annotations already mark it as destructive; description supplements with specific behavioral traits.

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

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

Description is three sentences with no redundancy. It front-loads the primary action and immediately follows with prerequisites and effects. Every sentence 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?

For a mutation tool with no output schema, the description adequately covers prerequisites, effects, and return value. It could mention potential errors or further side effects, but given the schema and annotations, 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 100%, with each parameter well-described in the schema. The description does not add new parameter-level details. Baseline score of 3 is appropriate as the schema already carries the burden.

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 cancels a committed voucher, with specific verb-resource pair. It distinguishes from siblings like revoke_voucher by specifying caller must be the buyer, which is a unique constraint. The action is unambiguous and well-scoped.

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 clear conditions: caller must be the buyer, and explains the financial consequences (forfeit penalty, remainder refunded). It does not explicitly compare with alternative tools like revoke_voucher or void_offer, but the context is sufficient for an agent to determine 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 already declare destructiveHint=true. The description adds that the tool returns unsigned transaction data (not directly executing) and mentions the collateral prerequisite, providing 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?

The description is three concise sentences, front-loaded with the main action. Every sentence adds value: purpose, caller requirement, prerequisite, and return type. No fluff.

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 is adequate but incomplete given the 7-parameter complexity and no output schema. It mentions 'unsigned transaction data' but does not describe the structure of the response. It also fails to explain the prerequisite 'matching collateral' in detail.

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 71% schema description coverage, the schema already documents most parameters. The tool description adds no additional parameter meaning; it does not elaborate on any of the 7 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 verb 'Fulfils', the resource 'buyer-initiated offer', and specifies the actor 'by the seller'. It distinguishes from siblings like 'commit_to_offer' by focusing on buyer-initiated offers (creator='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?

The description provides explicit usage conditions: caller must be the seller and must provide matching collateral. It does not explicitly compare with alternative commit tools, but the buyer-initiated 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?

The description adds context beyond annotations: it states the caller must hold the gating token (authorization requirement) and that it returns unsigned transaction data. Since annotations already declare destructiveHint=true and readOnlyHint=false, the description aligns and adds useful behavioral details 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 extremely concise: two sentences with no extraneous words. It front-loads the action, immediately gives usage guidance, and mentions the return type. 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 lack of output schema, the description mentions 'Returns unsigned transaction data', which is crucial. It covers prerequisites and usage. With 6 parameters all detailed in the schema, and a conditional nature, the description is nearly complete, though it could note potential errors or edge cases.

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 does not add significant meaning beyond what the schema already provides for each parameter. It restates the gating condition but does not elaborate on parameter usage or constraints 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 verb 'Commits' and the specific resource 'token-gated (conditional) offer using a specific gating tokenId'. It distinguishes from siblings by explicitly saying 'Use this instead of commit_to_offer for offers created via create_offer_with_condition'. The purpose is unambiguous and well-defined.

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 explicit guidance: 'Use this instead of commit_to_offer for offers created via create_offer_with_condition'. It implies when not to use (for non-conditional offers) and states a prerequisite (caller must hold the gating token). However, it does not mention other sibling tools like commit_to_conditional_offer_and_redeem_voucher, which could be 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, so the description's mention of 'commits' and 'redeems' is consistent and adds no contradiction. However, it adds value by stating the tool returns 'unsigned transaction data', which is not in annotations. It does not detail side effects or permissions beyond the gating token, but the key behavioral aspects are covered.

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 just two sentences, front-loaded with the key action ('Atomically commits...'), immediately followed by a prerequisite and output. Every sentence is essential, with no filler. It is highly efficient 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 complex tool with 5 parameters, no output schema, and many siblings, the description is brief but covers the core action, prerequisite, and return type. However, it lacks details on what 'commit' entails, the nature of 'unsigned transaction data' (raw hex?), and potential failure modes. Given the tool's atomic and destructive nature, more context would help the agent anticipate outcomes.

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 baseline is 3. The description adds little beyond the schema: it mentions 'using a specific gating tokenId' which ties to the tokenId parameter, but does not explain executionMode or signerAddress beyond what the schema provides. No additional parameter context is given, so the description meets the baseline without improvement.

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 commits to a token-gated offer and redeems the voucher in a single transaction. 'Commit' and 'redeem' are specific actions, and 'token-gated' and 'conditional offer' differentiate it from similar tools like 'commit_to_offer_and_redeem_voucher' (non-conditional) and 'commit_to_conditional_offer' (commit only). The purpose is well-defined and distinct from siblings.

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 prerequisite ('Buyer must hold the gating token') and mentions atomic execution, but does not give explicit guidance on when to use this tool versus alternatives like 'commit_to_conditional_offer' (if only commit is needed) or 'redeem_voucher' (if already committed). Given the large sibling set, more explicit when-to-use and when-not-to-use instructions would improve usability.

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 the tool as destructive (destructiveHint=true) and not read-only (readOnlyHint=false). The description adds value by detailing the actual outcomes (creating exchange, minting voucher) and specifying that the return is unsigned transaction data. 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?

Two sentences: the first states the core action and result, the second adds crucial usage conditions and return type. No filler words. Every sentence carries meaningful guidance, making it efficient 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 the lack of an output schema, the description adequately explains that unsigned transaction data is returned. It also covers a key prerequisite (approve_exchange_token). However, it does not mention the executionMode parameter, though the schema covers it. Overall, it provides sufficient context for a mutation tool with well-documented 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 all parameters are documented. The description adds semantic value by explaining the side effects of the 'buyer' parameter (overrides signerAddress) and prescribing the prerequisite action for ERC-20 tokens. This enriches understanding beyond the schema alone.

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 ('Commits to'), names the resource ('offer'), and specifies outcomes ('creating an exchange and minting a voucher NFT'). It distinguishes from siblings like commit_to_conditional_offer by mentioning the optional 'buyer' parameter and the prerequisite for ERC-20 offers. This clearly communicates the tool's net effect.

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 is the buyer unless 'buyer' is set, and for ERC-20 offers, approve_exchange_token must be called first. However, it does not explicitly exclude use when alternatives like commit_to_buyer_offer or commit_to_conditional_offer might be more appropriate. Thus it lacks explicit when-not guidance or sibling comparisons.

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 atomic behavior, immediate redemption, skipped transferability, immediate dispute clock start, and return of unsigned transaction data. Adds value beyond annotations which only indicate destructive nature.

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: purpose, prerequisites/consequences, return type. Concise and front-loaded 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?

Covers purpose, mechanism, prerequisites, behavioral impact, and return type. Lacks explicit error handling or next steps, but sufficient for a 4-param tool with 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%, so baseline 3. Description adds overall context but does not significantly enhance individual parameter meaning 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?

Clearly states it atomically commits to an offer and redeems voucher in a single transaction, using 'OrchestrationHandler'. Distinguishes from siblings that do these steps separately or conditionally.

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?

Mentions prerequisite (ERC-20 allowance) and behavioral consequences (skips transferability, starts dispute clock). Implies atomic nature but lacks explicit contrast with alternatives like commit_to_offer + redeem_voucher.

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 confirm destructiveHint=true, and the description adds valuable behavioral context: it releases funds, can be called by different roles, and 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?

Two sentences with no filler, front-loaded with the core purpose, structured efficiently to convey key 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?

The description covers purpose, caller roles, and return type. It lacks details on prerequisites or error states, but given the tool's specialization and good annotations, it is nearly 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% with detailed parameter descriptions. The tool description adds no extra semantic value beyond what the schema provides, justifying the baseline score 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 'completes an exchange' and the resource 'exchange', with specific conditions (after dispute period, releasing funds). It distinguishes from sibling dispute-related tools by specifying timing and caller roles.

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: seller after dispute period, buyer anytime post-redemption. It does not explicitly list alternatives or when not to use, but the conditional hints are sufficient for basic 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 indicate destructiveHint=true and readOnlyHint=false, implying a write operation. The description adds 'Returns unsigned transaction data,' which is a key behavioral trait—this tool does not execute the transaction but returns data for signing. However, it does not elaborate on the destructiveness (e.g., whether account creation is irreversible) beyond what annotations imply.

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 convey purpose, prerequisite context, and return type. Every sentence adds value without redundancy or wordiness.

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 fully covers the essential aspects: purpose, when to use, prerequisites, and what it returns ('unsigned transaction data'). No gaps remain for an agent to misunderstand.

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 have 100% schema description coverage with detailed explanations (e.g., configId format, signerAddress requirement). The tool description reiterates the signerAddress's role ('for signerAddress') but adds no new meaning beyond the schema. 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 ('Creates a buyer account') and the specific actor ('signerAddress'). It distinguishes this tool from siblings like 'create_seller' and 'commit_to_buyer_offer' by explaining its prerequisite role: 'Required before a buyer can commit to seller-initiated offers for the first time.'

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 when to use this tool ('before a buyer can commit to seller-initiated offers for the first time') and notes there are 'No prerequisites.' It does not explicitly state when not to use it or compare to alternatives, but the context is clear enough for an agent to decide.

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, indicating a read-only operation. The description adds behavioral context: the tool generates data to be signed, and both parties must sign before resolve_dispute. 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 wasted words. Front-loaded with action and returns. 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?

Describes output as typed data structure, mentions signing requirement. Lacks explicit instructions on how to use the returned data (e.g., calling eth_signTypedData_v4), but sufficient for the tool's purpose.

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 process context (e.g., buyerPercentBasisPoints must be signed by counterparty) but does not significantly add beyond schema. 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?

Clearly states the tool generates EIP-712 typed data for a mutual dispute resolution proposal. Mentions prerequisite of both parties signing the same value. Does not explicitly differentiate from siblings like 'resolve_dispute' or 'decide_dispute', but purpose is clear.

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 instructs that both buyer and seller must sign the same buyerPercentBasisPoints value before calling resolve_dispute. Provides clear context but does not mention 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?

Annotations indicate destructive=true and readOnly=false. The description adds that the tool returns an unsigned transaction and describes two execution modes (direct/metaTx), which are important behavioral details not covered by 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 four sentences, front-loaded with the action and resource, and every sentence adds value (prerequisites, formats, output handling). 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 no output schema, the description clearly explains the return value (unsigned tx) and how to proceed, which is sufficient for a complex tool with 25 parameters. Prerequisites and format details are covered, making it complete for the 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 96%, so the description adds minimal parameter-level detail. It mentions date and amount formats (dates in ms, amounts as strings in wei) but most parameters are well-documented in the schema. 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 'Creates a product offer', identifying the verb and resource. It also distinguishes from siblings like create_offer_and_commit by noting that this tool returns an unsigned transaction for local signing, implying that other tools handle commitment automatically. However, it does not explicitly name alternatives, so it gets a 4.

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 prerequisites (seller account, metadata storage) and explains when to use this tool versus alternatives (e.g., for local signing vs metaTx). It does not explicitly list exclusions, but the context is clear enough for an agent to decide.

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 (mutation) and readOnlyHint: false. The description adds atomicity, return type (unsigned transaction data), and the requirement for a signed signature, which provides some behavioral insight beyond annotations. It does not detail failure modes or the need for subsequent signing/sending, but the added value is moderate.

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 purpose and then providing the prerequisite and return type. Every sentence adds value, with no unnecessary words or redundancies.

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, no output schema), the description is relatively brief. It covers the atomic nature, prerequisite, and return type, but it omits guidance on what to do with the unsigned transaction data (e.g., call send_signed_transaction or send_meta_transaction based on executionMode) and does not explain the overall workflow beyond the prerequisite.

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%, so the schema already documents most parameters. The description adds context for the 'signature' parameter by linking it to the prerequisite workflow, but otherwise repeats no parameter details. This meets the baseline expectation for high-coverage schemas.

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 in one transaction, explicitly mentioning private/bilateral trades. It distinguishes from siblings by specifying the atomic combo and prerequisite, which is unique among related tools like 'commit_to_offer' or 'create_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 a clear usage context ('private/bilateral trades') and a prerequisite ('call sign_full_offer...'), helping the agent understand when to use it. However, it does not explicitly contrast with alternatives (e.g., using 'create_offer' then 'commit_to_offer' separately) or state 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?

Annotations already indicate destructiveHint=true, so the agent knows it's a write operation. The description adds that the operation is atomic, performed via OrchestrationHandler, and returns unsigned transaction data (implying a subsequent signing step). This context is useful but does not elaborate on potential side effects (e.g., fund requirements, reverting conditions).

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 that efficiently convey the core action, prerequisites, use case, and return type. It front-loads the atomic nature and avoids extraneous details, earning a perfect score.

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, no output schema), the description is brief and covers the essential purpose. However, it does not explain how to handle the returned unsigned transaction data or that this tool replaces separate create/commit/redeem calls. For such a complex tool, the description 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?

Schema description coverage is 94%, so the input schema already documents most parameters thoroughly. The description does not add further parameter-level details beyond referencing prerequisites. The baseline of 3 is appropriate.

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

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

The description clearly states the tool atomically creates a private offer, commits a buyer, and redeems the voucher. It names the OrchestrationHandler and distinguishes from create_offer_and_commit by noting the same prerequisites and the additional redemption step. However, it does not explicitly differentiate from other commit+redeem sibling tools like 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 specifies 'Use for instant-fulfilment private trades' and mentions prerequisites (sign_full_offer + EIP-712 signature). It provides a clear use case but lacks explicit guidance on when not to use this tool versus alternatives (e.g., when delayed redemption is acceptable, use create_offer_and_commit instead).

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 label the tool as destructive (destructiveHint=true). The description adds that it returns unsigned transaction data, which is useful for workflow understanding. However, it does not disclose permissions, reversibility, or other behavioral traits beyond the annotation baseline.

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, efficient and front-loaded. Every sentence adds value: purpose, prerequisites, and return type. No unnecessary repetition.

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 (26 params, nested objects, no output schema), the description gives a clear overview and links to prerequisites. Schema covers details. Missing error conditions or examples, but adequate for the complexity level.

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 high (92%), so the schema already documents most parameters. The description provides a high-level summary for the condition parameter but adds little value beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'creates', the resource 'offer gated by token-ownership', and distinguishes from the sibling 'create_offer' by explicitly mentioning the additional 'condition object'. It also specifies the return type (unsigned transaction 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 indicates that this tool shares prerequisites with 'create_offer' and requires a condition object, which implies usage for token-gated offers. It differentiates from the sibling tool but does not provide explicit when-not-to-use or alternative tool names.

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 destructiveHint=true; description adds that it returns unsigned transaction data and sets roles automatically. This goes beyond annotations. Missing details on idempotency or error 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?

Three concise sentences, front-loaded with the main action, 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?

Covers essential usage context (required before offers, return type) but lacks details on output format, error conditions, and parameter relationships. For a complex 18-param tool with no output schema, 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 coverage is only 39%, but the description only mentions 'seller metadata' and 'royaltyPercentage' without explaining the 9 required parameters like authTokenId, configId, or contactPreference. Does not compensate adequately 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 the verb ('Creates'), the resource ('seller account on Boson Protocol'), and provides context ('Required before creating any offers'). It also mentions automatic role assignment and return type, distinguishing it from siblings like create_buyer and update_seller.

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 says 'Required before creating any offers,' giving clear when-to-use guidance. Also notes automatic role assignment. However, it lacks explicit when-not-to-use or alternatives (e.g., update_seller), given many 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 indicate destructiveHint=true, which the description supports with 'Decides'. It adds valuable context: caller role and return of 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?

Three sentences, front-loaded with purpose, then caller condition, then parameter detail, then output. No fluff, each 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 4 required params, no output schema, and destructive nature, the description covers purpose, caller, parameter meaning, and return. Missing details about error cases or authorization failure, but sufficient for basic 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?

Schema coverage is 100% with descriptions for all 4 parameters. The description adds minor extra context (basis points range for buyerPercent, format for configId) but does not significantly enhance understanding 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 'Decides an escalated dispute' with specific conditions (caller must be resolver) and return value (unsigned transaction data). This distinguishes it from sibling dispute tools like raise_dispute, escalate_dispute, expire_dispute, 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 explicitly states the caller must be the dispute resolver and explains the buyerPercent parameter meaning. It does not explicitly contrast with alternative dispute actions, but the resolver role provides clear usage context.

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 it returns unsigned transaction data (not submitting), destructive nature (deposit), and prerequisite for ERC-20. Annotations already indicate destructiveHint=true, but description adds useful context 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?

Two sentences, no filler. First sentence states core purpose, second adds critical prerequisite. Efficient 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?

Given 6 parameters, no output schema, and complexity of deposits, the description is adequate. It explains the main flow but could elaborate on entity concept or executionMode implications, though schema handles those 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 already covers all parameters with descriptions (100% coverage), so description adds minimal extra semantics. It reinforces the need to call approve_exchange_token but doesn't add new meaning beyond what's in 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 'deposits' and the resource 'ERC-20 or native tokens into an entity's protocol treasury'. Distinguishes from sibling tools like 'withdraw_funds' and 'approve_exchange_token' via prerequisite mention.

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 prerequisite 'call approve_exchange_token first' for ERC-20 and mentions returns unsigned transaction data. Could be improved by explicitly contrasting with withdraw_funds or specifying when to use execution modes.

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 write operation. Description adds context beyond annotations: explains role requirement, fee coverage, and return of 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?

Three short sentences, no fluff. Core action, conditions, and return value stated upfront. 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 4 params and no output schema, description provides role and fee prerequisites, and return type. Could include note about multi-step process (sign then send), but adequate for a focused escalation 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?

Schema coverage is 100%, so parameters are well-documented in input schema. Description adds only vague context (e.g., exchangeId likely is dispute ID). Return type mentioned but not a parameter. Baseline of 3 warranted.

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 ('Escalates a stale dispute'), specifies caller role, fee condition, and return type. Verb 'escalates' and resource 'dispute' are precise, and it distinguishes from siblings like raise_dispute or decide_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?

States explicit prerequisites: caller must be buyer, resolver's fee must be covered. Implicitly guides when to use (stale disputes needing third-party). Could explicitly mention alternatives (e.g., 'Use raise_dispute for non-stale disputes').

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 the tool is permissionless and returns unsigned transaction data, giving useful behavioral context. 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?

Three sentences, no filler. Every sentence provides essential information: action, permission, condition, output. 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?

Given no output schema, the description explains the tool's purpose, prerequisites, and return type (unsigned transaction). It could detail the return format more, but overall it is sufficiently complete for a simple state-transition 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?

Schema coverage is 100%, so baseline is 3. The description does not add parameter-level meaning beyond what is in the schema; the conditions mentioned ('Disputed' state, timeout) are context for the exchangeId parameter but not detailed.

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 (marks a dispute as expired), the resource (dispute), and the conditions (resolution period passed, 'Disputed' state past timeout). It distinguishes from sibling tools like expire_dispute_batch and expire_escalated_dispute through specificity.

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 tool is permissionless and requires the exchange to be in 'Disputed' state past its timeout, providing clear when-to-use guidance. However, it does not explicitly state when not to use it or compare with alternatives like escalate_dispute.

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 (destructive=true), the description adds preconditions (exchanges must be in 'Disputed' state past timeouts), permissionless access, and return type (unsigned transaction data). This provides useful behavioral context beyond what annotations alone 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 concise sentences with no filler. The first sentence immediately states the action and scope, making it efficient 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 no output schema, the description mentions the return type (unsigned tx data). Preconditions are stated. Could include error scenarios or batch behavior, but overall sufficient for a clear 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?

Schema coverage is 100%, so baseline is 3. The description does not add significant new meaning beyond the schema; it restates the precondition for exchangeIds but no additional parameter details.

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 ('Marks') and resource ('expired disputes') and clearly indicates this is a batch operation. It distinguishes from sibling tools like expire_dispute (single) and expire_escalated_dispute by specifying batch and transaction context.

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 multiple disputes but does not explicitly contrast with expire_dispute or when-not-to-use. It states 'Permissionless' but lacks guidance on trade-offs between batch and single calls.

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; the description adds that it returns unsigned transaction data and is permissionless, providing useful context 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?

The description is two sentences with no waste, front-loaded with the main action and condition.

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 schema, annotations, and no output schema, the description fully covers the tool's purpose, behavior, and return type.

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 baseline is 3; the description does not add further meaning to the parameters beyond what is already in 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 expires an escalated dispute when the resolver's response period passes without a decision, distinguishing it from sibling tools like 'expire_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 specifies the condition for use (response period passed) and that it's permissionless, but does not explicitly list when not to use it or mention alternative dispute 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 indicate destructiveHint=true, and description adds vital behavioral context: returns unsigned transaction data (not executed directly), requires Resolving state, and is callable by either party. This goes beyond annotations, though permissions or side effects are not fully detailed.

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 adding value. Front-loaded with action, then state requirement, then caller permission, then 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?

Covers state prerequisite, caller roles, and return type (unsigned tx). Lacks error handling details (e.g., what happens if dispute not in Resolving state). Siblings provide adjacent tools for signing/sending, so overall context is 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?

All 5 parameters have schema descriptions (100% coverage), so parameter semantics are well-covered. Description adds state constraint but does not significantly enhance parameter understanding beyond 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?

Description clearly states verb+resource: 'Extends the deadline of an active dispute.' Specifies required state ('Dispute must be in 'Resolving' state') and explicitly distinguishes from siblings like escalate_dispute and expire_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?

Description provides context (dispute must be in Resolving state, either party can call) but does not explicitly discuss when not to use this tool or compare to alternatives like escalate_dispute or expire_dispute. No exclusion 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 read-only, and the description adds behavioral details like pagination and ordering support, as well as the data source (Boson subgraph). 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 three efficient sentences, front-loading the purpose. The mention of 'Read-only' is redundant with annotations but not harmful.

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 explanation of output structure or return value since no output schema. For a tool with six parameters and no output schema, more detail on what the tool returns 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 only 17%, and the description only broadly mentions 'Supports pagination and ordering' without explaining the specific parameters (e.g., productsFilter, productsOrderBy enum values). Minimal added value for 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 specifies a clear verb ('Reads') and resource ('product groupings with at least one non-voided variant from the Boson subgraph'), distinguishing it from sibling tools like 'search_products'. The title 'Get Products (Active Variants)' reinforces this.

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 notes 'Useful for storefront displays', giving clear context. However, it does not explicitly mention when not to use or mention alternative tools like search_products for broad searches.

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 declare readOnlyHint=true, and the description adds that no auth is required, which is useful beyond the structured data. It also states what it returns (valid configId values), making behavior transparent.

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 concise sentences with no extraneous information. It is front-loaded with the core purpose and immediately gives usage context.

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 simplicity of the tool (no parameters, no output schema) and the rich annotations, the description is complete. It explains what it returns and when to use it, which is adequate for an agent to invoke 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?

The tool has zero parameters, and schema coverage is 100%. According to the guidelines, 0 params yields a baseline of 4. No additional parameter description is needed.

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 returns all valid configId values and that it should be called first to discover which network/deployment to use. This distinguishes it from sibling tools which are mostly transactional.

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 for when to use this tool. It does not list alternatives or when not to use it, but for a discovery tool this is sufficient.

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 value beyond readOnlyHint by describing the returned entity (state, timeout, buyerPercent) and noting disputeId equals exchangeId. 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?

Two sentences, no wasted words, front-loaded with action and key 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?

Sufficiently complete for a read-only retrieval tool with good annotations; mentions return fields and usage hint. Could add non-existence behavior but not required.

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%, baseline 3. Description adds meaning by clarifying disputeId equals exchangeId, slightly exceeding 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?

Clearly states it reads a single dispute by ID, specifies that ID equals exchangeId, and distinguishes from 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?

Explicitly instructs to use get_disputes to search first, providing clear context on when to use this tool versus its sibling.

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; description reinforces 'Read-only' and details the return structure (array with ID, fees, etc.), adding value 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 efficient sentences, front-loaded with purpose and usage. 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?

Despite 6 parameters (including a nested filter object), no output schema, and complex sibling context, the description only covers return fields. Missing parameter guidance and behavioral details like pagination or ordering semantics.

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%) and description does not explain any parameters. It only describes output, leaving the meaning of skip, first, filter, orderBy, etc. entirely to 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 it reads registered dispute resolver entities and provides a specific use case (finding valid disputeResolverId for create_offer). However, it does not differentiate itself from many sibling tools that also read entities.

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 this tool: to find a valid disputeResolverId for create_offer. No guidance on when not to use or alternatives, but the 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 already declare readOnlyHint=true, and the description adds 'Read-only' and describes the return type with specific fields. No contradictions. However, it does not disclose additional behavioral traits like rate limits or data freshness.

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 concise sentences that front-load the purpose and key capabilities. Every sentence adds value, though including a brief sibling differentiation would improve structure.

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 presence of sibling tools for dispute management, the description does not explain that this tool lists multiple disputes (as opposed to get_dispute_by_id). It covers pagination and filtering but lacks details on configId requirement and output schema. 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?

With only 17% schema description coverage, the description adds high-level meaning (pagination, ordering, filtering by buyer/seller/state) but does not detail individual parameters like configId, disputesSkip, or the filter object structure. Provides some context but insufficient to fully compensate for the coverage gap.

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 'Reads dispute records from the Boson subgraph', which is a specific verb and resource. It distinguishes itself from sibling tools like get_dispute_by_id (single record) and mutation tools by indicating it is a read operation returning an array.

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 pagination, ordering, and filtering features but does not provide explicit guidance on when to use this tool versus alternatives like get_dispute_by_id or when to avoid it. The usage context is implied but not stated.

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 reinforces the readOnlyHint annotation and adds return format details, providing 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 clear sentences front-load the purpose, with no unnecessary words or repetition.

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 main functionality and return structure but lacks details on pagination and ordering parameters, given no output 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?

With only 17% schema coverage, the description adds context on filtering but does not explain pagination (skip/first) or ordering parameters, leaving 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 exchange records from the Boson subgraph, lists filtering options (buyer/seller/state), and distinguishes from write operations among siblings.

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 read-only usage but does not explicitly state when to use this tool versus alternatives or provide 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; description adds that signer is not needed and describes return format and pagination/filtering behavior. Provides 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 sentences, each adding value. Front-loaded with purpose, 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?

No output schema, but description specifies return array shape. Complexity is moderate (6 parameters); description covers core behavior and return format, though lacks parameter 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 low (17%), description mentions pagination/ordering/filtering but does not detail parameters individually. Provides high-level meaning but lacks specifics for fundsSkip, fundsFirst, fundsFilter, fundsOrderBy, fundsOrderDirection.

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 reads treasury fund balances from the Boson subgraph, distinguishing it from sibling mutation tools like deposit_funds and withdraw_funds. The verb 'reads' and resource 'treasury fund balances' 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?

Explicitly notes read-only nature and that signerAddress is not required, guiding when to use. Mentions pagination/ordering/filtering support, but does not explicitly contrast with other query tools like get_sellers.

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?

ReadOnlyHint annotation is already present; description reinforces read-only nature and specifies return structure (array with key fields). Adds value beyond annotation by describing output format.

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, efficiently communicates purpose and key features. Could be improved with bullet points or structured breakdown but remains concise.

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, description only lists a few output fields and omits nested object behavior. Does not cover pagination defaults or parameter semantics adequately for such a complex 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?

Schema coverage is only 8% (only configId described). Description mentions pagination, ordering, filtering generically but does not explain specific parameters (skip, first, orderBy, filter). Vague for 12-parameter tool.

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 reads offer listings from a specific subgraph. Verb 'Reads' and resource 'offer listings' are specific. Differentiates from sibling read tools (e.g., get_exchanges) by targeting 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?

Implies usage when needing offer listings but does not provide explicit when-to-use or when-not-to-use guidance. No mention of 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 provide readOnlyHint=true. Description adds 'No auth required' but no further behavioral detail. 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?

Two efficient sentences, front-loaded with purpose, zero waste.

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?

Describes return values (agents, entities, roles) but lacks output schema or example. Adequate for simple read operation given 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 has 100% coverage with full description for configId. Description adds no additional parameter context, 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?

Description clearly states it returns all registered dACP agents, listing associated protocol entities and roles, distinct from siblings like register_agent.

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 'No auth required', providing a key usage constraint. Does not explicitly contrast with alternative tools, but the read-only nature 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 already declare readOnlyHint=true, so the description's 'Read-only' adds no new behavioral insight. There is no mention of rate limits, data freshness, pagination limits, or any side effects. Beyond the safety hint, the description contributes little behavioral 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?

The description is two sentences, front-loaded with the main action, and every word adds value. It efficiently communicates purpose, optionality, and output format without 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 10 parameters (1 required, no output schema), the description is insufficient. It does not explain pagination (sellersSkip, sellersFirst), filtering (sellersFilter), ordering (sellersOrderBy, sellersOrderDirection), or the structure of included entities. For a complex query tool, more detail is needed.

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%, with only configId having a full description. The description vaguely mentions 'Optionally includes related offers, exchanges, funds, and logs' but does not elaborate on the meaning of parameters like includeLogs, sellersSkip, sellersFilter, or sellersOrderBy. It fails to 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 reads seller account entities from the Boson subgraph, optionally including related data. It distinguishes itself from sibling tools like get_sellers_by_address (which filters by address) and update_seller (which writes). The verb 'Reads' and resource 'seller account 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?

The description does not explicitly state when to use this tool versus alternatives. It mentions optional includes but lacks guidance on when to choose get_sellers over get_sellers_by_address or other read tools. No exclusion criteria or context for selection 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?

The description states 'Read-only' which aligns with the readOnlyHint annotation. It also adds the return type ('array of seller entities'), providing value beyond annotations. No contradictions found.

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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second explains when to use it, the third clarifies idempotency and 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 the high parameter count and no output schema, the description is incomplete. It lacks guidance on optional parameters like includeLogs, sellersFilter, pagination, and ordering. The agent would struggle to use this tool correctly without additional inference.

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 9% schema description coverage and 11 parameters, the description adds no parameter-level explanations. The address parameter is implied but not detailed. The configId parameter is described in the schema but not in the description. This is insufficient for an agent to select the correct 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 reads seller entities for a specific Ethereum address and explicitly distinguishes its use case: checking if a signerAddress exists before calling create_seller. This contrasts with sibling tools like create_seller, update_seller, 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?

The description provides a specific usage scenario (before create_seller) and implies a context (checking existence). However, it does not explicitly state when not to use this tool or mention alternatives like get_sellers, though the sibling list includes that.

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 'Read-only' confirms this. The description adds transparency about the return format (array of objects with address, name, symbol, decimals) and that it is safe (no side effects). No contradictory or missing behavioral traits.

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

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

The description is three sentences covering purpose, usage guidance, read-only nature, and return format. Every sentence serves a purpose, with no redundancy. It is front-loaded with the 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?

Given the tool has one parameter, no output schema, and annotations provide read-only hint, the description fully explains what the tool does, how to use the result, and what the return value contains. It leaves no gaps for an AI agent to misunderstand.

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 a detailed description for configId. The description does not add new parameter-level information beyond what the schema provides, so it meets 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 ('Returns'), resource ('ERC-20 tokens accepted as exchange tokens'), and scope ('on the given configId deployment'). It distinguishes from sibling tools by specifying it is for querying tokens, not mutating them, and gives usage context ('Use returned addresses in exchangeTokenAddress fields of create_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 explicitly tells the agent when to use this tool: to obtain token addresses for create_offer. It marks the operation as read-only, implying safe invocation. However, it does not explicitly mention when not to use it or list alternatives, though the sibling list includes many mutation tools, making the distinction 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 already declare destructiveHint=true; the description adds useful behavioral traits: the constraint that only the buyer can call, the time window, and the return of unsigned transaction data. It does not contradict annotations. It is transparent about the mutation but could detail side effects.

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

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

Three concise sentences: action+resource, constraints, and output. No redundant information. Every sentence earns its place, making it easy to parse quickly.

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

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

Given 4 parameters and no output schema, the description covers the essential purpose, constraints, and return type. It could mention that the returned unsigned transaction data needs to be signed and sent (e.g., via send_signed_transaction), but the sibling tool set implies this. Overall, adequate for a straightforward mutation 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?

Input schema has 100% coverage with good parameter descriptions. The tool description adds no additional per-parameter semantics beyond the schema, which is adequate. Baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Raises a dispute on a redeemed exchange') and uniquely distinguishes this tool from siblings like 'retract_dispute', 'escalate_dispute', etc., by stating it is the initial action of raising, with clear constraints (caller must be buyer, must be within disputePeriodDurationInMS).

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 to use (after redemption, within a time window) and who can call (buyer), providing clear context. However, it does not mention when not to use or list alternatives (e.g., if the dispute already exists), which would strengthen the 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 the caller must be the buyer, that the dispute period starts, and that it returns unsigned transaction data, providing useful 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, no redundancy. The action and key details are 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?

The description explains the purpose, preconditions, effect, and output format (unsigned transaction data). No output schema exists, but the description compensates adequately.

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 additional parameter-level information, 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 action ('Redeems a voucher'), the context (signalling physical receipt, starting dispute period), and what it returns (unsigned transaction data). It differentiates from sibling tools that combine redeem with other steps.

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 the caller must be the buyer and explains the consequence (dispute period starts). While it doesn't list alternatives or exclusions, the precondition and effect are 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 already indicate destructiveHint=true. The description adds context about returning unsigned transaction data, resetting state to 'Resolving', and returning the fee, which is beyond what annotations provide. However, it does not disclose authorization requirements or potential side effects beyond what is stated.

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 concise sentences with no wasted words. It front-loads the purpose and then lists effects and return value efficiently.

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 3 parameters, no output schema, and annotations present, the description covers the action and its outcomes. It could mention that the returned unsigned transaction data is typically sent via 'send_signed_transaction', but overall 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 100% with detailed descriptions for all three parameters. The description does not add meaningful semantic information beyond what the schema already provides (e.g., configId format, exchangeId source, signerAddress purpose). Baseline of 3 is appropriate.

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

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

The description clearly states the action 'refuses to decide an escalated dispute' and specifies the effects: returning the escalation fee, resetting dispute state, and returning unsigned transaction data. This distinguishes it from related 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 implies usage when a dispute resolver opts not to decide, but does not explicitly state when to use versus alternatives (e.g., 'decide_dispute' or 'resolve_dispute'). No exclusions or prerequisites are 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 readOnlyHint=false and destructiveHint=false. The description adds that registration is server-local and signature-based, and mentions a return value. It does not detail edge cases (e.g., overwriting existing registration) or side effects, but provides modest 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 focused sentences: first states purpose, second adds context and return info. No redundant or ambiguous phrasing. Front-loaded with key 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?

The description lacks explanation of prerequisites, failure modes, or integration with other tools. Given no output schema and sparse annotations, the description is moderately complete but misses important usage context 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?

Schema description coverage is 0% (only signerAddress has a description). The description loosely refers to 'Ethereum identities and roles' without detailing parameters like name, description, entities, or nested fields. It adds minimal meaning beyond the schema's type 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 ('Registers a dACP agent'), the resource ('with this MCP server instance'), and the associations ('Ethereum identities and roles'). It distinguishes this tool from siblings which focus on exchanges, disputes, offers, etc., as 'register' is a unique operation.

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 (independent registration before other operations) via 'Server-local state — no configId/signerAddress context needed.' However, it does not explicitly state when to use vs. alternatives, nor does it mention when not to use or 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 declare readOnlyHint=true, and the description adds that it returns a string. It does not disclose error conditions or performance characteristics, but read-only nature is covered. 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 sentences, front-loaded with the primary action. Every sentence adds value: what it does, when to use, and what it returns. 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 5 parameters with nested objects and no output schema, the description should elaborate on the return format (e.g., plain text vs HTML) and parameter specifics. It says 'text/HTML' but lacks detail. Adequate for basic understanding but incomplete for robust selection.

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 40%, and the description does not explain any parameters in detail. Parameters like 'template' and 'signerAddress' are left unclear, requiring the agent to infer from names. The description adds no semantic value beyond the schema's sparse 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 it renders the legal contractual agreement text/HTML for an offer, with specific inputs (offer data and metadata) and output (rendered agreement string). This distinguishes it from sibling transaction tools like 'commit_to_offer' which execute blockchain 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?

The description says 'Use to preview or store the agreement', which implies appropriate use cases but does not explicitly state when not to use or provide alternatives. The sibling list shows it's a rendering tool, but no comparative guidance is 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 provide destructiveHint=true. Description adds workflow context (local signing, return of unsigned tx data) and clarifies that no direct on-chain action occurs, complementing annotations well.

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: purpose followed by numbered workflow steps. Concise, front-loaded, 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?

Handles 8 parameters (7 required) well by linking to sibling tools and explaining return value ('unsigned transaction data'). No output schema needed; description covers integration flow.

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 description adds value by explaining the origin of sigR/sigS/sigV from local EIP-712 signing, which aids understanding beyond 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?

Description clearly states 'Resolves a dispute by mutual agreement.' and outlines the multi-step workflow, distinguishing it from siblings 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?

Explicitly says when to use: after both parties sign typed data locally, and that either party submits signatures. References create_dispute_resolution_proposal as prerequisite, providing clear usage context.

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 releases seller deposit, restores completion flow, returns unsigned transaction data, and requires caller to be the buyer. This provides meaningful behavioral insight not present in annotations 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?

Two sentences, front-loaded with the core action. No redundant or extraneous text. 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?

The description adequately covers the purpose and high-level effect. With strong schema coverage and annotation hints, the agent has enough context to invoke the tool. Could be improved by mentioning that the returned unsigned transaction must be signed and sent via send_signed_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?

Input schema has 100% description coverage, so the schema already documents all parameters well. The description adds no additional parameter meaning beyond the schema. 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?

Description clearly states the action (retracts a raised dispute), the effect (releasing seller deposit, restoring completion flow), and the caller constraint (buyer who raised it). This effectively distinguishes it from sibling tools like raise_dispute, escalate_dispute, 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?

Provides clear context on who should use it (buyer who raised the dispute) and what it accomplishes. However, it does not explicitly contrast with alternative dispute resolution tools (e.g., resolve_dispute or decide_dispute), which would strengthen 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?

The description discloses the destructive nature (funds are returned, voucher revoked) and returns unsigned transaction data, which goes beyond the annotations (destructiveHint: true). 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?

The description is two sentences, front-loaded with the core action and effect. Every sentence provides essential information without 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?

The description mentions 'Returns unsigned transaction data' but does not explain what steps follow (e.g., signing and sending via send_signed_transaction). Given no output schema, more context on the next action 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 coverage is 100% with detailed parameter descriptions. The tool description does not add any extra parameter semantics beyond the schema, so score is at 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 action ('Revokes'), the resource ('committed voucher'), and the effect ('returning funds to the buyer'). It also specifies the caller role ('seller assistant'). This is specific enough to distinguish from sibling tools like cancel_voucher, though not explicitly differentiated.

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 prerequisite ('Caller must be the seller assistant') but does not specify when to use this tool versus alternatives like cancel_voucher or redeem_voucher. No exclusions or contextual when-not-to-use guidance is 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?

The description adds behavioral context beyond annotations: it specifies the default for includeInvalidOffers (false, meaning only valid offers), and confirms the tool is read-only (consistent with readOnlyHint annotation). No contradictions; the description enriches 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?

The description is two sentences, front-loaded with the main purpose, and lists key features concisely. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.

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 clear purpose and features, the description does not explain the return structure beyond 'array of product search result fragments.' With 8 parameters, no output schema, and nested objects, the description should elaborate on the output fields and any error behavior. This gap makes the tool less transparent for automated invocation.

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 schema description coverage at 38%, the description partially compensates by mentioning 'Supports pagination, ordering, filtering' for parameters like productsSkip, productsFirst, productsOrderBy, and productsOrderDirection. However, it does not explain the meaning of nested objects (productsFilter) or the full list of ordering fields. The includeInvalidOffers parameter is well-described, but overall the description adds only moderate value 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 'Searches products in the Boson subgraph by keywords matched against title, description, brand, category, and tags,' specifying the verb, resource, and search fields. It also distinguishes from sibling tools like get_all_products_with_not_voided_variants by being a keyword search with pagination and 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 provides clear usage context: it is a read-only search tool supporting pagination, ordering, filtering, and an includeInvalidOffers flag. However, it does not explicitly state when not to use this tool or compare it with alternatives like get_all_products_with_not_voided_variants, so it lacks explicit 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 indicate destructiveHint=true, so the description does not need to restate that. It adds context about Biconomy and ERC-20 payment, but does not disclose potential side effects like gas costs, transaction status, or failure modes.

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 succinct sentences that convey the core functionality and return value without unnecessary words. Excellent 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 complexity (6 required parameters, nested object, no output schema, many siblings), the description is insufficient. It does not explain the return value structure, error handling, or how this fits into the broader transaction workflow.

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 50%; description adds that 'request' is an ERC20ForwardRequest and 'domainSeparator' is a signature. However, it does not explain the nested fields within 'request' or the exact format of 'signature' and 'domainSeparator', leaving ambiguity.

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 'Relays' and the resource 'Biconomy forwarded meta-transaction (ERC-20 gas payment)'. However, it does not distinguish this from sibling tools like 'send_meta_transaction' or 'send_native_meta_transaction', which are also transaction relay 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?

The description mentions prerequisites ('Requires a complete ERC20ForwardRequest and domain separator signature') but provides no guidance on when to use this tool vs. alternatives, or when not to use it. Given the large sibling set with similar transaction tools, this is a gap.

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, so the description's mention of 'relays' adds little new safety info. It does explain that the user pays no gas and requires signature components, but lacks details on side effects like blockchain state changes. The description does not contradict 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 primary purpose. Every sentence adds value: what it does, requirements, and return type. No redundant or verbose language.

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 required parameters and no output schema, the description covers the essential context: purpose, requirement for locally-signed signature, gas saving, and return type. However, it could elaborate on the relay process or expected behavior to fully compensate for the missing output 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%, leaving many parameters undocumented. The description adds context for sigR/sigS/sigV (from EIP-712 payload) and mentions functionName/functionSignature indirectly, but fails to explain nonce, functionName input format, or functionSignature encoding. This helps baseline but insufficient for full clarity.

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 verb 'relays' and the resource 'meta-transaction', which is distinct from general transaction tools. However, it does not explicitly differentiate from closely related siblings like send_forwarded_meta_transaction or send_native_meta_transaction, slightly reducing clarity.

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 usage condition: 'Use when the target operation requires metaTx relay.' This helps the agent decide when to invoke. However, it does not list alternatives or when not to use, which is acceptable given the tool's specialized nature.

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 set `destructiveHint: true`, so the description adds context about using Biconomy and returning relay transaction data. This goes beyond the annotations, but does not disclose additional behavioral traits such as rate limits or failure modes.

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-load the core action and requirements, with no wasted words. Every sentence adds value—describing the mechanism and 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 the complexity (7 required params, no output schema), the description covers the main action, prerequisites, and return type. It lacks details on what the relay transaction data contains, but is sufficient for an agent familiar with meta-transactions.

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 covers only 43% of parameters with descriptions. The description compensates by explaining that `functionSignature`, `sigR`, `sigS`, and `sigV` come from a locally-signed EIP-712 payload, adding meaning beyond the schema patterns and types.

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: 'Relays a native meta-transaction (EIP-712 signed function call) via Biconomy.' It uses a specific verb (relays) and resource (native meta-transaction), and distinguishes from sibling tools like `send_meta_transaction` by specifying 'native' and 'via Biconomy'.

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 by requiring 'ABI-encoded function signature and sigR/sigS/sigV from a locally-signed EIP-712 payload,' but does not explicitly state when to use this tool vs alternatives like `send_meta_transaction` or `send_signed_transaction`. No exclusions or when-not 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 indicate destructiveHint=true, and the description confirms a write operation ('Broadcasts'). It adds value by specifying the return fields (transaction hash, block number, gas used) and the required signing method. It does not mention cost or failure modes, but the annotation covers the essential behavioral trait.

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 only two sentences: the first states purpose and required input format, the second states return values. Every sentence is necessary, and the structure is front-loaded, allowing quick comprehension.

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 two required params and no output schema, the description covers the return values and input format thoroughly. It lacks details on error handling or gas implications, but given the destructive annotation and typical Ethereum transaction semantics, it is sufficiently complete for an AI 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?

Schema coverage is 100%, so baseline is 3. The description adds extra context beyond the schema by explaining the signedTransaction format with an example (ethers wallet.signTransaction(tx)) and detailing the configId format. This enhances understanding for an agent selecting the tool.

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 'Broadcasts' and the resource 'signed raw Ethereum transaction'. It distinguishes from sibling tools like send_meta_transaction by specifying that the transaction must come from local wallet signing, 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 gives clear guidance on when to use this tool: 'signedTransaction must be 0x-prefixed RLP-encoded hex obtained from local wallet signing'. It also mentions the configId parameter format. However, it does not explicitly exclude scenarios (e.g., when using meta-transactions) or provide alternatives, which would improve 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?

The description explains that this tool generates data to be signed offline, consistent with the readOnlyHint annotation. It adds context about the return value and next steps, which helps the agent understand it is a preparatory read operation.

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 essential information is front-loaded: what the tool does, when to use it, and what to do with the output.

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 (32 parameters, nested objects, no output schema), the description provides adequate workflow context and tells the agent what to do after invoking. It could mention the return format more precisely, but it suffices for a preparatory 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?

Schema coverage is high (94%), so the baseline is 3. The description does not elaborate on individual parameters beyond what the schema already covers. It adds minimal value for parameter semantics, but the schema is 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 verb (generates) and resource (EIP-712 typed data for a non-listed offer), and distinguishes from siblings by specifying it should be called before create_offer_and_commit or void_non_listed_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?

Explicitly states when to call this tool relative to other tools ('Call before create_offer_and_commit or void_non_listed_offer') and describes the workflow (generate, sign locally, use signature). No exclusions or alternatives are mentioned, but the 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?

The description contradicts the readOnlyHint=true annotation by stating the tool authorizes a spender to pull tokens, which is a mutation. It does not clarify that the signature enables a state-changing transaction, and the annotation is misleading. Flagged as annotation 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 concise at three sentences, front-loading the core action and output. It is well-structured but could be slightly more precise about the 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 the lack of output schema and many sibling tools, the description is incomplete. It does not explain how this permit type differs from others (e.g., vs. erc2612), nor does it specify prerequisites like token support for DAI-style permits.

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 input schema provides descriptions for all parameters. The description does not add additional semantic value beyond what the schema already provides, meeting the baseline expectation.

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?