Agoranome seller tools

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

With only readOnlyHint/openWorldHint in annotations, the description adds material facts: the call costs $0.01 USDC paid via x402 inside the call, failed calls are not charged, and the tool reports what Agoranome already holds rather than fetching fresh. It also discloses the post-settlement behavior (USDC transfer on Base, quote match, optional buyer-side receipt) beyond what annotations cover.

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 verdict contents and mode split are front-loaded and every sentence carries information (what is checked, when to use, cost model). The middle sentence is a dense run-on list, but it is not 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?

There is no output schema, so the description must convey return content and does: it enumerates the verdict's components and the settlement-mode proof fields. Remaining gaps are minor — no pagination/format detail, and the share/receipt publication side effect is only alluded to.

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 seven parameters are already documented, making 3 the baseline. The description only adds meaning for tx= (settlement mode) and loosely gestures at pay_to and expected_price; share, max_price, and accept_proof get no extra framing in the prose.

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 a specific verb and resource: a signed verdict on one x402 offer built from Agoranome's held data, enumerating what the verdict covers (Fair Offer block, pay-to, price vs listing/quote, verified deliveries, policy tiers). It is clear what the tool does and has a distinct two-mode shape, but it never names the nearby siblings (check_offer, check_fair_offer) it likely overlaps with, leaving that differentiation 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?

It states the operating moment explicitly ("before paying an x402 seller", "Use when an agent needs seller evidence at the moment of payment") and defines the tx= variant as the post-payment settlement check, so an agent knows which mode to pick. It stops short of stating when NOT to use it or pointing to an alternative sibling 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?

Goes well beyond the annotations: discloses the $1 USDC x402 charge, that failed calls are not billed, that nothing signed at a trap is settled, and that the signed report arrives within 24 hours. Minor tension with readOnlyHint=true since money moves and publish names the client publicly, but the description discloses both effects plainly rather than contradicting them.

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-loads purpose, then trap inventory, then cost and timing; every clause carries information. It is dense and jargon-heavy in a single block, which slightly raises parsing cost for an agent, but there is little 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?

With no output schema, the description carries the return-value burden and does: a signed report with traps refused, traps paid, cents at risk, and a certificate line, plus the 24-hour latency. An agent knows what it gets, what it costs, and what a failure looks like.

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 both 'client' and 'publish' are already documented in the schema. The description adds no extra meaning about either — no hint that version strings matter or what publishing entails beyond what the schema says. 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 ('red-team an x402 client') and enumerates exactly what is exercised: nine trap routes, each a $0.001 seller, one correct offer and eight named attacks. This is clearly distinguishable from siblings like buyer_check, conformance_check, and check_offer, which do not stand up adversarial 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?

'Use before a client or policy goes live' gives a clear activation condition, and the price line sets a cost gate. It stops short of naming a sibling alternative (e.g. when buyer_check suffices vs. when the paid drill is warranted), so routing is inferred 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 state readOnlyHint=true and openWorldHint=true, and the description adds critical behavioral context: the $1.00 USDC x402 payment occurs inside the call and failed calls are not charged. It also discloses return content (win rate with confidence intervals, loss reasons, tested edits), which is valuable beyond the annotations.

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

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

The description is front-loaded with the core question and mechanism, then covers trial structure, return values, and pricing in efficient sentences. Every sentence contributes useful information without 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?

For a two-parameter tool with no output schema, the description adequately explains the trial setup, return values, and payment behavior. Minor remaining gaps include persona/list-position details and any timeout or failure modes beyond billing, but the core invocation guidance is complete.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces that tasks are buyer-agent phrased and constrained to up to three, and that resource is the offer URL, but it adds little semantic detail beyond the schema's own 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 states a specific function: an A/B conversion test where buyer-agent models compare your x402 API against real Bazaar rivals, returning win rate, loss reasons, and tested edits. It is clear and distinctive from sibling tools like rank_check or lint_listing, though it does not explicitly name alternative tools to differentiate usage.

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 opening question 'Will buyer agents choose my x402 API?' implies the tool's use case for conversion testing, but there is no explicit guidance on when to choose it over siblings such as rank_sample, signed_sample, or demand_gaps. Usage is inferable but not directly 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?

Goes well beyond the thin annotations by disclosing cost ($1.00 USDC per call, paid via x402 inside the call), the refund policy (failed calls not charged), the one-payment/no-renewal model, and the consequence of failure (a passing badge is withdrawn the day a check fails, signed results published). These are exactly the operational facts an agent needs before spending 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?

All the right facts are present and the core behavior is front-loaded, but the single run-on sentence with nested parentheticals is hard to parse, and the juxtaposition of 'priced at 5 cents or less' with 'Price: $1.00 in USDC per call' reads as contradictory until the reader works out the first refers to the endpoint being certified.

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 minimal annotations, the description carries the load well: cost, cadence, badge behavior, and refund terms are all covered. It stops short of saying what the call returns (certification id, badge/status URL) or how an incompatible or unpaid endpoint is handled.

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 both url and notify are already documented with formats and defaults. The description adds intent context ('your route is paid once to check that failed calls are free') but never mentions the notify webhook, adding no meaning beyond the schema.

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

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

States a specific verb+resource (Fair Offer certification of an x402 API) and makes its defining trait — continuous daily re-checks over 30 days — explicit, which separates it from the one-shot certify_offer sibling. It never names certify_offer or any sibling directly, so the differentiation is inferable rather than spelled out.

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 for when this is the right call: you want a full certification now plus roughly daily re-runs for 30 days, with the public badge tracking the latest verdict. It does not state an explicit exclusion (e.g. 'use certify_offer for a one-time check'), leaving the agent to infer the alternative.

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 substantial behavior the annotations do not: $1.00 USDC cost paid in-band via x402, failed calls not charged, an outbound paid call to the user's route when it is priced cheaply, and a signed result published at a public URL regardless of outcome. It does, however, sit in tension with readOnlyHint=true, since the call spends money and hits a third-party endpoint — the description discloses this, so it is a mismatch with the annotation rather than a contradiction, but an agent trusting only the annotation would be surprised.

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?

Purpose is front-loaded in the first clause and the pricing/billing facts close it out, so the reading order is sensible. The middle is a long run-on chain of checks that is dense but not padded — nearly every clause conveys a distinct verified behavior.

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 tool with no output schema, the description covers what is checked, what a run costs, when charges are waived, and where the result appears (public signed URL). The main residual gap is what the pass/fail result actually contains and whether certification is repeatable/idempotent, but an agent has enough 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?

With a single fully documented parameter, the schema already defines `url` as a public https URL of the paid endpoint. The description adds only indirect context ('for an x402 API', 'your 402's fair-offer block'), which implies the URL must serve an x402 fair-offer document but never says so explicitly.

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 (certify) and resource (an x402 API's fair-offer block) and enumerates the concrete checks performed (receipts vs Base, sample attestation, 0.2 schema conformance, Bazaar price). It is clear what the tool does but never names or contrasts with the near-identical siblings check_fair_offer, check_offer, or conformance_check, so an agent still has to guess which certifier to pick.

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: it is evidently for someone who has published an x402 offer and wants it certified, and the '5 cents or less' clause hints at a conditional branch. There is no explicit when-to-use/when-not guidance and no mention of the many sibling checkers, which is exactly the ambiguity that matters here given 19 siblings with overlapping names.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new context: no payment is required and each rule returns one of four discrete verdicts. It stops short of describing auth/rate-limit behavior or what a response envelope looks like.

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 'Free' differentiator and the core action; the verdict vocabulary follows naturally. Minor cost: the accept_proof sentence carries a slightly dense embedded example.

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

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

No output schema exists, so the description takes on return-value disclosure and does explain the four verdict states per rule. Adequate for a 2-parameter read-only tool, though the overall response shape beyond the per-rule verdicts is not described.

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, but the description meaningfully upgrades the notably vague schema text for accept_proof ('Optional Accept-Proof value') by supplying a concrete syntax example ('sample=attested; price<=listing') and stating what the parameter answers.

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 concrete verb+resource ('check any x402 offer's Fair Offer block') plus scope qualifiers ('from outside, without paying'), which cleanly separates it from siblings like lint_listing or signed_sample that operate on listings or samples rather than an external 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 gives one concrete usage cue — pass accept_proof to check an offer against buyer requirements — but never states when to prefer this tool over lint_listing or the other validation-adjacent siblings, leaving comparison 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context: it states that nothing is paid or signed and that the result is an allowed/refused decision with reasons, which helps an agent understand the side-effect-free nature of the call.

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, front-loaded with the core question, and every sentence earns its place. The parenthetical policy summary and closing 'Nothing is paid or signed' add useful detail without bloat.

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 four-parameter, read-only check with no output schema, the description covers purpose, policy basis, and return shape (allowed/refused with reasons) adequately. It could say more about what happens with an invalid or unreachable URL, but the essential call context is present.

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 url, tier, max_price_usd, and expected_price_usd. The description echoes the policy concepts of price cap, listing price, and proof tier, but does not add syntax or edge-case semantics beyond what the schema provides; baseline 3 is appropriate.

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

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

The description gives a specific verb-and-resource question (whether a buyer's policy would pay an x402 offer) and names the policy being applied. It distinguishes the tool's scope well, but it never names sibling tools such as check_fair_offer or certify_offer to disambiguate when this policy check is the right one.

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 the question 'would a buyer's policy pay this x402 offer?' and by the 'Free' label, which suggests a no-cost pre-check. However, there is no explicit guidance on when to prefer this over check_fair_offer or certify_offer, and no stated prerequisites or exclusions.

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

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

Goes well beyond the annotations: it discloses the $1.00 USDC per-call price, that payment happens inside the tool call via x402, that failures are not charged, and that nothing is signed or paid against the target. This is exactly the cost and side-effect context an agent needs before spending money. Minor tension worth noting: readOnlyHint=true coexists with a per-call wallet charge, though the tool is read-only with respect to the checked endpoint.

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 core question, then the check list, then cost and safety. One long sentence enumerating checks is dense but each clause names a distinct verification, so little is wasted; the pricing sentence could be tightened.

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 compensates by listing what is verified, which implies the shape of the result, but it never says whether the response is a pass/fail per check or a single verdict. Cost, safety, and scope are otherwise fully covered for a one-parameter 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?

There is a single parameter with 100% schema description coverage ('Public https URL of the paid endpoint'), so the schema already carries its meaning. The description adds no format or constraint detail beyond it (e.g., https-only enforcement is only implied by 'Public https URL' in the schema). Baseline 3 applies when the schema does the work.

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 (a 402 conformance check of an x402/MPP paid endpoint) and frames the exact question it answers: can buyer agents' SDKs pay it? The enumerated checks (v2 requirements, malformed payment refusal, MPP challenge, live price) make it clearly distinct from siblings like check_offer, certify_offer, and lint_listing.

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 scopes applicability well: it applies to x402 v2 or MPP endpoints and works on unpaid requests only, with failed calls not charged. It does not, however, explicitly route the agent away from near-neighbors such as check_offer or certify_continuous, nor state prerequisites like the endpoint being publicly reachable over https.

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 say readOnly and openWorld; the description adds materially beyond that: cost ($1.00 USDC inside the call), billing policy (failed calls not charged), data scope (public Bazaar data only, joined with measured repeat demand), and a cost/latency proxy (up to 150 searches). These are exactly the operational facts an agent needs before spending 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?

Front-loaded with the motivating question and the mechanism, with pricing and failure policy in a tight closing sentence. Dense but every sentence carries information; the parenthetical weakness taxonomy is compact rather than padded.

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 does state what comes back — a ranking of unmet-demand tasks plus supporting evidence per item — which is enough for an agent to interpret results. It could say more about result shape or count, but nothing essential is missing 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 100% and the single parameter already documents the topic filter and its omission behavior, so the schema does the heavy lifting. The description adds no extra syntax, normalization, or scoping guidance for the topic argument; 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?

Opens with the buyer-agent question it answers, then states a precise verb+resource: runs up to 150 Bazaar searches phrased as buyer tasks and ranks unmet demand by explicit weakness criteria (no listings, few payers, thin descriptions, poor fit). This is clearly distinct from siblings like rank_check, buyer_panel, and weekly_insights.

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 framing question 'What x402 API should I build?' plus 'Phrased the way buyer agents phrase tasks' makes the use case clear and gives a strong signal for when this tool beats a plain rank/lint check. It stops short of explicitly naming an alternative sibling or excluding cases where simpler/cheaper tools would suffice.

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 says the tool charges $0.10 in USDC per call and returns a signed receipt, which is a financial side effect, while annotations declare readOnlyHint=true. That is a direct contradiction of the read-only annotation, so the transparency score is 1 despite otherwise rich disclosure of cost, receipt, and failed-call behavior.

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

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

The description is front-loaded with the core action and cost, then adds receipt, cause allocation, no-effect scope, payment method, and failed-call policy. Each sentence adds useful decision or behavioral context with little 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?

For a no-parameter funding tool with no output schema, the description covers cost, payment mechanism, return value, allocation, non-effects, and failure handling. An agent has enough context to invoke it correctly, aside from the annotation contradiction already flagged.

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, so the baseline is 4. The description appropriately adds no parameter semantics because none are 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 states a specific verb and resource: fund the x402 evidence commons via a $0.10 contribution. It clearly distinguishes this from analytical or certification sibling tools by explaining that it only supports the commons and never changes results, ranks, or certifications.

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 makes the usage context clear: optional contribution to keep evidence lookups and checks free, with explicit exclusions that it delivers nothing else and does not affect outcomes. It does not name sibling alternatives, but the when-not guidance is strong enough for confident selection.

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 readOnlyHint and openWorldHint annotations, the description discloses important behavior: one unpaid call performs validation, pricing is $0.005 USDC per call via x402 inside the tool call, and failed calls are not charged. It also describes the useful output artifacts: a fix for each problem, a fixed 402 ready to paste, and grading aligned with the weekly report card.

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 front-loaded with the user-facing question and the tool purpose, and the remaining clauses mostly earn their place by explaining validation scope, output, cost, and billing behavior. It is somewhat long and runs as a single dense sentence, but it is not padded with irrelevant material.

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 a complex validation task, the description does a good job explaining what is checked and what the agent receives, including fixes, a fixed 402, and grading context. It still leaves the exact response structure implicit, but the core behavioral and output expectations are present.

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 description coverage is 100%, and the single url parameter is already documented as the public https URL of the paid endpoint. The description does not add syntax, format, or validation detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: it checks an x402 endpoint for Bazaar indexing and validates the 402 PAYMENT-REQUIRED header, discovery metadata, schemas, description limits, and service name. This is much clearer than a tautology, though it does not explicitly distinguish itself from sibling tools such as conformance_check or certify_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 gives a clear usage condition: use when an agent needs to lint an x402 listing before its first settled payment. It does not name when-not-to-use cases or direct agents to alternative sibling tools, so it stops short of the top score.

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 say readOnly/openWorld; the description adds that significant context: $1.00 USDC via x402 charged inside the call, failed calls not billed, one payment with no renewal, free status polling, optional webhook push. It does not explain what the flagged result contains beyond 'a drop in your win rate', but the billing and failure semantics are exactly the kind of detail annotations cannot 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?

Front-loaded with the buyer's question, then scope, then pricing — good ordering with no idle sentences. Slight marketing register ('its real Bazaar rivals') costs a point but doesn't obscure meaning.

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 still tells the agent the deliverable is a win-rate verdict plus a drop flag, where results surface (status URL / webhook), and the billing model. What's missing is the shape of the initial result versus the change alert, but an agent can call this correctly as written.

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 tasks, resource and notify are already documented in-schema. The description only echoes the webhook ('an optional https webhook gets each result') and adds nothing about task phrasing or resource expectations beyond the schema. 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?

Names a concrete action and outcome: test your offer against Bazaar rivals via the Machine Buyer Panel, then re-run on model changes for 30 days and flag a win-rate drop. The recurring-monitoring scope implicitly separates it from one-off siblings like check_fair_offer and buyer_panel, but it never names an alternative explicitly.

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

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

The 'now + 30 days of re-runs' framing implies this is for ongoing monitoring rather than a single check, and the free status URL / webhook options are mentioned. However, there is no explicit 'use this instead of X when Y', so the agent must infer the choice 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 declare read-only and open-world behavior. The description adds important context beyond the annotations: the call costs $0.05 in USDC via x402, payment happens inside the tool call, and failed calls aren't charged. It does not describe output shape or pagination, but no output schema exists and the analytics content is summarized.

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 purpose is front-loaded in a concise opening question, followed by scope, use case, and pricing. The pledge sentence is slightly tangential to invocation but still brief and relevant to seller transparency; overall it is 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 read-only, two-parameter analytics tool with no output schema, the description covers what is analyzed, when to use it, cost, and failure charging. It could be stronger by clarifying the return format or how results relate to the `days` window, but the major invocation-relevant facts are present.

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 `address` and `days` are already documented in the input schema. The description reinforces that `address` is the seller pay-to address on Base and implies weekly cohort lookback, but adds no syntax or format detail 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 states a specific resource and analysis: payer analytics for an x402 seller from USDC payments on Base, including repeat buyers, one-off payers, revenue per payer, and weekly retention cohorts. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling `buyer_panel`, which sounds adjacent.

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 gives an explicit use condition: "Use when an agent needs payer analytics for a pay-to address." That is clear context, but it does not state when not to use it or name a specific alternative sibling such as `buyer_panel`, so the guidance stops short of full routing.

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?

Excellent disclosure of cost ($0.001 USDC on Base, paid inside the call), failure semantics (failed calls aren't charged), and return contents (signed receipt + wallet profile + next-tool hint). However, this describes a real transfer of USDC from the caller's wallet while annotations declare readOnlyHint=true, so an agent gating on that hint would wrongly assume zero economic 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?

Front-loaded with purpose and the core question it answers, followed by price and charge policy. Dense but every sentence carries information; the "what the Lab knows about your wallet and which tool to try next" clause is slightly rambling but still tells the agent what comes back.

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 return-value burden and does so: a signed receipt proving an end-to-end paid call, plus wallet intelligence and a next-tool recommendation. Nothing essential to deciding or calling 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?

The tool takes zero parameters, so there is no per-parameter semantics to explain; baseline is 4. The description correctly implies no inputs are needed beyond the wallet/x402 client configuration.

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: a ping/test-payment against an x402 API, priced at a fraction of a cent, returning a signed receipt. It clearly distinguishes itself from the surrounding certify_*, buyer_*, and spend_audit siblings as the cheap end-to-end wallet smoke test.

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 an agent needs a cheap test payment endpoint before buying anything bigger" gives an explicit trigger and an implicit ordering against the heavier siblings. It does not name which specific sibling to graduate to (certify_offer, buyer_drill, etc.), leaving that inference to the agent.

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

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

Annotations already declare read-only and open-world behavior, but the description adds important context: $0.01 USDC paid via x402 inside the call and failed calls are not charged. It also previews returned artifacts, including rank, competitor listings, and trailing signals.

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?

It front-loads the rank question and then compactly covers operation, outputs, free sample, price, and failure billing. The SEO/competitor sentence is slightly redundant, but the description remains efficient 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?

With no output schema, the description still explains what comes back and which signals are compared. The input schema and annotations cover parameters and safety, so an agent has enough information to select and 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 coverage is 100%, so task, resource, and network are already documented in the schema. The description reinforces 'your task' and 'your listed resource URL' but adds no syntax, format, or network-filter detail 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?

Names a specific operation: it runs the search a buyer agent would run and returns rank, competitor listings ahead, and trailing signals. The x402/Bazaar scope and the free sample endpoint separate it from generic analytics 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?

Implies use when checking Bazaar search rank, SEO, and competitor position, and gives a free sample endpoint plus per-call price as a decision aid. It does not explicitly state when not to use it or name sibling tools like rank_sample or lint_listing as 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful context beyond that: results are capped at the top three, ranking is simulated from a buyer agent's view, and the rank output is conditional on passing resource. It doesn't mention rate limits or caching, but for a read-only sampling tool that is a minor 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?

Two tight sentences, front-loaded with the free-tier nature and the result shape, then the sibling comparison. Nothing is wasted or 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?

Simple two-parameter read tool with full schema coverage and annotations that carry the safety profile; the description states the return shape (top three plus your rank) well enough that no output schema is needed. Nothing required 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?

Schema coverage is 100%, so the baseline is 3, and the description goes beyond it by explaining the conditional effect of the optional resource parameter (“your rank if you pass resource”). That behavioral linkage isn't expressed in the schema's plain URL description.

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

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

States a concrete verb and resource: it returns the top three Bazaar results a buyer agent would see for a task, plus your own rank when resource is supplied. It also names the sibling rank_check and explains how that paid tool differs, so the agent can separate the two without opening either 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?

"Free" plus "the paid rank_check adds the signals where you trail the listings ahead of you" clearly implies when to reach for this tool versus the paid alternative. It doesn't spell out explicit exclusions or rate limits, but the free-vs-paid split is a usable routing cue.

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 substantial behavior beyond the annotations, including the $0.05 USDC per-call price, x402 payment inside the call, and the fact that failed calls are not charged. It also describes the external fetch/check/sign mechanics and the contents of the attestation.

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 front-loaded with the purpose and then proceeds to mechanism, buyer verification, price, and failure policy without irrelevant material. The sentences are dense but each carries useful information for invoking or evaluating the tool.

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

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

For a paid external verification tool, the description covers the important mechanics, cost, and failure behavior. It does not explicitly state what the tool call returns to the caller, but the public verification URL and signed attestation concept make the outcome largely inferable.

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 both parameters are already documented. The description reinforces their roles, but it mostly repeats the same-host and sample/paid-route relationship rather than adding syntax or edge-case semantics 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 states a specific operation and resource: a signed attestation of an API's sample output, intended as a trust proof for an x402 seller. It is clear what the tool produces, but it does not explicitly distinguish itself from sibling tools such as rank_sample or lint_listing.

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 target scenario is implied clearly enough: an x402 seller wants a trust proof before buyers pay. However, the description gives no explicit when-to-use/when-not-to-use guidance and does not name sibling alternatives that an agent should consider 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?

The annotations already establish readOnlyHint and openWorldHint, and the description adds important behavioral context: the tool costs $1.00 in USDC via x402 inside the call and failed calls are not charged. It does not cover latency, rate limits, or auth/permission details, but for a read-only paid audit it discloses the key operational 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 dense and front-loads the statement content, then gives usage and pricing. The first sentence is long but each listed audit check is relevant to selecting the tool, and the remaining sentences are efficient.

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

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

For a comparatively complex audit tool with no output schema, the description lists the main returned findings and mentions the CSV of every payment. It is sufficient for an agent to understand the scope and call the tool correctly, though a little more detail on output shape could 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%, so the wallet and days parameters are already well documented in the input schema with defaults, bounds, and pattern constraints. The description does not add meaningful parameter semantics beyond referring to the wallet generally, so the baseline score of 3 applies.

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

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

The description clearly defines a specific resource and scope: a wallet statement/audit for an x402 buyer wallet on Base, including price checks, duplicate payments, seller changes, certification failures, and CSV output. It is highly specific, but it does not explicitly differentiate itself from similarly named sibling tools such as buyer_panel, buyer_drill, or payer_analytics.

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 gives a clear usage condition: 'Use when an agent or its operator needs to account for an x402 wallet's spending.' That is enough to know the primary scenario, but it does not state when not to use it or name alternative sibling tools for adjacent needs.

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 read-only and open-world nature; the description adds genuinely non-obvious behavior: a $0.25 USDC charge per call settled via x402 inside the call, and that failed calls are not charged. It also discloses data provenance (Bazaar discovery + Base settlements) and that figures are adjusted for sweeps. Missing only things like latency or freshness lag relative to 'latest' week.

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?

Opens with a framing question, then front-loads the payload description, then usage, then pricing — a sensible order with no filler. The middle sentence is dense with a long comma list but every item describes report contents an agent would want. Slightly heavier than needed but not wasteful.

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 single-optional-parameter read tool with no output schema, the description tells the agent what sections come back, where the data originates, and what it costs — enough to decide and call. It stops short of describing response shape or pagination/size, which matters somewhat for a report-style tool with 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?

Only one optional parameter and the schema documents it at 100% coverage ('ISO week; latest if omitted'), so the schema already carries the semantics including the pattern and default. The description adds nothing about the week argument. Baseline 3 is correct when the schema does all the work.

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 a specific resource (weekly x402 market/demand report) and enumerates its contents: repeat-use demand by category, demand gaps, movers, price bands, GET vs POST traction, with sources and sweep adjustment. That is far more specific than the title alone. It does not explicitly contrast itself with siblings such as demand_gaps or payer_analytics, though the enumeration implies this is the superset report.

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 a clear usage condition: 'Use when an agent needs x402 demand by category before choosing what to build or how to price it.' That gives the agent a decision context. No exclusions or named alternatives (e.g., when to prefer demand_gaps for a narrower answer) are given, so it stops short of a 5.

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