Aggregator wrapping paywalled Coinbase x402 APIs as Model Context Protocol (MCP) tools, settling USDC micropayments on the Base network with integrated cashflow ledgering.
Scored across 10 tools
Most tools have clear boundaries and the 'prefer over' guidance helps differentiate them. The main risk is the cluster of discovery tools (search_bazaar, list_discovered_apis, list_verified_apis, quote_route), plus the two paid call tools, which could cause misselection without careful reading.
Overall naming is snake_case and verb-first, which is predictable. It is slightly inconsistent because read operations mix get_ and list_, and route_and_call breaks the verb_noun pattern.
10 tools is a well-scoped set for a dispatcher server: execution, discovery/routing, stats, paywall, and financial monitoring are all represented. Each tool maps to a distinct workflow step without feeling like filler.
The core dispatch lifecycle is covered: discover, search, quote, call, route, monitor stats, and review financials. There are minor gaps such as no paywall configuration or detailed single-API metadata endpoint, but agents can work around these.
PAID inbound $0.01 USDC, then pay and call one specific Bazaar resource by tool_name or full URL (Treasury settles upstream). Prefer over route_and_call when you already know which API to hit. Do not use for open-ended tasks — use route_and_call or quote_route first. Discover names via search_bazaar or list_discovered_apis.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Optional JSON body | |
| query | No | Optional query parameters | |
| tool_name_or_url | Yes | Registered tool_name or full upstream resource URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It clearly discloses the paid nature ($0.01 USDC inbound, Treasury settlement upstream) and that this is an execution call to an external resource. It does not detail possible side effects or return behavior, but the cost factor and direct-call semantics are meaningful beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences packed with essential information: cost, action, differentiation, and discovery path. No filler or redundancy; key constraints are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid resource-calling tool with no annotations and no output schema, the description covers selection, invocation, cost, and discovery. It could mention error/refund behavior or idempotency, but the provided context is sufficient for an agent to decide and call correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description repeats that tool_name_or_url can be a registered tool_name or full URL, which is already in the schema, and adds no further semantics for body or query. 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?
States a clear action (pay for and call a specific Bazaar resource) with explicit input modes (tool_name or full URL). It distinguishes itself from route_and_call by noting when it is preferred, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (when you already know which API to hit), when-not-to-use (open-ended tasks), and names alternatives (route_and_call, quote_route). Also tells the user how to discover valid names via search_bazaar or list_discovered_apis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Show success-rate/latency history for paid dispatcher calls. Prefer over list_verified_apis when you need raw stats (omit url for all). Prefer over get_cashflow/get_pnl — those are money ledgers, not reliability metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional upstream resource URL to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds useful context (FREE, history of stats, raw metrics rather than ledger data), but it does not mention rate limits, authentication, output shape, or whether the data is near-real-time. For a read-only stats tool this is acceptable but not rich.
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 compact and front-loaded: it states the cost, the core purpose, and then routes to alternatives. Every sentence contributes either purpose or usage guidance, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description is nearly complete. It explains what the call returns conceptually (success-rate/latency history) and how to get all vs. one resource. It does not spell out response fields, but the absence of an output schema makes that less critical here.
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 only parameter, url, is already fully documented in the schema (100% coverage). The description adds extra semantics by saying 'omit url for all,' which clarifies the default behavior 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 uses a specific verb and object: 'Show success-rate/latency history for paid dispatcher calls.' It explicitly distinguishes itself from list_verified_apis, get_cashflow, and get_pnl, so an agent can infer its unique role among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing guidance: 'Prefer over list_verified_apis when you need raw stats' and 'Prefer over get_cashflow/get_pnl — those are money ledgers, not reliability metrics.' This tells the agent both when to use the tool and which alternatives cover the other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE (operator). List recent ledger rows (in/out/markup). Prefer over get_pnl when you need individual settlements; prefer over get_paywall_status when auditing history, not current prices.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return (default 25) | |
| direction | No | Optional filter by ledger direction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It communicates read-only intent ('List') and a 'recent' temporal scope, but it does not clarify ordering, pagination, or the meaning of 'FREE (operator)'. These omissions leave some behavioral uncertainty, though the core listing behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main action is front-loaded, followed immediately by usage guidance. It earns a top score for minimalism and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list tool, the description covers purpose, parameter hints, and usage differentiation. It doesn't explicitly describe the return format or clarify what 'FREE (operator)' means, but given the low complexity and complete schema, the essential information for correctly invoking the tool 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%, and both parameters already have clear descriptions in the input schema. The description adds only a small amount of nuance by mapping the in/out/markup values to ledger directions, but it does not materially exceed what the schema already 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 uses a specific verb ('List') and resource ('recent ledger rows') and immediately clarifies the optional in/out/markup directions. It also distinguishes the tool from siblings by naming get_pnl and get_paywall_status with the specific scenarios they serve, leaving no ambiguity about what this tool does.
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?
Explicit routing guidance is provided: 'Prefer over get_pnl when you need individual settlements; prefer over get_paywall_status when auditing history, not current prices.' This directly tells the agent when to choose this tool over alternatives, which is exactly what the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Show inbound paywall config (enabled, price, network, Merchant payTo). Prefer over get_cashflow/get_pnl when checking what callers must pay before tools run — not historical money movement.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It clearly implies a read-only operation ('Show') and highlights the 'FREE' nature, which is relevant for a paywall-related tool. It doesn't discuss auth or failure modes, but for a zero-parameter read-only config check, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The key qualifier 'FREE' and the resource are front-loaded, and the alternative-routing guidance is compact and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool with no output schema, the description fully covers what the tool returns, when to use it, and how it differs from relevant siblings. Nothing essential 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 has zero parameters, so the baseline is 4. There is no parameter information needed beyond the empty schema, and the description appropriately focuses on output semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and resource ('inbound paywall config'), and lists concrete fields (enabled, price, network, Merchant payTo). It also explicitly distinguishes itself from siblings by clarifying it is not about historical money movement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to prefer this tool ('when checking what callers must pay before tools run') and names the alternatives to avoid (get_cashflow/get_pnl) with the reason ('not historical money movement'). This gives clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE (operator). Summarize revenue, COGS, markup, and gross profit. Prefer over get_cashflow when you want totals, not per-entry rows. Prefer over get_api_stats — this is money PnL, not latency/success stats.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional ISO timestamp — only include entries at/after this time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It clearly establishes that the tool returns summarized aggregate figures rather than line-item rows, and clarifies that 'FREE (operator)' applies. It could mention error behavior or what happens with empty results, but its summary semantics make the main behavioral expectation clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the first states what the tool does, the second and third route the agent away from misleading alternatives. No filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter summary tool with no output schema, the description gives enough to call it correctly: the aggregated metrics expected, the operator-level access note, and clear sibling distinctions. A minor gap is lack of detail about return formatting or edge cases, but the tool is simple enough that this is not a serious omission.
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 only one optional parameter, and the schema already describes 'since' with 100% coverage. The description adds no parameter-specific detail, but the schema fully covers the meaning, 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 opens with a specific verb—'Summarize'—and names the exact resource and metrics: revenue, COGS, markup, and gross profit. It also explicitly distinguishes itself from get_cashflow and get_api_stats, making its purpose unambiguous even among nine 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?
It provides explicit selection guidance: prefer this over get_cashflow when totals are needed instead of per-entry rows, and prefer this over get_api_stats because it reports money PnL, not latency/success stats. This tells an agent exactly when to choose this tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Dump the in-memory discovery cache (Base, ≤ MAX_PRICE_USD) — no new Bazaar search. Prefer over search_bazaar/quote_route when you only need what is already warmed. Prefer over list_verified_apis when you want every cached API, not only Verified. Call search_bazaar first if the cache is empty.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool performs no new Bazaar search, is free, operates on the in-memory cache, has constraints, and may be empty. It could go further by describing the output shape or side effects, but 'dump' plus the cache semantics make the read-only behavior clear.
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 but well-structured: it front-loads the core behavior, then gives precise sibling comparisons and a fallback action. Every sentence adds value and there is no redundant restatement of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers the essential context: what data is returned, what constraints apply, how it differs from siblings, and what to do when the cache is empty. It does not define 'Base' or 'MAX_PRICE_USD', but these appear to be domain constants, and the guidance is sufficiently actionable.
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 empty schema is fully covered. The description adds useful context about the fixed filters applied to the returned cache entries (Base, ≤ MAX_PRICE_USD), which the schema cannot express. This is solid for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool dumps the in-memory discovery cache with explicit constraints (Base, ≤ MAX_PRICE_USD), and distinguishes it from search_bazaar, quote_route, and list_verified_apis. The verb 'dump' and resource 'in-memory discovery cache' make the action and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: prefer this over search_bazaar/quote_route when only warmed cache data is needed, prefer over list_verified_apis when non-Verified cached APIs are desired, and call search_bazaar first if the cache is empty. This fully routes the agent among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. List only APIs that currently qualify for the Verified routing tier. Prefer over list_discovered_apis when you want reliability-filtered endpoints, not the full cache. Prefer over get_api_stats when you want the pass/fail Verified set, not per-URL metrics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that the tool is FREE, filters by current Verified qualification, and excludes full-cache and per-URL metric outputs. It does not mention auth, rate limits, or response shape, but the read-only listing behavior is adequately conveyed for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the first states scope and cost, the second and third route to alternatives. Key information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema list tool, the description is complete. It defines what is returned, when to use it, and how it differs from the relevant siblings. No additional context is needed to invoke 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 zero parameters, the input schema is already complete and there is nothing for the description to add about parameter meaning. The baseline of 4 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 uses a specific verb and resource: 'List only APIs that currently qualify for the Verified routing tier.' It clearly differentiates from sibling tools by stating what it is not: not the full cache and not per-URL metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer over list_discovered_apis' and 'Prefer over get_api_stats', and provides the conditions that select this tool: wanting reliability-filtered endpoints or a pass/fail Verified set. This gives an agent direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Rank Bazaar APIs for a natural-language task without paying. Prefer over search_bazaar when you need ranked candidates (economy=cheapest; verified=reliability score). Prefer over list_discovered_apis when matching a task, not dumping the cache. Use route_and_call next to execute; do not use this to pay.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language task, for example "weather in Boston" or "token balance" | |
| tier | No | Routing tier: "economy" = cheapest first (V3); "verified" = reliability-scored APIs with enough successful history (V4) | |
| limit | No | Max ranked candidates to return (default 10) | |
| max_price_usd | No | Optional per-call budget (clamped to MAX_PRICE_USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It clearly discloses that the tool is FREE, does not charge, only ranks candidates rather than executing, and uses tier-specific behavior (economy=cheapest, verified=reliability score). This is strong behavioral disclosure beyond what the schema alone offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no wasted words. The most important behavioral fact 'FREE' is front-loaded, followed by sibling differentiators and the critical instruction to use route_and_call for execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 4-parameter schema with full descriptions and no output schema, the description is complete for selection and invocation. It covers what the tool does, when to prefer it over alternatives, what tier values mean, that it costs nothing, and what to use next for execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the enum semantics for tier ('economy' = cheapest, 'verified' = reliability-scored), which goes beyond the schema's plain labels. Other parameters are already well documented by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Rank Bazaar APIs for a natural-language task', and adds the key qualifier 'without paying'. It also explicitly distinguishes itself from search_bazaar and list_discovered_apis, so an agent can tell siblings apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing guidance: 'Prefer over search_bazaar when you need ranked candidates' and 'Prefer over list_discovered_apis when matching a task, not dumping the cache.' It also names route_and_call as the next execution step and warns 'do not use this to pay', leaving no ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID inbound $0.01 USDC to Merchant, then auto-pick and call the best Base x402 API for a natural-language task (Treasury pays upstream; failover on errors). Prefer over call_x402_api when you have a task but no specific tool_name/URL. Prefer over quote_route when you want data now, not a dry-run ranking. economy=cheapest; verified=reliability-scored.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Optional JSON body overrides | |
| task | Yes | Natural-language task, for example "current weather for Boston" | |
| tier | No | Routing tier: "economy" = cheapest first (V3); "verified" = reliability-scored APIs with enough successful history (V4) | |
| query | No | Optional query overrides; defaults to the listing example query | |
| max_attempts | No | How many candidates to try on failure (default 3) | |
| max_price_usd | No | Optional budget for this route (clamped to MAX_PRICE_USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It unambiguously states the operation is PAID, involves a $0.01 USDC payment to Merchant, that Treasury pays upstream, and that failover on errors occurs. These are important non-obvious behaviors that an agent must know. It could go slightly further by describing return behavior or side effects beyond payment, but the key traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero wasted words. The core action and cost implication are front-loaded in the first sentence, usage guidance in the second, and tier clarification in the third. Each sentence earns its place and the structure makes the tool's purpose immediately scannable.
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, routing, multi-parameter tool with no output schema, the description covers the essential context: payment, auto-picking, failover, tier semantics, and budget implications. It also names sibling tools for boundary conditions. The minor gap is that it does not describe the shape of the returned result or how the agent should interpret the upstream API's response, which is relevant for a 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?
Schema description coverage is 100%, so the baseline is 3. The schema already documents all six parameters, including tier enum values and max_attempts defaults. The description restates tier semantics ('economy=cheapest; verified=reliability-scored') but mostly duplicates schema information. It adds no substantial new meaning beyond what the input schema already provides.
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 opens with a specific verb and resource: 'PAID inbound $0.01 USDC to Merchant, then auto-pick and call the best Base x402 API for a natural-language task.' It clearly differentiates from siblings by explicitly naming call_x402_api and quote_route as alternatives to prefer over or not prefer. This is a clear, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Prefer over call_x402_api when you have a task but no specific tool_name/URL' and 'Prefer over quote_route when you want data now, not a dry-run ranking.' It also explains the tier choice semantics ('economy=cheapest; verified=reliability-scored'), giving clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Keyword/semantic search of the public Coinbase x402 Bazaar (Base, ≤ MAX_PRICE_USD) and cache matches. Prefer over quote_route when browsing by query text, not ranked task routing. Prefer over list_discovered_apis when refreshing from the live catalog. Follow with call_x402_api (known URL/tool_name) or route_and_call (task).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 10) | |
| query | Yes | Semantic or text search query, for example weather or token balance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds meaningful context: the search is FREE, scoped to the public Bazaar, capped by MAX_PRICE_USD, and it caches matches. It does not describe return shape or freshness, but the caching side effect is explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense, purposeful sentences with no filler. It front-loads the free/public search scope, then gives routing guidance and follow-up actions. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for correct selection and invocation given only two parameters and a fully documented schema. The main gap is that no output schema exists and the description does not describe the result structure, though 'cache matches' implies a list of matches.
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 both query and limit thoroughly. The description adds context that query is 'keyword/semantic', but does not materially improve on the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Keyword/semantic search of the public Coinbase x402 Bazaar (Base, ≤ MAX_PRICE_USD)'. It also names the exact siblings it should not be confused with, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to prefer this tool over quote_route when browsing by query text rather than ranked task routing, and over list_discovered_apis when refreshing from the live catalog. It even tells the agent what to do next with call_x402_api or route_and_call.
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.
get_mbta_predictionsx402_agent402_tools_api_crypto_price_11x402_agent402_tools_api_weather_alerts_9x402_ai_data_marketplace_1042299154756_us_centra_3x402_api_exa_ai_search_35x402_api_onesource_io_api_chain_allowance_34x402_api_onesource_io_api_chain_block_number_15x402_api_onesource_io_api_chain_block_number_19x402_api_onesource_io_api_chain_call_33x402_api_onesource_io_api_chain_chain_id_27x402_api_onesource_io_api_chain_code_address_32x402_api_onesource_io_api_chain_contract_addres_20x402_api_onesource_io_api_chain_ens_input_14x402_api_onesource_io_api_chain_erc1155_balance_28x402_api_onesource_io_api_chain_erc20_balance_13x402_api_onesource_io_api_chain_erc20_transfers_22x402_api_onesource_io_api_chain_erc721_tokens_21x402_api_onesource_io_api_chain_estimate_gas_29x402_api_onesource_io_api_chain_events_31x402_api_onesource_io_api_chain_live_balance_16x402_api_onesource_io_api_chain_network_info_30x402_api_onesource_io_api_chain_nft_metadata_23x402_api_onesource_io_api_chain_nft_owner_26x402_api_onesource_io_api_chain_nonce_address_18x402_api_onesource_io_api_chain_pending_38x402_api_onesource_io_api_chain_proxy_address_36x402_api_onesource_io_api_chain_receipt_hash_25x402_api_onesource_io_api_chain_storage_37x402_api_onesource_io_api_chain_total_supply_24x402_api_onesource_io_api_chain_tx_hash_17x402_api_polyform_org_v1_weather_current_8x402_api_polyform_org_v1_weather_metar_7x402_api_x402node_dev_maps_weather_10x402_apiacre_com_v1_data_current_weather_4x402_apiacre_com_v1_data_us_weather_forecast_2x402_app_tenna_ai_api_x402_tenna_observatory_rou_12x402_bazaar_gateway_vercel_app_api_weather_5x402_fanfare_run_nfl_standings_1x402_seoul_weather_402_fly_dev_weather_seoul_cur_6x402_stableenrich_dev_api_exa_search_39x402_x402_factory_com_v1_calendar_sports_nfl_0x402_x402_ottoai_services_weather_1x402_x402tap_com_api_weather_0x402_fanfare_run_nfl_standings_1x402_x402_factory_com_v1_calendar_sports_nfl_0x402_api_onesource_io_api_chain_contract_addres_20x402_api_onesource_io_api_chain_contract_addres_21x402_api_onesource_io_api_chain_erc1155_balance_28x402_api_onesource_io_api_chain_erc1155_balance_29x402_api_onesource_io_api_chain_erc721_tokens_20x402_api_onesource_io_api_chain_erc721_tokens_21x402_api_onesource_io_api_chain_estimate_gas_28x402_api_onesource_io_api_chain_estimate_gas_29x402_api_onesource_io_api_chain_events_30x402_api_onesource_io_api_chain_events_31x402_api_onesource_io_api_chain_network_info_30x402_api_onesource_io_api_chain_network_info_31x402_api_onesource_io_api_chain_nft_metadata_23x402_api_onesource_io_api_chain_nft_metadata_24x402_api_onesource_io_api_chain_total_supply_23x402_api_onesource_io_api_chain_total_supply_24x402_agent_commerce_factory_jm_austriaeast_cloud_8x402_agent_massive_com_v2_reference_news_11x402_agent402_tools_api_crypto_news_9x402_agent402_tools_api_images_to_pdf_8x402_agentdatum_com_api_v1_d_news_headlines_1x402_agentdatum_com_api_v1_d_news_search_0x402_agents_machina_gg_world_cup_v1_get_schedule_9x402_agents_machina_gg_world_cup_v1_get_standing_8x402_agentworld_me_api_agentworld_sports_apex_as_5x402_agentworld_me_api_agentworld_sports_gridiro_7x402_agentworld_me_api_agentworld_sports_hardwoo_6x402_api_24klabs_ai_api_v1_translate_0x402_api_agentfeeds_jp_v1_reg_events_headlines_7x402_api_agentstools_dev_crypto_news_5x402_api_agentstools_dev_search_news_2x402_api_agentstools_dev_sports_game_3x402_api_agentstools_dev_sports_schedule_0x402_api_agentstools_dev_sports_scores_1x402_api_agentstools_dev_sports_standings_4x402_api_agentstools_dev_sports_team_2x402_api_aidress_ai_pay_agent_ottoai_crypto_news_8x402_api_delx_ai_api_v1_x402_news_search_11x402_api_interzoid_com_translatetoany_6x402_api_memoryapi_org_x402_translate_7x402_api_onesource_io_api_chain_call_32x402_api_onesource_io_api_chain_call_33x402_api_onesource_io_api_chain_code_address_32x402_api_onesource_io_api_chain_code_address_33x402_api_onesource_io_api_chain_events_30x402_api_onesource_io_api_chain_events_31x402_api_onesource_io_api_chain_network_info_30x402_api_onesource_io_api_chain_network_info_31x402_api_onesource_io_api_chain_nft_metadata_23x402_api_onesource_io_api_chain_nft_metadata_24x402_api_onesource_io_api_chain_total_supply_23x402_api_onesource_io_api_chain_total_supply_24x402_api_predictionmarketdata_io_market_news_6x402_api_relaystation_ai_v1_pdf_images_9x402_api_x402node_dev_search_news_13x402_bazaar_gateway_vercel_app_api_translate_3x402_blockrun_ai_api_v1_surf_search_news_14x402_finance_toonhaus_dev_api_market_news_15x402_gdelt_use_x402atlas_com_search_6x402_loonie_toll_onrender_com_title_10x402_loonie_toll_onrender_com_translate_4x402_netintel_dev_translate_short_2x402_news_apitoll_cloud_v1_cointelegraph_news_4x402_payload402_edgebytenet_workers_dev_translat_1x402_quartermaster_surewhynot_app_v1_translate_5x402_rest_coincap_io_v3_agentfriendly_news_top_12x402_toolcall_click_t_news_search_13x402_www_x402financialdata_com_news_ticker_3x402_x402_ottoai_services_equity_news_10x402_x402_professorsausages_com_news_headlines_9x402_x402_shizu_me_news_7x402_x402_yodeler_xyz_v1_news_12x402_agent_commerce_factory_jm_austriaeast_cloud_8x402_agent_massive_com_v2_reference_news_11x402_agent402_tools_api_crypto_news_9x402_agent402_tools_api_images_to_pdf_8x402_agentdatum_com_api_v1_d_news_headlines_1x402_agentdatum_com_api_v1_d_news_search_0x402_agents_machina_gg_world_cup_v1_get_schedule_9x402_agents_machina_gg_world_cup_v1_get_standing_8x402_agentworld_me_api_agentworld_sports_apex_as_5x402_agentworld_me_api_agentworld_sports_gridiro_7x402_agentworld_me_api_agentworld_sports_hardwoo_6x402_api_24klabs_ai_api_v1_translate_0x402_api_agentfeeds_jp_v1_reg_events_headlines_7x402_api_agentstools_dev_crypto_news_5x402_api_agentstools_dev_search_news_2x402_api_agentstools_dev_sports_game_3x402_api_agentstools_dev_sports_schedule_0x402_api_agentstools_dev_sports_scores_1x402_api_agentstools_dev_sports_standings_4x402_api_agentstools_dev_sports_team_2x402_api_aidress_ai_pay_agent_ottoai_crypto_news_8x402_api_delx_ai_api_v1_x402_news_search_11x402_api_interzoid_com_translatetoany_6x402_api_memoryapi_org_x402_translate_7x402_api_predictionmarketdata_io_market_news_6x402_api_relaystation_ai_v1_pdf_images_9x402_api_x402node_dev_search_news_13x402_bazaar_gateway_vercel_app_api_translate_3x402_blockrun_ai_api_v1_surf_search_news_14x402_finance_toonhaus_dev_api_market_news_15x402_gdelt_use_x402atlas_com_search_6x402_loonie_toll_onrender_com_title_10x402_loonie_toll_onrender_com_translate_4x402_netintel_dev_translate_short_2x402_news_apitoll_cloud_v1_cointelegraph_news_4x402_payload402_edgebytenet_workers_dev_translat_1x402_quartermaster_surewhynot_app_v1_translate_5x402_rest_coincap_io_v3_agentfriendly_news_top_12x402_toolcall_click_t_news_search_13x402_www_x402financialdata_com_news_ticker_3x402_x402_ottoai_services_equity_news_10x402_x402_professorsausages_com_news_headlines_9x402_x402_shizu_me_news_7x402_x402_yodeler_xyz_v1_news_12call_x402_apiget_api_statsget_cashflowget_mbta_predictionsget_paywall_statusget_pnllist_discovered_apislist_verified_apisquote_routeroute_and_callsearch_bazaarx402_agent402_tools_api_crypto_price_11x402_agent402_tools_api_weather_alerts_9x402_ai_data_marketplace_1042299154756_us_centra_3x402_api_exa_ai_search_35x402_api_onesource_io_api_chain_allowance_34x402_api_onesource_io_api_chain_block_number_15x402_api_onesource_io_api_chain_block_number_19x402_api_onesource_io_api_chain_call_32x402_api_onesource_io_api_chain_chain_id_27x402_api_onesource_io_api_chain_code_address_33x402_api_onesource_io_api_chain_contract_addres_21x402_api_onesource_io_api_chain_ens_input_14x402_api_onesource_io_api_chain_erc1155_balance_29x402_api_onesource_io_api_chain_erc20_balance_13x402_api_onesource_io_api_chain_erc20_transfers_22x402_api_onesource_io_api_chain_erc721_tokens_20x402_api_onesource_io_api_chain_estimate_gas_28x402_api_onesource_io_api_chain_events_31x402_api_onesource_io_api_chain_live_balance_16x402_api_onesource_io_api_chain_network_info_30x402_api_onesource_io_api_chain_nft_metadata_23x402_api_onesource_io_api_chain_nft_owner_26x402_api_onesource_io_api_chain_nonce_address_18x402_api_onesource_io_api_chain_pending_38x402_api_onesource_io_api_chain_proxy_address_36x402_api_onesource_io_api_chain_receipt_hash_25x402_api_onesource_io_api_chain_storage_37x402_api_onesource_io_api_chain_total_supply_24x402_api_onesource_io_api_chain_tx_hash_17x402_api_polyform_org_v1_weather_current_8x402_api_polyform_org_v1_weather_metar_7x402_api_x402node_dev_maps_weather_10x402_apiacre_com_v1_data_current_weather_4x402_apiacre_com_v1_data_us_weather_forecast_2x402_app_tenna_ai_api_x402_tenna_observatory_rou_12x402_bazaar_gateway_vercel_app_api_weather_5x402_seoul_weather_402_fly_dev_weather_seoul_cur_6x402_stableenrich_dev_api_exa_search_39x402_x402_ottoai_services_weather_1x402_x402tap_com_api_weather_0
Add one secure layer between your agents and this server.