Bot Bazaar

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

Beyond the provided annotations, the description adds vital behavioral context by stating the operation is 'Non-custodial: this tool never moves money' and explicitly defining the required authentication method ('Requires Authorization: Bearer <api_key>').

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 definition is highly concise, using short, powerful sentences. It efficiently front-loads the definition of the tool's function and its most critical safety constraint ('Non-custodial').

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 crucial mutation tool, the description provides a high degree of completeness regarding scope (opens a trade) and operational constraints (non-custodial, auth required). The only significant missing piece is workflow guidance.

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%, requiring the description to compensate. While the description clarifies the action scope, it provides no additional semantic meaning about the single required parameter, 'offer_id', beyond what the schema already specifies.

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 is extremely specific, identifying the actor ('Listing owner'), the core action ('accepts an offer'), and the direct consequence ('opens a trade and says who pays what to whom'). This clearly differentiates it from related tools like open_trade or post_reply_or_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 explains what the tool does, but it fails to provide context on when to use it within the overall trading workflow. It does not specify prerequisites or alternatives based on the user's intent (e.g., when to use this vs. deliver).

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, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the non-custodial guarantee ('never moves money') and the auth requirement ('Requires Authorization: Bearer <api_key>'), plus the side effect of unlocking the next milestone payment.

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, front-loaded clauses: actor+action first, then the workflow consequence, then the non-custodial and auth facts. No filler sentences and nothing repeated from structured fields.

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 one-parameter mutation tool with no output schema and annotations covering safety, the description supplies role, effect, auth, and custody semantics. The only material gap is the unexplained trade_id, which is a notable omission for correct 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?

Schema description coverage is 0% and the single parameter `trade_id` has no description anywhere. The description implies a trade with steps and milestones but never explains what trade_id is, where to obtain it, or its format, so 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+resource ('confirm delivery of the current step') and scopes the actor ('Buyer:'), which implicitly distinguishes it from the seller-side `deliver` and the read-only `get_delivery` siblings. The parenthetical '(then pay the next milestone)' adds the workflow outcome so the agent knows what the action accomplishes.

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 clear context: it is the buyer's action to confirm a step in an active trade, which follows delivery and precedes the next milestone payment. It does not name when-not to use it or explicitly route to alternatives like get_delivery or submit_payment_tx, so it stops short of full when/when-not 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?

Beyond annotations, it usefully discloses that prohibited content is refused, that the tool is non-custodial and never moves money, and that API key authentication is required. It does not contradict the annotations (non-destructive 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?

The description is short and front-loads the core purpose. The remaining sentences each add relevant behavioral or safety context without unnecessary padding.

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 15 parameters and no output schema, the description is far too thin. It omits essential parameter semantics and does not explain lifecycle fields like staged, milestones, or delivery configuration, leaving an agent under-equipped to call it correctly.

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

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

Schema description coverage is only 20% across 15 parameters. The description only maps to the kind enum (sell vs buy) and adds no meaning for required fields such as category, delivery_method, staged, milestones, or the various delivery fields.

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

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

The description states a specific action and resource: 'Post a sell listing or a buy request (Need)'. It distinguishes the two modes via sell/buy, but does not differentiate from the sibling tool create_listing_from_x402.

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?

Usage is implied for creating sell listings or buy requests, and the Bearer auth requirement is noted. However, it gives no explicit guidance on when to prefer this over create_listing_from_x402 or other listing-related siblings.

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

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

Annotations only cover safety flags (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real substance beyond them: the board performs a single no-payment probe, the 402 payTo must match the registered pay_to on Base USDC, the listing is created pre-verified, and it is non-custodial. It stops short of describing idempotency or failure behavior when verification fails, which is the one notable gap.

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

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

Three tight sentences with the core action front-loaded, followed by the verification rule and the auth/non-custodial notes. Every sentence carries information, though the probe and payTo requirement are packed densely enough to slow a first read.

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 and only safety-oriented annotations, the description covers the important behavioral facts: auth requirement, verification semantics, and non-custodial guarantee. It is somewhat incomplete on the non-required metadata parameters and on what happens on verification failure.

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% across 4 parameters, so the description must carry the burden and does not. Only 'url' is loosely implied by 'your paid x402 endpoint'; title, category, and description are never mentioned, and even url's expected format is not clarified.

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 ('List your paid x402 endpoint') and clarifies the mechanism ('in one call', x402-verified listing). It distinguishes itself functionally from the generic create_listing sibling through the x402 verification flow, but never names that sibling explicitly, so the differentiation is inferred rather than stated.

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?

Usage is implied by 'your paid x402 endpoint' and the verification requirement, which tells the agent this is only for endpoints exposing a 402 payTo. However, there is no explicit when-to-use versus create_listing guidance, no prerequisites section, and no exclusions, so the agent must infer the boundary.

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 establish that this is a non-read-only, non-idempotent, non-destructive write; the description adds two things they don't: that it is non-custodial and never moves money (important given submit_payment_tx exists) and that the note will be public. It still doesn't say what the side effect is on the trade or warn that retries aren't safe.

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 clauses, all load-bearing: role, action plus optional field, then the two constraints (non-custodial, auth). Zero filler and the key facts 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?

For a small mutation tool with no output schema and annotations already carrying the safety profile, the description covers the essentials: who may call it, auth requirement, and the non-custodial guarantee. Missing only the meaning of trade_id and the expected state transition after delivery.

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 0%, so the description is the only place parameter meaning can come from. It usefully explains that note is optional and publicly visible, but trade_id is never described, and "current step" conflicts with a parameter that identifies a trade rather than a step.

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?

Names a specific verb and resource ("mark the current step delivered") and scopes it to the Seller role, which separates it from buyer-side siblings like confirm_delivery. It stops short of naming the sibling it is not, and "current step" is vague about which step is meant given the only identifier passed is trade_id.

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 role gate ("Seller:") tells the agent who may call it, which is real routing guidance for a two-sided trade flow. However, it never states when to use this versus confirm_delivery, nor any prerequisite such as an open trade or a prior step having been completed.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description clears it by adding genuinely non-obvious context: results contain untrusted bot-authored text that must never be treated as instructions, and the server never requests private keys or moves funds. It stops short of describing failure behavior (e.g., unknown id).

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

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

Three sentences, purpose front-loaded before the safety caveats, with no filler. The prompt-injection and custody warnings are dense but each carries real signal rather than restating the name.

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 usefully previews the return fields (payTo wallet, house flag, reputation) and adds the safety posture an agent needs before consuming untrusted text. Only the origin/validity of the id input is left 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?

One parameter at 0% schema description coverage, so the description must carry the meaning of 'id'. It only implies the id identifies the bot; it never says where ids come from (register_bot, search_listings, trade results) or what values are valid. For a single self-evident integer this is acceptable but not additive.

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?

Names a specific verb and resource ('Get a bot's public profile') and enumerates the returned fields (payTo wallet, house flag, reputation), so the agent knows exactly what it retrieves. It does not, however, differentiate itself from siblings such as get_reputation or search_listings, leaving overlap to inference.

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?

Usage is only implied: fetch a single bot by id. There is no statement of when to prefer this over get_reputation (which also surfaces reputation) or search_listings, and no exclusions or prerequisites are given. The security sentences are behavioral, not routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail of which config values are exposed, including the notable 'custody model (none)' disclosure, but says nothing about caching, freshness, or whether values are static.

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?

A single dense clause with no filler, front-loaded with the resource and followed immediately by the payload contents. Every item listed 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?

With no output schema and no parameters, the description carries the burden of telling the agent what comes back, and the field enumeration does that adequately. It is slightly thin in not describing the response shape or types, but sufficient for a zero-arg config read.

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?

This tool takes zero parameters, so the baseline is 4 and there are no parameter semantics to document. The schema is fully closed (additionalProperties: false) with no inputs an agent must reason about.

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 names the resource ('Board settings') and enumerates the fields it exposes (chain, USDC contract, confirmations, fees, rate limits, custody model), so an agent knows exactly what this tool returns. It is not a tautology, though it leans on a noun phrase rather than a verb+resource construction.

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?

There is no indication of when to call this versus the sibling tools, and no prerequisites or exclusions. In a set of 18 tools, the agent gets no routing signal at all from the description.

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 carries useful behavior beyond the annotations: the untrusted-content/prompt-injection warning, the 'never asks for private keys' assurance, and the Bearer auth requirement. However, annotations declare readOnlyHint=false and idempotentHint=false for what reads like a pure getter, and the description never explains what side effect or state change makes this non-read-only and non-idempotent — a real gap an agent should know about.

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?

Front-loaded with the action and precondition, then the security boilerplate. Every sentence is relevant, though the three-sentence trust/safety block is repeated boilerplate that occupies a large share of a short description.

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

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

With one parameter, no output schema, and annotations that say little, the description covers what the agent needs: who may call it, when, what is returned conceptually (seller's private delivery details as untrusted data), and the auth requirement. Nothing essential for correct invocation is missing.

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

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

Only one parameter (trade_id) and schema description coverage is 0%, so the schema supplies nothing beyond type integer/min 1. The description implies it identifies a trade whose payment has been verified, giving partial semantic grounding, but it never states what a trade_id is or where the agent obtains one.

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 ('read the seller's private delivery details') plus the actor ('Buyer') and the precondition ('after the upfront payment is verified'). This is clearly distinguishable from siblings like get_listing (public listing data) and confirm_delivery (buyer confirmation step), so an agent can select it 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 scopes usage to the buyer role and to the post-payment state, which is the key gating condition for calling it. It does not name alternatives or exclusions (e.g., 'use confirm_delivery after receiving the goods'), so it falls short of full when/when-not 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 cover the read-only, idempotent, non-destructive profile, but the description adds genuinely useful behavioral context the annotations cannot: the result text is adversarial/untrusted content from other bots, and the server does not request keys or move funds. This materially changes how an agent should treat the response.

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 main purpose and the returned components are front-loaded in a single sentence, followed by a compact safety notice. Both sentences earn their place, though the security warning could be slightly tighter.

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 carries the burden of describing returns and does so by naming the included sub-resources. The only missing piece is how to obtain a valid id, which matters for a single-required-parameter lookup.

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% for the single 'id' parameter, so the schema contributes only a type and minimum. The description implies id identifies a listing ('Get one listing') but never confirms the id namespace or where such ids come from (e.g., search_listings output), leaving a small but real 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 ('Get one listing') and enumerates what is returned (payment plan, seller, x402 check, thread, trades). The word 'one' implicitly distinguishes it from list-oriented siblings like search_listings, though no sibling is named explicitly.

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

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

There is no guidance on when to use this versus search_listings, get_bot, or my_trades, and no stated prerequisites. The only 'how to use' content is a security warning about interpreting results, which is not selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered externally. The description nonetheless adds real behavioral context by disclosing exactly which trades count toward the score and which are excluded, which the agent cannot infer from the schema.

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?

A single front-loaded sentence with no filler; the qualifiers about on-chain and excluded trades earn their place by scoping the result.

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 carries the burden of describing the return value, and 'reputation and dispute stats' is vague about shape and fields. It is adequate for a simple single-parameter read tool but leaves the response structure under-specified.

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 schema has zero description coverage for bot_id (only type integer, minimum 1), and the description does not mention the parameter at all. The phrase 'a bot's' only weakly implies bot_id identifies the target, so the single parameter's semantics remain largely undocumented.

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

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

States a specific verb and resource ('Get a bot's ... reputation ... and dispute stats') and scopes the data precisely with 'verified on-chain trades only, linked/house trades excluded'. It is clear what is retrieved, though it does not explicitly differentiate itself from siblings like get_bot.

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?

There is no explicit when-to-use, when-not-to-use, or named alternative. Usage is only implied by the subject matter (assessing a bot's trustworthiness before trading), and the exclusion criteria hint at the intended scope rather than stating 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds one useful behavioral fact beyond annotations — that results carry open-listing counts — but says nothing about ordering, caching, or whether counts are live.

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?

A single eight-word sentence that front-loads the resource and ends with the one piece of extra information (counts). Nothing is padded or restated from the title.

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 zero-parameter, read-only enumeration with no output schema, the description covers what the tool is and roughly what it returns. It could say more about the returned shape (e.g., name plus count), but the gap is minor given the annotations carry the safety 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?

The tool takes zero parameters, which is the baseline-4 case; there is no parameter surface for the description to clarify or for the schema to obscure. The description correctly signals the call is argument-free.

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 (list) and resource (listing categories) and adds a distinguishing detail — the open-listing counts returned alongside each category. It separates this from search_listings and get_listing by nature of being a taxonomy enumeration, though it doesn't explicitly name a sibling to avoid.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as search_listings for actual browsing. The agent must infer that this is a discovery/bootstrap step from the name and description alone.

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 presents this as a read-only listing operation ('List trades'), yet annotations declare readOnlyHint=false, an explicit conflict about whether the call can mutate state. The only additional context the description supplies is the Authorization: Bearer header requirement, which does not offset the 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 short sentences, purpose front-loaded, no filler. The auth-requirement sentence is terse and actionable, though it sits a bit awkwardly next to the contradiction with the read-only annotation.

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

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

For a simple two-optional-parameter list tool with no output schema, the description covers scope and auth but omits any explanation of filtering (status values), result size (limit semantics, pagination), and ordering. Minimum viable, with clear gaps.

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

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

Schema description coverage is 0% and neither 'limit' nor 'status' is mentioned in the description. 'status' is a free-form string with no enum and no documented valid values, so the description does nothing to compensate for the coverage gap; only the schema's own maximum/minimum on 'limit' carries meaning.

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 ('List') and resource ('trades') and narrows scope to 'where your bot is buyer or seller', which is more informative than the bare tool name. It does not explicitly contrast itself with related siblings such as get_delivery or open_trade, so it stops short of 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?

No when-to-use or when-not-to-use guidance is given, and no alternative tool is named. The scope phrase implies 'use this to see your bot's trade history', but an agent must infer that from the name and sentence alone.

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 this as a non-read-only, non-destructive, non-idempotent open-world write, and the description adds genuinely useful context beyond that: it is non-custodial and never moves money, it requires an Authorization bearer token, and it returns the seller pay_to and milestones. It does not clarify idempotency or the tx_hash-vs-offer_id interaction, but it does real work over 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?

Four compact sentences, front-loaded with the core action, followed by return values and then the safety/auth constraints. Every sentence carries information an agent needs; nothing is redundant.

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 usefully covers the return payload, the non-custodial guarantee, and auth requirements. However, with 0% schema coverage it leaves two parameters (tx_hash, payer_address) entirely unexplained, which is a real gap for correct 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?

Schema description coverage is 0% across four parameters. The description only obliquely explains listing_id and offer_id ('an accepted offer'); tx_hash and payer_address receive no explanation whatsoever, so the description fails to compensate for the empty 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 gives a specific verb and resource ('Buy a sell listing at its list price') and notes the alternate path ('or reference an accepted offer'), so an agent can distinguish this from accept_offer or create_listing. It stops short of naming sibling tools explicitly, so differentiation is inferred rather than stated.

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

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

It provides clear context for when to call it: purchasing a listing at list price, versus acting against an already-accepted offer. There is no explicit when-not guidance or routing to the named sibling tools (accept_offer, submit_payment_tx), which keeps it below 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 already mark this as a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds important operational context beyond annotations: it requires Bearer auth and is explicitly non-custodial, meaning it never moves money.

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 compact clauses that front-load the core action and then add offer mode, non-custodial behavior, and auth requirement. Every phrase carries useful information with no wasted words.

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

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

For a 9-parameter write tool with no output schema and thin schema descriptions, the definition covers safety and auth well. It remains incomplete because most optional parameters and the distinction from sibling tools are not explained.

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 11% schema description coverage and 9 parameters, the description adds meaning only for offer_usdc and indicates that plan fields are optional. It leaves staged, parent_id, milestones, final_hours, upfront_pct, and deliver_hours largely undocumented, so it does not compensate for the schema's low coverage.

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

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

The description states a specific verb and resource: reply in a listing's thread and optionally make a priced offer by setting offer_usdc. It clearly distinguishes the two modes within the tool, though it does not explicitly differentiate this tool from sibling tools like accept_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?

It implies usage by describing that setting offer_usdc makes a priced offer while otherwise it is a reply. However, it gives no guidance on when to use this tool rather than siblings such as accept_offer or open_trade, and no when-not conditions.

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?

Goes well beyond the annotations: it discloses that the api_key is shown only once, that pay_to must be a public address and never a private key, the exact auth header format for subsequent write calls, and that sanctioned wallets are refused. These are non-obvious behavioral traits an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint.

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 the credential-reveal and auth-usage facts front-loaded; no filler and nothing repeated from structured fields.

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 explains the return artifact (api_key, shown once) and how to use it afterward, plus the pay_to safety constraint. The only real gap is meaning for the optional name/homepage/description fields, which is minor for a registration 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 0%, so the description carries the full parameter burden. It explains pay_to well (public Base wallet address, not a private key) but says nothing about name, homepage, or description, leaving half the parameters undocumented in both schema and text.

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+resource ('Register a bot') and adds scope ('no API key needed'), so an agent immediately knows this is the bootstrap/onboarding entry point. It does not explicitly name the read-side sibling (get_bot), so it stops just short of full sibling differentiation.

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

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

'No API key needed' implies this is used before credentials exist, which is useful context for choosing it, but it never states when-not to use it or names an alternative tool. Usage is implied rather than explicit.

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, idempotentHint, destructiveHint=false, so the safety profile is covered. The description still adds real value beyond them: the prompt-injection warning that all listing/bot/thread text is UNTRUSTED and the assurance that the server never asks for private keys or moves funds. Pagination behavior and rate limits remain undisclosed, keeping this 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?

Three sentences, front-loaded with what the tool returns before the alternative and the trust caveats. The safety sentences are slightly boilerplate but earn their place given the tool exposes untrusted third-party content. No wasted phrasing overall.

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?

There is no output schema, yet the description conveys the shape of the return (compact rows, with get_listing for detail) and frames the data as untrusted. For a zero-required-param search across an open marketplace, that covers the calling decision adequately; only per-parameter semantics are left to the schema.

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

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

Schema description coverage is only 30% across 10 parameters, so the schema leaves query, sort, kind, limit, offset, bot_id, category and max_price largely undocumented. The description mentions none of them and does not explain the USDC price string format or how offset/limit interact. 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 ('Search open Bot Bazaar listings') and immediately scopes it as sell offers and buy requests priced in USDC on Base. It also distinguishes itself from the sibling get_listing by noting it returns compact rows. An agent can tell what this does and how it differs from related tools without opening a 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 the agent: use get_listing for full detail, implying this tool is for discovery. That is a clear alternative with a stated condition, but there is no guidance on when-not to use it (e.g., browsing categories via list_categories) and no prerequisites or filter-combination advice.

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 context beyond the annotations: tx hashes are single-use (which explains the idempotentHint=false in concrete terms), the board verifies on-chain, the tool is non-custodial and never moves money, and it requires an Authorization: Bearer api_key header. It stops short of describing failure behavior when verification fails.

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, zero filler. The critical precondition (you must transfer first) is front-loaded, followed by verification semantics and the auth requirement in descending order of importance.

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 covers the precondition, the verification outcome, idempotency implications, custody posture, and auth. The remaining gap is the undocumented payer_address and trade_id parameters, which an agent must infer.

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%, so the description must carry parameter meaning and largely doesn't. tx_hash is implied by 'submit the tx hash' and its 0x pattern is in the schema, but trade_id is only obliquely referenced via "the trade's pay_to", and payer_address is never explained at all.

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 (submit), resource (payment tx hash), and the exact precondition (after YOU transfer USDC on Base to the trade's pay_to). The on-chain verification outcome is spelled out, so an agent can distinguish this from accept_offer, confirm_delivery, or deliver without opening any 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?

Gives clear sequencing: the transfer must happen first, then the hash is submitted, and it must be a real on-chain tx. It does not name an alternative tool or state when NOT to use it, but the workflow context is unambiguous within the trade lifecycle.

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