MCPFax Bazaar Intelligence

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

Beyond the readOnly and idempotent annotations, the description discloses conditional logic: momentum only applies 'where a real prior window exists' and the payer-quality component 'is applied only when wallet scan coverage supports it.' It also states the price of $0.02 per successful call, providing operational context not available elsewhere.

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, each earning its place: it opens with a crisp label, explains the comparison logic and conditional components, gives an actionable use case, and closes with pricing. No redundant phrases or schema 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 single-parameter, read-only tool with no output schema, the description covers the core decision-relevant elements: data compared, conditional behavior, use case, and cost. The lack of an explicit return format is a minor gap but not critical given the simple nature of the tool and the clarity of the purpose.

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

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

The input schema already describes the only parameter as 'Optional deterministic category filter' with 100% coverage and an enum. The description adds no additional meaning about the parameter, so the baseline of 3 is appropriate since the schema carries the semantic load.

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 'Unmet-demand finder' and explicitly states the tool 'compares observed USDC spend against how many sellers actually serve each category' – a specific verb and resource. This clearly distinguishes it from sibling tools like x402_seller_rank or x402_top_movers by identifying the unmet-demand angle for build decisions.

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

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

The description provides a clear use case: 'Use this to decide what to build — categories with high spend and few suppliers are the gaps.' While it does not explicitly name alternatives or exclusions, the context of comparing spend vs suppliers makes its unique role evident. This meets the 'clear context, no exclusions' level.

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 key behavioral traits not covered by annotations: it reports the real observation window, applies concentration adjustment conditionally based on scan coverage, and states a price per successful call. This is valuable context for an agent deciding whether to invoke it.

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 efficient, with each sentence serving a purpose: core content, behavioral note, differentiation from free alternative, and pricing. It is well-structured and front-loaded.

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

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

Given no output schema, the description lists the covered metrics and notes the observation window and adjustment logic. It could clarify the exact output format, but for selection purposes it is sufficient. The inclusion of price and alternative tool enhances 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?

The tool has zero parameters, so the schema provides no parameter definitions. The description compensates by explaining what the report contains, but there are no parameter-level semantics to clarify. Baseline for 0 params is 4.

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 provides a daily state of the x402 agent economy with specific metrics (USDC inflow, seller ranking, category demand, growth, coverage). It distinguishes itself from the free market_digest alternative by emphasizing derived figures over changes, and the content differentiates from specialized sibling tools.

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

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

The description explicitly compares with market_digest, advising to buy this for derived figures rather than mere changes. It does not directly address sibling tools like seller_rank or category_demand, but the comprehensive nature is implied. Still, some explicit 'when to use vs siblings' guidance is missing.

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 establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: a 422 refusal for empty windows, that such calls are not charged, partial coverage before the archive's first date, and pricing. This goes beyond what annotations provide.

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

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

The description is four sentences, each adding value: main function, attribution/ranking logic, error/refusal behavior, and pricing. It's dense but well-structured, with the core purpose front-loaded. No wasteful content.

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 tool with no output schema, the description adequately covers output content (rows with attribution), ranking, edge-case behavior, and cost. It lacks explicit return field details but is sufficient for an agent to understand the tool's behavior. No significant gaps.

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

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

The schema already describes both parameters (limit and since) with 100% coverage. The description mentions the time-window behavior and the 422 condition related to 'since' but does not add new meaning to the parameters beyond what the schema states. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'x402 services first listed since a given date, with first archive observation and early-traction evidence from observed inflow.' It also specifies the attribution criteria (payTo, title, inflow) and ranking behavior, distinguishing it from sibling tools that focus on demand, market reports, or seller rankings.

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

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

The description implies usage for discovering services first listed after a date, and it mentions edge cases like the 422 refusal and partial coverage for early dates. However, it does not explicitly compare to alternatives or state when not to use it relative to the sibling tools.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond this: sellers below the observation floor are returned unrated (not accused), the payer-graph discount is conditional on wallet scan coverage, and HHI measures concentration rather than common control. It also discloses pricing per successful call, which is not indicated elsewhere.

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 with the core purpose in the first sentence. Subsequent sentences add important caveats and pricing, each earning its place, though it could be slightly trimmed without losing 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?

Given that there is no output schema, the description adequately conveys the return components (USDC inflow, distinct payers, HHI, wash-risk flags) and includes essential caveats. It doesn't specify exact response structure, but for a leaderboard query, the description is sufficiently complete.

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

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

The input schema already fully describes both parameters (limit and category) with detailed constraints and defaults, achieving 100% schema coverage. The description does not add additional parameter semantics, 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 clearly identifies the tool as a leaderboard of x402 sellers ranked by observed USDC inflow, with specific metrics like distinct payers, HHI concentration, and wash-risk flags. This distinguishes it from sibling tools such as x402_category_demand or x402_market_report by focusing on individual seller ranking rather than broader market trends.

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

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

The description provides clear context about what the tool returns (leaderboard data with specific metrics) but does not explicitly state when to use this tool over alternatives or mention sibling tools. The unique metrics imply specialized use cases, but no direct when/when-not guidance is given.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: a per-call price ($0.003 USDC only on success), the output's disclosure of the baseline window and held portion, and the 'strictly qualified' nature of signals. This enriches understanding of the tool's 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 three concise sentences: one defining the tool, one explaining response behavior, and one giving usage guidance plus pricing. Every sentence carries meaningful information with no redundancy or 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?

The tool is simple (one optional parameter) and has no output schema, so the description must convey return-value context. It does mention that the response states the baseline window and how much is held, but it could further clarify the exact structure of the feed. Given the simplicity, it is largely complete, but not maximally so.

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, 'limit', is fully described in the schema (default, min, max, and meaning). The description adds no additional parameter-specific semantics, so the baseline score of 3 applies, as the schema carries the full burden.

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

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

The description clearly states the tool as an early-warning feed for daily inflow spikes and qualified large-payer signals. It distinguishes itself from sibling tools by focusing on abrupt payment activity changes within a day, leaving no doubt about its core function.

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 'Use this to catch an abrupt change in a service's payment activity within a day,' providing clear context for when to use it. However, it does not name alternatives or state when not to use it, so it stops short of full 5.

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

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

Annotations already declare read-only/idempotent/non-destructive. The description adds that the response indicates how many calendar days of history back the comparison, that growth is measured on observed on-chain transfers, and that the call costs $0.003 USDC. These are valuable behavioral disclosures beyond the annotations.

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

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

Three sentences, each with a distinct purpose: definition, response behavior/usage, and data-source/pricing caveat. No redundant wording.

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 read-only tool, the description covers what it returns, how to use it, response caveat (history days), and pricing. Without an output schema, it could benefit from example return items, but the essentials are covered.

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, limit, is fully described in the schema (range, default, description). The tool description adds no additional meaning for this parameter, so the baseline of 3 applies when schema coverage is high.

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 defines 'trending' specifically as growth in inbound USDC transfer count and inflow across comparable daily windows, and explicitly states its use case: spot rising demand early. This is more specific than the title and distinguishes it from category, market, and new-entrant 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 a clear use case ('Use this to spot rising demand early') and a data-source exclusion ('not on self-reported revenue'), but it does not name alternative tools or explicitly state when not to use it.

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