x402 Crypto Market Structure

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds significant behavioral detail: auto-detection of EVM/Solana, specific output fields, flags list, and cost. No contradictions.

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 concise: one purpose sentence, a list of outputs and flags, and the REST equivalent and argument specification. Every sentence earns its place. Front-loaded with the main purpose.

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 tool's simplicity (1 required param, no enums, output schema exists), the description covers all necessary context: input format, auto-detection, output fields, flags, cost, and usage hint. It is complete without repeating the 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 only provides title and type for 'address'. The description compensates fully by specifying EVM (0x...) and Solana (base58) formats and auto-detection. With 0% schema description coverage, this is exactly what is needed.

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

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

The description clearly states the verb (risk-check/analyze), resource (wallet address), and the key outputs (entity label, risk level, account age, etc.). It uniquely distinguishes from sibling tools (api_info, market_*) by focusing on address risk analysis.

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 advises 'Before you transact, know who you're dealing with', implying use for address vetting. It also provides the REST equivalent and cost, which aids usage context. However, it does not explicitly mention when not to use or compare to alternatives, though siblings are clearly different.

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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about rate limits (60 calls/min per IP for MCP, 60/min and 200/hr per wallet for REST) and pricing, which goes beyond 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 concise with only 4 sentences, front-loading the purpose, then usage guidelines, then rate limit details. No redundant 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?

Given no parameters and the presence of an output schema, the description sufficiently covers the tool's purpose and key details like pricing and rate limits. It is complete for an informational 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?

No parameters, so schema coverage is 100%. The description adds context about what information the tool provides, but no parameter details are needed. Baseline 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 REST API access information for autonomous agents, including pricing, quick start, and migration guide. It is distinctly different from sibling market data 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 lists when to call this tool (e.g., building a trading bot, hitting rate limits) and provides context for MCP vs REST API usage, helping the agent decide when to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of 'data-only' and 'no LLM latency' adds marginal context. The idempotentHint=true is questionable given market data changes, but the description does not contradict 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 well-structured with a catchy opening, clear bullet for token list, and concise explanation of the context parameter. It includes REST equivalent and cost. Slightly verbose but each sentence adds value.

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 presence of an output schema (not shown), the description appropriately focuses on inputs and purpose. It covers token selection, context options, and macro outputs. Missing rate limits or auth details, but these are likely covered by annotations.

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 0% schema description coverage, the description compensates by explicitly listing supported tokens for the 'token' parameter and explaining the 'context' parameter options and effect (adds percentile rankings). This adds meaningful guidance beyond the plain 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 clearly defines the tool's purpose: analyzing macro regime, directional signal, and confidence. It specifies supported tokens and distinct attributes like 'data-only' vs LLM-based alternatives, differentiating it from 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 suggests using this tool 'before entering a position' but does not explicitly contrast with siblings like market_full, market_light, or market_orderflow. The context is implied but not definitive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: it makes a 'grounded judgment', cites data values, and discloses coverage per token. No contradiction with 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 moderately long but every sentence adds value. It front-loads the main purpose and lists parameters in a readable list. Slightly verbose due to the 'REST equivalent' note, but overall 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?

With only 2 parameters and an output schema (not shown but exists), the description covers parameter semantics and behavioral traits adequately. It also mentions cost and coverage disclosure, providing complete context for an agent's decision.

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

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

Schema coverage is 0%, so the description carries the full burden. It lists accepted token symbols (BTC, ETH, etc.) and context options ('7d', '30d'), adding significant meaning beyond the schema's plain string type.

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 'Full pre-trade diligence in one call' and enumerates specific outputs (stance, signal, risk level, verdict with data). It distinguishes from siblings like market_light and market_snapshot by offering a comprehensive single-call analysis.

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 advises 'Use when you want a single answer rather than assembling the pieces yourself', giving clear context for invocation. It does not explicitly list when not to use or compare to specific alternatives, but the guidance is sufficient for an agent.

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

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

Annotations already indicate read-only, idempotent, and non-destructive. The description adds valuable behavioral context: rate limit of 10 calls/minute per IP, caching up to 24h, and automatic symbol disambiguation. This goes beyond annotations by disclosing performance constraints and data freshness trade-offs.

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 well-organized: purpose first, then comparisons, usage guidelines, rate limits, caching, and parameter details. Every sentence is substantive with no fluff. Ideal front-loading and efficient use of space.

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 output schema exists, so return values need not be detailed. The description covers purpose, usage, limitations, rate limits, caching, and one parameter. It falls short by not addressing the 'brief' parameter or explaining what happens if symbol is invalid. Overall fairly complete but with a notable 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?

Schema coverage is 0%, so description must compensate. For the 'symbol' parameter, it adds semantics (alphanumeric 1-10 chars, examples, case-insensitivity). However, it completely omits the 'brief' parameter, leaving its purpose and valid values undocumented. Partial compensation, hence 3.

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 structured coverage for ANY listed token, including price, momentum, and signals. It explicitly distinguishes from sibling 'market_snapshot' by noting broader coverage but shallower data, and specifies it's for tokens outside the core set. This satisfies the specific verb+resource and sibling differentiation criteria.

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: 'Use for tokens outside the BTC/ETH/SOL/etc. core set.' It also explains when not to use by contrasting with market_snapshot and mentioning shallower data. It specifies rate limits and caching behavior, providing clear context for invocation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations, such as the tool being 'Data-only', checking orderflow coverage per token, and flagging wash trading via HHI > 0.6. It provides meaningful insight into the tool's behavior without contradicting 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 structured with a hook question, bullet-like list of outputs, and then the REST equivalent and Args. It is front-loaded with the key purpose. While slightly lengthy, every sentence adds value. It could be more concise but remains effective.

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 tool's complexity, the description covers all essential aspects: purpose, specific metrics, limitation (orderflow coverage disclosure), cost (0.50 USDC), and parameters. Since an output schema exists, the description does not need to explain return values. This is highly complete for effective agent use.

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

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

Schema description coverage is 0%, so the description must compensate. It lists allowed tokens explicitly and explains the 'context' parameter as an optional window ('7d' or '30d') adding percentile rankings. This adds significant meaning beyond the schema's bare string types, though it could specify allowed values more formally.

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 purpose: analyzing market order flow to detect if moves are backed by real buyers or manipulation. It lists specific metrics (CVD direction, buy/sell ratio, whale clustering, etc.) and explicitly distinguishes itself from siblings by focusing on order flow data. The REST equivalent is also provided.

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 order flow analysis but does not explicitly state when to use this tool versus alternatives like market_analyze or market_snapshot. It mentions 'Data-only' but lacks clear guidance on exclusions or specific scenarios where this tool is preferred over siblings.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds that the call returns 16 fields and includes orderflow coverage per token, but does not elaborate on behavioral traits like rate limits, data freshness, or what 'orderflow coverage disclosed' means. Some value added beyond 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 relatively concise, front-loading the purpose with a relatable question and key data points. The Rs list adds value, though the line about 'no LLM overhead' and REST equivalent is extra but not excessive. Slight fluff could be trimmed.

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 a single parameter and the presence of an output schema, the description is adequate. It explains the tool's purpose and lists inputs. However, it could be more complete by briefly contrasting with sibling tools or clarifying the 'orderflow coverage' term.

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 0% schema description coverage, the description compensates by listing 26 valid token symbols explicitly (e.g., BTC, ETH, SOL). This significantly aids the agent in choosing the correct parameter value, though it does not specify case sensitivity or exact formatting.

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 it provides current market data (price, funding rate, CVD, whale activity, liquidation pressure) for a token, listing 16 fields. However, it does not explicitly differentiate from sibling tools like market_full, market_analyze, or market_light, which could cause confusion about when to use this specific snapshot.

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 encourages feeding data into models but provides no guidance on when to use this tool versus alternatives (e.g., market_full for more detail, market_analyze for analysis). No when-not-to-use or prerequisites are mentioned.

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