Get your x402 API found and bought: lint, Bazaar rank, buyer panel, demand gaps. Paid in USDC.
Scored across 9 tools
Each tool maps to a distinct seller concern: demand discovery, listing lint, rank, payer analytics, A/B conversion, trust attestation, test payment and market report. The only real overlaps are rank_check vs rank_sample (free vs paid variant, clarified in the description) and demand_gaps vs weekly_insights (targeted gap search vs broad weekly market report), which a careful agent can separate.
All names are snake_case and readable, with a clear resource/action hint. The set mixes verb-first (lint_listing, rank_check) and noun-phrase (buyer_panel, demand_gaps, weekly_insights) conventions, so not a uniform verb_noun pattern, but the deviation is minor and never confusing.
Nine tools is well within the ideal 3-15 range, and each one covers a distinct stage of the x402 seller lifecycle rather than padding the surface. No redundant or trivial entries.
The surface covers demand research, listing validation, ranking, buyer analytics, conversion testing, trust proof and a test payment, which is strong end-to-end seller coverage. Gaps are minor, e.g. no explicit price-recommendation or listing-update/republish operation after lint fixes.
Will buyer agents choose my x402 API? The Machine Buyer Panel is an A/B conversion test: buyer-agent models choose between your offer and its real Bazaar rivals for up to three tasks, across buyer personas and list positions. Returns your win rate with confidence intervals, why you lost, and up to three truthful edits tested on the same trials. Price: $1.00 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to three tasks, as a buyer agent would phrase them | |
| resource | Yes | Your resource URL |
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.
What x402 API should I build? The demand gap finder runs up to 150 Bazaar searches phrased the way buyer agents phrase tasks and ranks the unmet demand: tasks whose top results are weak (no listings, few payers, thin descriptions or a poor fit), with the evidence for each. Public Bazaar data only, joined with measured repeat demand per category. Price: $1.00 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | A topic or category to search around; every category if omitted |
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.
Why isn't my x402 API in the Bazaar? Listing lint checks an x402 endpoint for Bazaar indexing: one unpaid call validates its 402 PAYMENT-REQUIRED header, discovery metadata, input and output schemas, description limits and service name against the indexing rules, with a fix for each problem. Use when an agent needs to lint an x402 listing before its first settled payment. Price: $0.005 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public https URL of the paid endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses crucial behavior an agent could not infer: it is a paid call ($0.005 USDC via x402 inside the tool call), it makes one unpaid call to the target endpoint, failed calls are not charged, and it returns a fix per problem. Payment and billing semantics are exactly the kind of context annotations do not 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?
It opens with the user's motivating question, then front-loads what is checked, then when to use it, then pricing. Every sentence adds distinct information (scope, trigger, cost, failure handling) with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers trigger, cost, and failure behavior, and hints at return content ('a fix for each problem'). A slightly clearer statement of what the response contains would close the only remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter with 100% schema description coverage ('Public https URL of the paid endpoint'), so the schema already carries the meaning. The description adds only the framing that the URL is an x402 endpoint to be linted, which is mild value on top of the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (checks/validates) and resource (an x402 endpoint's Bazaar listing) and enumerates exactly what is validated: 402 PAYMENT-REQUIRED header, discovery metadata, input/output schemas, description limits, and service name. This is clearly distinct from the analytics/rank siblings (buyer_panel, rank_check, demand_gaps).
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 concrete trigger: 'Use when an agent needs to lint an x402 listing before its first settled payment.' That is a clear context for invocation. It does not, however, name an alternative tool or state when not to use it, so it falls short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who pays my x402 API, and do they come back? Customer analytics for an x402 seller from USDC payments on Base: repeat buyers versus one-off and sweep-like payers, revenue per payer and weekly retention cohorts. Use when an agent needs payer analytics for a pay-to address. Agoranome pledges 15% of settled revenue to a cause, verifiable at /impact/ledger. Price: $0.05 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days to look back | |
| address | Yes | Seller pay-to address on Base |
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.
x402 ping and test payment: can my wallet pay an x402 API? Pay a fraction of a cent in USDC on Base and get a signed receipt back, proof that your wallet and x402 client complete a real paid call end to end. Use when an agent needs a cheap test payment endpoint before buying anything bigger. Price: $0.001 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses the exact cost ($0.001 USDC per call on Base), that payment happens inside the tool call via x402, that a signed receipt is returned, and that failed calls aren't charged — real behavioral value an agent needs before spending. It does not cover latency, rate limits, or what a failed call looks like; readOnlyHint arguably understates that funds move, though no data is modified, so this is a tension rather than a 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?
Front-loaded with what it does and the price, with the use case close behind. Some phrasing is promotional filler ('proof that your wallet and x402 client complete a real paid call end to end'), which adds emphasis but not new decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no parameters, so the description carries the burden — and it does describe the return (a signed receipt) plus the billing failure behavior. Remaining ambiguity (receipt format, chain/asset edge cases beyond Base) is minor for a test-ping 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?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly implies a parameterless ping (payment is handled by the x402 client, not by caller-supplied arguments).
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 ('x402 ping and test payment') and immediately explains the outcome: pay $0.001 USDC on Base, receive a signed receipt proving the wallet and client complete a real paid call. This is clearly distinguishable from data-oriented siblings like payer_analytics or signed_sample.
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 a clear triggering condition and implies sequencing relative to larger purchases. It does not name a specific sibling as the alternative or state when-not to use it, 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.
Where does my x402 API rank in Bazaar search? Rank check runs the search a buyer agent would run for your task and returns your rank, the competitor listings ahead of you, and the signals where you trail them (payers, calls, description, output example, schema, price). Search rank, SEO and competitor analysis for x402 listings. A three-result sample is free at /v1/seller/rank/sample. Price: $0.01 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What a buyer agent is searching for | |
| network | No | Optional CAIP-2 network filter | |
| resource | Yes | Your listed resource URL |
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.
Free: the top three Bazaar results a buyer agent would see for a task, and your rank if you pass resource. The paid rank_check adds the signals where you trail the listings ahead of you.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What a buyer agent is searching for | |
| resource | No | Your listed resource URL |
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.
Trust proof for an x402 seller: a signed attestation of your API's sample output, so buyer agents can check it before paying. Agoranome fetches a free sample from your endpoint's host, checks that your paid route on the same host answers with an x402 offer, and signs an attestation of what it saw and when: the sample's SHA-256 and body, and the offer's price, network and pay-to. Buyers check it at a public URL. Price: $0.05 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| sample | Yes | Public https URL that returns a sample output without payment | |
| resource | Yes | Your paid x402 endpoint, on the same host as the sample |
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.
What are agents buying on x402? A weekly x402 market data and demand report from Bazaar discovery and Base settlements: repeat-use demand by category, demand gaps, movers, price bands and GET vs POST traction, adjusted for sweeps, with cited sources. Use when an agent needs x402 demand by category before choosing what to build or how to price it. Price: $0.25 in USDC per call, paid with x402 inside the tool call. Failed calls aren't charged.
| Name | Required | Description | Default |
|---|---|---|---|
| week | No | ISO week; latest if omitted |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
buyer_paneldemand_gapslint_listingpayer_analyticspingrank_checkrank_samplesigned_sampleweekly_insightsPaid API bazaar for agents: seals, audits, wallet intel, codec ops. x402.
Onchain DeFi intelligence API for Base, payable per call with x402 (USDC). Live MCP tools: get_bot_status (Telegram bot health), get_market_stats (market snapshot), get_onchain_sales (proven revenue from live x402 routes). Built for agents that need verifiable onchain data — whale flow, signals, and sales evidence at $0.003/call.
Find live x402 APIs for any task (0.005 USDC, no match no charge); free x402 readiness checks.
Pay-per-call ($0.005-$0.03 USDC) market, on-chain, and prediction-market data API for AI agents and trading bots via x402 — no signup, no API key. Remote MCP server, 28 tools: token security (honeypot/liquidity/counterfeit checks), Hyperliquid oracle-gap risk, kimchi premium, funding APR, DEX slippage, Polymarket arbitrage/liquidity audits, Hyperliquid HIP-4 odds.
Add one secure layer between your agents and this server.
