agentic-commerce

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the mutating/risky profile is already known. The description adds real context beyond that: it does not submit on-chain but 'Returns unsigned transaction data', and it ties into the metaTx relay workflow. It does not mention the unlimited-allowance risk (only the schema alludes to max uint256), leaving a small gap for a destructive approval 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?

Three tightly packed sentences with zero filler: purpose first, then the ordering/exception rule, then the return behavior. Every sentence earns its place and the most decision-relevant constraint leads.

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

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

No output schema exists, but the description compensates by stating the return is unsigned transaction data, and it explains the workflow position and the metaTx alternative. For a 5-param approval tool this gives an agent everything needed to invoke it in the right sequence.

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 the schema already documents amount, configId, executionMode, and both addresses in detail. The description adds no parameter syntax or format beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Grants ERC-20 allowance to the Boson Protocol contract'), and distinguishes itself from siblings by naming commit_to_offer and deposit_funds as the operations it must precede. An agent can tell exactly what this does without opening the schema.

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 ordering requirement ('must be called before commit_to_offer or deposit_funds when using non-native exchange tokens') and the one exception (metaTx relay with transferAuthorizations built via sign_receive_with_* and passed to send_meta_transaction). When-to-use, prerequisite, and alternative path are all covered.

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 flag destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds material context beyond that: it clarifies the caller/signer model (signerAddress unless 'buyer' is set) and, crucially, that the tool 'Returns unsigned transaction data' rather than submitting — a behavior an agent must know to wire up signing correctly. It does not state irreversibility or failure modes, keeping it short of a 5.

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

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

Four tight sentences, front-loaded with purpose, each conveying distinct operational information (effect, caller model, prerequisite, metaTx shortcut, return shape). Dense but no filler; only the metaTx sentence is slightly long.

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

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

With no output schema, the description correctly discloses the return shape ('unsigned transaction data'), covers the approval prerequisite, the gasless alternative, and the signer model. The remaining gap is routing versus the six sibling commit_* tools, which is significant given the crowded namespace.

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 the baseline is 3. The description goes further by explaining the signerAddress-vs-buyer relationship and by pointing out that transferAuthorizations are built with a sign_receive_with_* tool, connecting parameters to the wider workflow in a way the schema alone does not.

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?

States a specific verb ('Commits to') plus resource ('an offer') and adds the observable consequences: an exchange is created and a voucher NFT is minted. However, with siblings like commit_to_buyer_offer, commit_to_conditional_offer, and commit_to_offer_and_redeem_voucher, the description never explains what makes this the plain/base variant, so an agent cannot fully disambiguate from the name alone.

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?

Gives genuine sequencing guidance ('For ERC-20 offers, call approve_exchange_token first') and names the metaTx alternative path via send_meta_transaction. But it offers no guidance on when to choose this tool over the many sibling commit_* variants, which is the primary routing decision an agent faces here.

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 only declare readOnlyHint=false and destructiveHint=true, so the description carries the real behavioral load: it discloses atomicity, that voucher transferability is skipped, that the dispute-period clock starts immediately, that it returns unsigned transaction data, and the allowance prerequisite. This is meaningful context well 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?

Three tight sentences: the action leads, the precondition and mode-specific requirements follow, and the side effects plus return value close. Front-loaded and free of filler despite dense protocol terminology.

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 mutating tool with no output schema, the description covers the precondition, atomic side effects, and return format ('unsigned transaction data'), which is sufficient to invoke it correctly. It stops short of explaining the direct-vs-metaTx resolution flow, which the schema's enum description partly covers.

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 all four parameters (including the executionMode enum with direct/metaTx) are already documented. The description reinforces signerAddress behavior but adds little parameter syntax or format beyond the schema, so the baseline 3 applies.

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

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

States a specific compound verb+resource: atomically commits to an offer and immediately redeems the voucher in one transaction. This clearly distinguishes it from the single-action sibling commit_to_offer and signals its relationship to commit_to_conditional_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?

Gives a concrete precondition (buyer must already hold ERC-20 allowance via approve_exchange_token, or pass transferAuthorizations in metaTx mode) and names the helper tools involved. However, it never explicitly says when to prefer this over commit_to_offer followed by redeem_voucher separately, so routing among the commit variants is left to inference.

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?

Beyond the destructiveHint=true/write annotations, the description discloses two non-obvious behaviors: signerAddress is auto-assigned as admin/assistant/treasury, and the tool returns unsigned transaction data rather than executing on-chain. This tells the agent a follow-up sign/send step is required. It does not flag irreversibility of the on-chain account creation.

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

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

Four short sentences, front-loaded with the purpose, then prerequisite, behavior, and inputs. Generally efficient, though "Provide seller metadata and royaltyPercentage" adds little beyond what the schema already conveys.

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 an 18-parameter creation tool with no output schema and low schema coverage, the description covers the transaction-return behavior but omits guidance on many required structural parameters. An agent would still rely heavily on the schema and guesswork for fields like type and kind.

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 39% across 18 parameters. The description only re-mentions royaltyPercentage and signerAddress (already documented in the schema) and vaguely says "Provide seller metadata," leaving required params like type, kind, contactPreference, authTokenId, and authTokenType unexplained in both places. It fails to 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?

States a specific verb and resource ("Creates a seller account on Boson Protocol") and frames its role as a prerequisite for offers. It is clearly distinguishable from create_buyer and create_offer, though it does not explicitly contrast with update_seller, which would have earned a 5.

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?

"Required before creating any offers" provides clear, actionable context for when this tool is needed. It stops short of naming exclusions or the alternative (update_seller for existing accounts), so it does not reach a 5.

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

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

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds real behavioral context beyond them: the approval prerequisite, the gasless metaTx bypass, and that the call returns unsigned transaction data. It does not discuss failure/revert conditions or what happens to treasury state, so not a full 5.

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, zero waste, front-loaded with purpose then prerequisites then return value. Dense tool references (approve_exchange_token, sign_receive_with_*) are necessary for chaining rather than filler.

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 6-param destructive write with no output schema, the description covers purpose, prerequisites, alternate execution paths, and the return shape. Minor gaps remain around error/revert behavior and whether the returned unsigned tx must be relayed via send_signed_transaction in direct mode.

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 every parameter (including tokenAddress's address(0) convention and executionMode's enum) is already documented in the schema. The description restates the approval/metaTx dependency for amount but adds no syntax or format detail beyond what the schema provides — baseline 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?

States a specific verb and resource (deposits ERC-20 or native tokens into an entity's protocol treasury) and immediately names the concrete use case (seller deposit). An agent can distinguish it from sibling withdraw_funds and from the approve/transfer helpers without opening the schema.

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 routes prerequisites: 'For ERC-20, call approve_exchange_token first,' and gives the alternate path — skip approval in metaTx mode by passing transferAuthorizations to send_meta_transaction. This names the sibling tools and the condition that selects each path.

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 flag destructiveHint=true, and the description adds real context: no gas cost to the user, the EIP-712 sigR/sigS/sigV requirement, and the token-pull mechanism. It does not state that the relay is broadcast irreversibly on-chain or what happens if the nonce/signature is stale, which for a destructive write tool would be worth adding.

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?

Five tight sentences, front-loaded with the core action and gasless benefit, then signature requirements, use condition, optional authorizations, and the return value. Dense but no sentence is filler; the nested-signing detail is the only slightly heavy part.

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 9-param, 8-required write tool with no output schema, the description covers the purpose, prerequisite signing flow, optional token-pull flow, and states the return value. The main gap is the absence of a routing rule against the two sibling meta-transaction tools.

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 (33%), so the description must compensate, and it does for the critical cryptography params: it explains that sigR/sigS/sigV come from a locally-signed EIP-712 payload and that transferAuthorizations are built via sign_receive_with_* tools. functionName, functionSignature, and nonce remain undocumented, but the hardest params are covered.

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?

Specific verb+resource: 'Relays a pre-signed meta-transaction via Biconomy' with the gasless rationale. It is clear what the tool does, but it does not distinguish itself from the sibling relay tools send_forwarded_meta_transaction and send_native_meta_transaction, which an agent must choose among.

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?

'Use when the target operation requires metaTx relay' gives a condition, and it explains the transferAuthorizations alternative to approve_exchange_token. However it offers no guidance on when to pick this relay over send_forwarded_meta_transaction or send_native_meta_transaction, leaving the most likely sibling confusion unresolved.

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 readOnlyHint=true annotation correctly reflects a local typed-data generator, and the description adds real context beyond it: the default spender (protocol diamond), the expiry-bounded authorization scope, and the exact shape of the returned transferAuthorization template. It does not cover failure modes or token-support limits, keeping it from a 5.

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 dense sentences that front-load the core action before the usage workflow and return description. Every sentence carries task-relevant information, though the embedded field paths make some clauses heavy.

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

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

With no output schema, the description correctly compensates by naming what is returned (typedData plus a transferAuthorization template) and how it must be signed and forwarded. Combined with fully-covered params, an agent has enough to invoke it correctly; only the choice among sibling permit standards is unaddressed.

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 the schema already documents all seven parameters, making 3 the baseline. The description adds only marginal detail, clarifying the spender default and the expiry cutoff ('until `expiry`'), while value, configId, signerAddress, tokenDomainName and exchangeTokenAddress are left 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?

States a specific verb and resource: 'Generates EIP-712 typed data for a DAI-style Permit.' An agent can tell what the tool produces. However, it does not explicitly differentiate itself from the closely-named siblings sign_receive_with_erc2612_permit, sign_receive_with_erc3009_authorization, and sign_receive_with_permit2, so channel selection still requires inference.

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