Crypto Market Intelligence MCP

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

With no annotations provided, the description carries the full burden. It transparently discloses the payment model (free allowance, $0.02 per query, 402 handling), the need for payment_tx, and the return of a provenance attestation. It does not mention rate limits or data freshness, but the core behavioral traits are well covered.

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 two main sentences plus a payment instruction. It is front-loaded with the primary purpose. The payment details are somewhat dense but necessary. No wasted words, though the structure could be slightly clearer.

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 complexity (payment, provenance, anomaly types), the description covers all essential aspects: what it does, return format, and payment flow. An output schema exists, so return values are documented there. The description is complete for an API 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 input schema has 100% description coverage for all three parameters. The description adds value by explaining the re-call requirement with 'SAME args' after a 402, which is not obvious from the schema alone. This slightly exceeds the baseline of 3 for high schema coverage.

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: 'Scan the market for anomalies' and specifies the types of anomalies detected (volume spikes, price moves, divergence from moving averages). It distinguishes from sibling tools like price, market_overview, and whale_alerts by focusing on anomaly detection and ranking.

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 explains when to use the tool (scanning for market anomalies) and provides payment instructions, but it does not explicitly state when not to use it or compare it to alternative sibling tools. The context is clear but lacks exclusion guidance.

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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: payment required ($15 USDC), daily expiration at midnight UTC, MINT provenance attestation, and the 402 payment flow. This is sufficient for the agent to understand side effects and requirements.

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 paragraphs—clear and front-loaded with the brief's contents, then payment details. It is dense but not overly verbose; every sentence adds information. Could be slightly more structured but remains concise.

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 (paid, time-sensitive, provenance), the description adequately covers payment, expiry, and retry flow. It correctly assumes the output schema handles return values. Minor gap: no mention of behavior for missing dates (e.g., future dates), but overall 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?

All three parameters (date, agent_id, payment_tx) are described in the schema and the description adds context: date format, agent_id scoping the free-tier counter, and payment_tx usage after a 402. This adds value beyond the schema, justifying a score above the baseline 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's purpose: 'Get the curated daily crypto brief' and enumerates specific contents (gainers/losers, Fear & Greed, market cap, BTC dominance, DeFi TVL movers, anomalies). This verb+resource combination distinguishes it from siblings like anomaly_scan, defi_overview, and market_overview.

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 detailed payment and retry instructions but lacks explicit guidance on when to use this tool versus siblings. It doesn't mention scenarios where a user might prefer a focused tool like anomaly_scan for anomalies alone.

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?

No annotations are provided, so the description carries the full burden. It clearly discloses that the tool is paid, explains the free-tier allowance, details the error recovery process for 402s, and mentions the optional authorization bypass. This level of detail far exceeds basic behavioral disclosure.

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 fairly concise but includes some redundancy (e.g., restating the payment mechanism twice). It is front-loaded with the main functionality, then covers payment specifics. Sentences are purposeful, though minor trimming could improve 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?

Given the tool's moderate complexity (two modes, payment handling), the description covers all essential aspects: core functionality, parameter effects, payment details, and error recovery. The presence of an output schema reduces the need to describe return values. No gaps are apparent.

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%, providing descriptions for all three parameters. The description adds value beyond the schema by explaining the dual behavior dependent on the 'protocol' parameter and the payment flow for 'payment_tx'. While the schema already does well, the description provides essential context for proper usage.

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 explicitly states it retrieves DeFi TVL intelligence from DeFiLlama and distinguishes two clear behaviors: with a protocol name, returns that protocol's TVL and 1d/7d changes; without a name, returns top protocols by TVL grouped by category plus total TVL. This is a specific verb-resource pairing that clearly differentiates 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 provides explicit guidance on payment handling: a daily free allowance, $0.01 USDC per query after that, and the 402 retry mechanism with payment_tx. It also mentions an Authorization header bypasses payment. However, it does not explicitly state when not to use this tool versus alternatives.

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

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

With no annotations, the description must disclose behaviors. It mentions the tool is 'FREE' and returns specific data, but lacks details on update frequency, latency, or limits. The behavioral disclosure is adequate but minimal.

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, front-loaded with the core purpose, and includes all key elements without wasted words. 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?

Given no parameters and the presence of an output schema, the description covers the tool's purpose and return data sufficiently. However, it could mention whether the data is real-time or cached, but overall it is complete for a simple parameterless tool.

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

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

There are zero parameters, and schema coverage is 100% (trivially). The description does not need to add parameter info. Baseline for 0 parameters is 4 per rubric.

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: 'Get a snapshot of the crypto market' and lists specific data returned (top 20 coins, total market cap, BTC dominance, Fear & Greed index). This distinguishes it from sibling tools like price (single coin) or defi_overview (DeFi focused).

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 use for quick market sentiment via 'everything an agent needs to size up sentiment in one call' but does not explicitly state when to use this over alternatives or when not to use it. No comparisons to sibling tools are provided.

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?

No annotations are provided, so the description bears the full burden. It mentions the tool is 'FREE' and describes its informational nature (details, how-to). For a read-only informational tool, this is adequate, though it could state more explicitly that it has no side effects.

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

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

The description is a single sentence that conveys the key points without fluff. It could be slightly restructured for clarity (e.g., separating the network details from the how-to), but overall it is concise 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?

For a tool with no parameters and a simple informational purpose, the description provides sufficient context. It mentions sibling data servers, aligning with sibling tools. The presence of an output schema (not shown) further reduces the need for additional explanation.

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 and 100% schema coverage, so the baseline is 4. The description does not need to add parameter details; it correctly explains the tool's purpose 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 clearly states the tool provides 'FoundryNet Data Network + MINT Protocol details' and explains how to attest crypto market reads on-chain. It distinguishes from siblings like anomaly_scan and market_overview by focusing on network protocol info.

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 implicitly indicates usage for getting network and protocol details, but lacks explicit guidance on when to use versus siblings or alternatives. The mention of 'sibling data servers' hints at related tools but does not provide clear when-to-use or when-not-to-use criteria.

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?

No annotations are provided, so the description bears full responsibility. It indicates the tool is FREE and returns non-destructive data. It explains accepted inputs (id or symbol) and output fields, which provides sufficient transparency for a simple read-only 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?

The description is concise with three short sentences. The first sentence states purpose, the second adds value (FREE, gateway tool), and the third covers parameter usage. No waste, though the promotional language is not strictly necessary.

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 complexity (single parameter, simple output), the description adequately explains what the tool does and returns. With an output schema present (though not shown), it covers the essential aspects for an agent to use the tool effectively.

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% with a clear parameter description. The description restates that the parameter accepts a CoinGecko id or ticker symbol, adding no new meaning 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 clearly states the tool gets the latest USD price for a cryptocurrency, listing specific return fields (price, 24h change, volume, market cap). It implies it's the entry-level tool by calling it the 'gateway tool', distinguishing it from sibling tools like price_history or market_overview.

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 calls it the 'gateway tool every trading agent needs', which hints at a primary use case but does not explicitly state when to use this tool versus siblings like price_history or market_overview. No exclusions or alternatives are mentioned.

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?

With no annotations, the description carries full burden. It discloses payment requirement, free allowance, 402 error handling, and authorization bypass. Missing details like rate limits or that it's read-only, but covers the critical payment 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?

Two short paragraphs: first states core function, second covers payment details efficiently. No redundant information, but could be slightly more streamlined.

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?

Output schema exists, so return values need no description. The description covers main functionality, payment mechanism, and parameter usage. Missing explanation of non-critical aspects like error handling beyond 402, but sufficient 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%, so baseline is 3. The description adds value beyond schema by explaining the payment_tx parameter's role in retry and linking 'days' to 'over the last N days'. This improves the agent's understanding.

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 'Get' and resource 'daily price/volume history', specifies the time range ('over the last N days'), and lists use cases ('for backtesting, charting, and trend analysis'). This distinguishes it from sibling tools like 'price' which likely provides single-point data.

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 describes usage context (backtesting, charting, trend analysis) and provides payment handling instructions. However, it does not explicitly mention when not to use this tool or compare directly to 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?

With no annotations, the description carries full burden. It discloses the data source (volume-derived, not on-chain), payment requirement, and retry process. However, it does not mention potential rate limits, data freshness, or whether the tool is read-only. It is transparent about key behaviors but lacks some operational details.

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 efficiently structured: one sentence for purpose, one for data source caveat, one for payment instructions. Each sentence serves a distinct purpose without redundancy. It is concise yet comprehensive for the tool's complexity.

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 (payment model, free tier, filtering), the description covers most aspects: data source, payment flow, parameter roles. The output schema exists, so return values need not be described. The only gap is lack of mention of response format or pagination, but overall it 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?

Schema description coverage is 100%, so baseline is 3. The description adds context by explaining the role of 'agent_id' (scopes free-tier counter) and 'payment_tx' (used after 402). It also implies that 'coin' filters to one coin and 'min_value_usd' sets a floor. This additional meaning justifies a score above 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 clearly specifies the tool's purpose: to 'surface notable crypto flows' based on volume and turnover as a proxy for whale activity. It distinguishes itself from raw on-chain data by explicitly stating it's volume-derived, making the purpose specific and 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 provides explicit guidance on when to use this tool, including that it is volume-derived (not raw on-chain) and details the payment model ($0.01 per query after a free daily allowance). It explains how to handle a 402 error with payment, and mentions the optional Authorization header. This covers both usage conditions and alternatives.

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