MCPFax Macro & Market Intelligence

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds meaningful behavioral context beyond these: the $0.005 USDC cost, the payment challenge behavior for unpaid calls, and the no-settlement rule when no data is returned. This is valuable and not redundant.

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 filler: the core purpose, the use case, and the important cost/payment caveats. Every sentence earns its place and the key information is 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 zero-parameter read-only tool, the description covers the source, units, use case, cost behavior, and even the equivalent HTTP route. The lack of an output schema is not a significant gap at this complexity level.

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 no parameters, so the schema is empty. The description still adds helpful semantics by specifying that the result is provided in both wei and gwei, which informs interpretation of the response.

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

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

The description states a specific verb ('read'), a precise resource ('Base mainnet gas price'), the live JSON-RPC source, and the output units (wei and gwei). This clearly distinguishes the tool from the sibling financial 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?

It explicitly tells the agent when to use the tool: to estimate the cost of a Base transaction before submitting it. It does not name alternatives, but with zero parameters and unrelated siblings, no exclusion is necessary.

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 goes well beyond the readOnly/idempotent annotations by disclosing the explicit per-symbol error behavior, the $0.005 USDC cost via x402 on Base, the payment-challenge edge case, and the no-data/no-settlement guarantee. This is rich behavioral context an agent needs before calling.

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

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

The description is front-loaded with purpose and usage, then adds error handling, cost, and routing details. It is a bit dense, especially around the payment model, but each sentence conveys an operationally relevant fact with little waste.

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

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

For a simple one-parameter, read-only tool, the description covers purpose, asset-limit, error behavior, cost edge cases, and the equivalent HTTP route. There is no output schema, and the response shape is not described in detail, but the description is adequate 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?

The input schema already documents the symbols parameter with examples and a default, and coverage is 100%. The description adds extra meaning by stating the 'up to ten' asset limit and clarifying that prices are USD spot values, which is not fully captured in the schema.

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

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

The description states a specific verb and resource: it returns Coinbase spot prices in USD for crypto assets. It clearly scopes the tool to 'current' prices for up to ten assets, distinguishing it from sibling price-oriented tools like defi_token_prices and fx_reference_rates.

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 explicitly says 'Use this for a current crypto price,' giving clear guidance on when to invoke the tool. However, it does not mention alternative tools or conditions where a sibling would be preferable, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond those: the $0.005 USDC cost per call, the unpaid-call payment challenge response, the 'no data costs nothing' policy, and the null-TVL handling (excluded from total rather than zero). This fully discloses the tool's operational quirks, which is exactly what an agent needs to handle edge cases.

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 paragraph with multiple sentences, but each sentence earns its place: purpose, use case, null handling, cost/payment, and equivalent HTTP route. It is front-loaded with the core purpose and progressively adds operational details. It is not overly verbose for the amount of critical information it conveys.

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

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

With no output schema, the description must convey the return shape, and it does: it lists the key fields (chain, native token symbol, EVM chain id, summed cross-chain total) and the ranking order. It also covers null behavior, cost, and payment edge cases. While it does not specify exact field names or response structure, it provides sufficient context for an agent to understand what to expect and how to handle non-data responses.

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 both parameters (limit and search) already described in the input schema. The description does not add any parameter-specific meaning beyond what the schema provides; it focuses on output and cost. Given the high schema coverage, a 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 opens with a specific verb and resource: 'Total value locked per blockchain from DefiLlama, ranked high to low, with each chain's native token symbol and EVM chain id plus the summed cross-chain total.' This clearly differentiates it from siblings like defi_protocols (protocol TVL) and defi_yields (yields) by focusing on chains. The inclusion of concrete output elements (token symbol, EVM chain id, summed total) makes the tool's purpose unmistakable.

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 explicitly states two use cases: 'Use it to compare chains by capital deployed or to check where a chain sits.' It also provides operational guidance on cost and payment behavior. However, it does not mention any alternative tools or when not to use it, though the tool is distinct enough among siblings that this omission is minor.

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?

Discloses behavior for unpaid calls (returns payment challenge) and no data (not settled), plus honest not_found, which goes beyond readOnlyHint annotation.

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 informative paragraph covering output, usage, and errors without excessive verbosity, though it is slightly long for the amount of new info beyond the schema.

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

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

No output schema provided, but the description lists all returned fields (TVL, per-chain breakdown, category, token symbol, chain list, description, links) and covers error cases and cost, making it complete for 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?

Only parameter 'slug' has a description and example in the schema (100% coverage), so the description adds no additional parameter-specific meaning beyond the schema, warranting 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?

States it provides full detail for one protocol by slug, listing specific fields (TVL, per-chain breakdown, etc.), and distinguishes from sibling tool defi_protocols by saying 'Use it after finding a slug with the protocols list.'

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 instructs to use after finding a slug, and describes cost and behavior on unpaid calls and unknown slugs, providing clear when-to-use and constraints.

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?

Discloses read-only, idempotent nature via annotations and additionally explains payment behavior (cost, unpaid call challenge, no settlement on no data) and data freshness (live, 5-minute hold), going 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 well-organized, with each sentence adding value (purpose, output, usage, cost, freshness, HTTP route). No redundant fluff; it is concise yet comprehensive.

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?

Covers all necessary context: functionality, filters, output fields, use cases, payment model, data freshness, and equivalent HTTP route. Even without an output schema, the listed fields make it 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 4 parameters have descriptions in the schema, and the tool description reinforces their meaning (e.g., filters by chain, category, name substring). Schema coverage is 100%, and each parameter is self-explanatory.

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?

Clearly states the tool ranks DeFi protocols by TVL from DefiLlama with filters and lists output fields. It also explicitly mentions use cases like sizing a protocol, finding biggest venues, and resolving slugs.

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 use cases and contrasts with the protocol-detail tool by mentioning it resolves slugs needed by that tool. Also includes cost and HTTP route, which helps decide when to use.

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?

Beyond the annotations (readOnly, openWorld, idempotent), the description adds concrete behavioral details: the $0.005 USDC cost per call, the payment challenge for unpaid calls, and the fact that calls returning no data are never settled. It also explains that unpriced tokens return null rather than a substituted price, which is valuable behavior information.

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 dense paragraph that covers purpose, usage, cost, and error behavior. It is well-structured but slightly verbose; breaking it into separate sentences or bullet points could improve scannability. Still, it is concise enough and every sentence contributes useful information.

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

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

Given there is no output schema, the description adequately describes the return fields (price, symbol, decimals, confidence, timestamp). It also covers edge cases (null for unpriced tokens, payment challenge, no-settlement on no-data), providing a complete picture of the tool's behavior and output.

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 provides 100% coverage with descriptions and examples for both parameters. The description further clarifies the coins parameter format (chain:address or coingecko:id) and the search_width default, adding slight semantic value 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 clearly states the tool's purpose: 'Price arbitrary on-chain tokens with DefiLlama's coins API'. It also specifies the address format and return fields, and explicitly differentiates it from the sibling crypto spot tool, making its 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 usage guidance: 'Use it to value a DeFi position holding tokens no exchange lists' and explicitly states what it is NOT for: 'This is NOT the exchange-price tool: use the crypto spot tool for a plain price of a major asset'. This provides clear when-to-use and when-not-to-use instructions.

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 readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond that, including the $0.008 USDC cost via x402, the payment-challenge response for unpaid calls, the no-settlement-when-no-data rule, and the null-never-zero APY convention. This is strong transparency for a paid API.

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

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

The description is front-loaded with the core purpose and filters, then covers output fields, use case, APY null semantics, cost/payment behavior, and an HTTP equivalent. Every sentence adds useful information without padding or 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?

Despite having no output schema, the description lists the returned fields (pool_id, chain, project, symbol, TVL, APYs, IL risk, exposure). It also covers payment behavior and the no-data cost rule, making it complete enough for an agent to invoke the tool and interpret results 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?

The input schema already documents all six parameters at 100% coverage, so the schema carries the parameter definition burden. The description reinforces the filter categories (chain, project, symbol, min TVL, stablecoin-only) and adds the ranking-by-APY context, but it does not add much meaning beyond what the 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 states a specific action ('Screen DefiLlama's yield-pool universe') with explicit filters and output fields, so an agent knows exactly what the tool does. It is clearly distinct from siblings like defi_protocols or defi_chains because it focuses on yield pools and APY 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 provides a clear use case: 'Use it to find where a given asset earns yield.' It does not explicitly name alternative tools or give when-not-to-use guidance, but the context is specific enough for an agent to select it appropriately among the 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 behavior, and the description adds meaningful context beyond that: the Worker cron refresh from Frankfurter, daily rather than live data, the snapshot.captured_at and snapshot.age_hours response fields, the payment requirement and failure mode, and the no-data-no-charge policy. 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 front-loaded with the core purpose and then layers caveats, response metadata, cost, and payment behavior. It is dense but each sentence adds relevant operational information, though the equivalent HTTP route line is slightly peripheral for an MCP agent.

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 explains the core behavior, data freshness, key response metadata, and the important payment-challenge failure mode. It does not spell out the full rate response structure, but an agent has enough to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, and each parameter already has a clear description and example. The tool description adds useful context about base currency and ECB observation date, but it does not need to compensate for schema gaps because the schema is already thorough.

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 resource as European Central Bank reference foreign-exchange rates for a chosen base currency, with the ECB observation date. It is immediately distinguishable from the sibling crypto, defi, and prediction-market tools, and the 'not live tradable quotes' caveat sharpens the scope.

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 states these are daily reference rates and explicitly warns they are not live tradable quotes, which tells an agent when not to use them. It also explains the as_of historical lookup behavior via the schema. It does not name a specific alternative tool, but the exclusion is clear enough in context.

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 it read-only, idempotent, and open-world, so the description correctly does not repeat those facts; instead it discloses what the tool returns, the non-real-money nature of Manifold probabilities, the payment experience via x402, and the no-data/no-settlement behavior. This adds substantial value beyond the structured metadata and contradicts none of 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 purpose and return fields are front-loaded in the first sentence, followed only by the two caveats that materially change call behavior (MANA semantics and paid-call settlement) and the HTTP route. No sentence is filler or repeated schema 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 an optional-parameter, read-only list/search tool with no output schema, the description is complete: it names the returned fields, explains the venue's token/pricing semantics, covers the payment challenge and no-cost-on-no-data behavior, and gives the direct HTTP equivalent. An agent has enough to invoke it correctly without additional documentation.

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 documents all four parameters with descriptions, examples, and allowed values, so the baseline of 3 applies. The description's 'Search or browse' and output-field list imply the intended use of search/sort/filter but add no parameter-level detail beyond the schema.

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

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

The opening clause 'Search or browse Manifold Markets questions' uses a specific action and resource, and the description lists concrete return fields (probability, outcome type, volume, liquidity, unique bettor count, close time, creator, resolution state). This is distinct enough to separate it from sibling prediction-market tools such as polymarket_markets, even though no sibling is named.

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 clear practical guidance: the MANA/play-money caveat, the per-call cost, the unpaid-call challenge behavior, and the fact that a no-data call is never settled and costs nothing. It stops short of explicitly saying when to choose this over prediction_market_search or Polymarket tools, so it gets a 4 rather than a 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 readOnlyHint, idempotentHint, and non-destructive. The description adds valuable cost and payment behavior: $0.005 USDC via x402 on Base, unpaid calls returning a payment challenge, and no-cost for no-data calls. It also mentions the HTTP route. This goes beyond the annotations and clarifies failure modes.

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?

Four sentences, front-loaded with the main action and then usage and cost. No filler; every sentence adds value. The structure is logical: what it does, when to use, cost/payment, and HTTP route.

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?

Complete for a list tool: parameters are fully documented in the schema, annotations cover safety, and the description covers cost, usage, and return fields. No output schema exists, but the description lists the fields returned, which is sufficient for an agent to interpret the response.

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 each parameter documented including examples and defaults. The description does not add additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate. It does not discuss parameter interactions or edge cases.

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?

Clearly states the tool lists Polymarket events, defines what events are (grouped questions such as elections), and lists the fields returned (title, slug, end date, volume, etc.). This distinguishes it from siblings like polymarket_market or polymarket_markets by focusing on grouped questions rather than individual markets.

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 states when to use: 'Use it when a question has many candidate outcomes and you want them together rather than one at a time.' This implies alternatives like polymarket_market for single outcomes and provides clear guidance without needing to inspect 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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses additional behavior: the cost per call, payment challenge mechanism, and the fact that unpaid or no-data calls cost nothing. It also clarifies null name handling, adding transparency not present in 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 detailed but each sentence serves a purpose: it covers the core function, a use case, a data nuance (null names), and cost/payment details. The structure is logical, starting with the primary purpose and then adding practical context.

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 provides a clear picture of the output (rank, pseudonym, display name, wallet address, USDC amount) and includes operational details like cost and HTTP route. While it doesn't specify an exact response format, the information is sufficient for an agent to understand what the tool returns and how to use it.

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 provides full parameter descriptions (limit, metric, window) with examples. The description reinforces these by mentioning 'traded volume or realised profit' and '1d, 7d, 30d or all-time window,' but adds no new semantics beyond the schema. Since schema coverage is 100%, 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 states the tool's function: retrieving a public trader leaderboard from Polymarket, with specific metrics (volume or profit) and time windows. It distinguishes itself from sibling tools by focusing on leaderboard data rather than individual markets or trades.

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 suggests when to use the tool ('Use it to find who is moving size on the venue') and provides actionable context like the HTTP route and cost. While it doesn't explicitly contrast with alternatives, the purpose is clear enough for an agent to select it appropriately.

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 readOnlyHint/idempotentHint already covering safety, the description adds valuable behavioral detail: null order books instead of fabricated prices, not_found for unknown identifiers, billing semantics, payment-challenge behavior on unpaid calls, and no settlement when no data is returned. This goes well beyond the annotations and helps an agent anticipate edge-case responses.

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 yet information-dense: purpose, use case, edge-case behavior, billing, and an HTTP route equivalent are conveyed in three sentences. No sentence is filler, and critical caveats are placed early.

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

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

For a read-only lookup tool with no output schema, the description sufficiently describes output contents (outcome pricing, best bid/ask, midpoint, spread, top price levels with sizes) and covers errors and costs. An agent has enough information to invoke the tool correctly and interpret its likely responses.

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 each parameter (id, slug, condition_id, depth) already having descriptions and examples. The description repeats identifier options but adds no new parameter-level detail, so a 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?

Description opens with a specific verb-resource pairing: 'One Polymarket market' retrievable by Gamma id, slug, or condition id, and distinguishes itself by including 'full outcome pricing and the LIVE CLOB order book'. This clearly differentiates it from sibling tools like polymarket_markets and polymarket_trades, which cover lists and trade history.

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 says to use it 'before taking a position, to see real depth rather than only a last price,' which gives a clear use context. It does not explicitly name alternatives or state when to use them, so it falls just short of the strongest 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description goes further by detailing cost ($0.005 USDC), payment challenge behavior for unpaid calls, and the 'no data no cost' guarantee, which are critical operational details not covered by 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: it starts with the core action, then explains the use case, and finally covers cost and HTTP equivalent. It packs necessary detail (output fields, pricing behavior) without unnecessary fluff, making it efficient and easy to parse.

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?

Despite lacking an output schema, the description enumerates all returned fields (question, Gamma id, condition id, outcomes with prices, best bid/ask, etc.) and explains payment/response edge cases. This gives the agent a complete picture of what to expect, fulfilling the contextual needs.

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 provides 100% coverage with descriptions and examples for all four parameters. While the description mentions ordering by volume/liquidity, it does not add significant meaning beyond the schema's existing parameter descriptions, 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 states the tool's primary function: to list live Polymarket markets with detailed fields like question, Gamma id, condition id, outcomes, prices, and liquidity. It also distinguishes this from sibling tools by focusing on market lists ordered by volume/liquidity, 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?

The description provides a concrete use case ('see what the largest real-money prediction markets are pricing right now') and implies this is the go-to for listing markets. However, it does not explicitly contrast with sibling tools like polymarket_events or prediction_market_search, so the guidance could be more direct.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context beyond that: the per-call cost ($0.005 USDC via x402), the payment challenge behavior on unpaid calls, and the guarantee that no-data calls are never settled. This is exactly the kind of extra transparency that annotations do not capture.

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 carrying distinct information: purpose and fields, use case, cost/payment behavior, and HTTP route. It is front-loaded with the core purpose and avoids redundancy. Slightly verbose for a simple tool, but every sentence contributes 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?

For a read-only tool with two parameters and no output schema, the description covers the essential operational aspects: what it returns, how it is used, cost, payment failure mode, and an equivalent HTTP endpoint. It lacks explicit error handling or rate-limit info, but given the annotations and schema, this 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 coverage is 100%, with both 'limit' and 'market' already described in the input schema. The description reinforces that 'market' is the condition id and notes it is required (though schema marks it optional), but it does not add new semantic meaning beyond the schema. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 retrieves recent public trade prints for a single Polymarket market identified by condition id, and enumerates the exact fields returned (timestamp, side, outcome, price, size, notional, pseudonym, wallet, hash). This distinguishes it from sibling tools like polymarket_market (single market details) and polymarket_markets (listing markets).

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 concrete use case: 'Use it to see whether a quoted price is actually trading and who is behind the flow.' This tells the agent when to employ this tool, though it does not explicitly mention alternatives or exclusion conditions. The context is clear enough to route correctly among the Polymarket family.

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, open-world, idempotent, non-destructive. The description adds substantial behavior: cost per call, payment challenge on unpaid calls, no charge for empty results, per-venue status visibility, and the deliberate exclusion of Kalshi. 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 dense but every sentence carries value: purpose, return format, usage condition, exclusion, cost, payment behavior, and HTTP route. It is front-loaded with the core purpose and avoids 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 complex tool with no output schema, it explains return structure (normalised list with venue, currency, question, YES probability, volume, end date, URL, per-venue status), failure handling, cost, and alternatives. An agent has all necessary context to call it correctly.

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

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

Schema coverage is 100% and each parameter already has descriptions and examples. The description does not materially extend parameter meaning beyond the schema, though it does imply q is required via usage phrasing. 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 verb 'Find' and the resource 'prediction market by question text', specifies the two venues (Polymarket and Manifold), and distinguishes it from sibling single-venue tools by emphasizing the cross-venue normalization and unified output.

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 states when to use: 'when you know the question but not the venue or the id.' Also provides a clear exclusion (Kalshi) with a technical reason, and mentions cost/behavior that informs invocation decisions.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description provides important behavioral details: the $0.005 USDC cost via x402, the fact that an unpaid call returns a payment challenge instead of data, and that no-data calls are never settled and thus cost nothing. This is valuable operational context an agent needs before invoking the 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 compact and well-structured, front-loading the data content and use case before explaining cost and payment behavior. Every sentence adds useful information, and there is 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?

Given this is a simple no-parameter, no-output-schema tool, the description is complete: it states what data is returned, why to use it, how payment works, and the equivalent HTTP route. No critical information for correct invocation is missing.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter meaning to clarify. The description instead focuses on what the response contains, which is the relevant semantic information for a no-parameter call.

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 returns USDC, USDT, and DAI spot prices against USD plus their peg deviations in basis points. This is a specific, concrete resource and makes it distinct from broader price tools like crypto_spot_prices.

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 explicitly says to use this tool to check whether a stablecoin is holding its dollar peg before settling or holding value in it. It does not name alternative tools or exclusion cases, but the intended context is clear enough for an agent to decide when to call 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 read-only, non-destructive, idempotent, and non-open-world. Description adds key behavioral details not in annotations: stored snapshot freshness (captured_at, age_hours), observation date semantics, payment challenge on unpaid call, no settlement on no data, and index-level (not YoY) interpretation. It doesn't describe return schema (output schema absent) but does warn about payment/HTTP behavior, which is notable. Slight gap on exact response format beyond snapshot fields, but enough for an agent to decide.

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?

Description is dense and well-organized; first sentence defines purpose, second covers freshness, third clarifies index levels, fourth covers cost/payment/HTTP. Information is front-loaded with essentials (metrics, units, snapshot caveat). Some redundancy ('this is a STORED SNAPSHOT' repeated in same sentence) and overuse of dashes/parentheticals, but no waste; could be tightened slightly without loss.

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

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

For a read-only data tool with one optional parameter and no output schema, it covers: purpose (macro data), freshness check, as_of semantics, cost/payment behavior, HTTP alternative, and interpretation caveat (index vs YoY). Lacks explicit note on whether data updates daily or what periods are covered, but the input schema and freshness fields mitigate. Sibling tools provide clear contrast, and the description explicitly says it is not live, which is critical. Missing output schema is a limitation but not critical for decision-making.

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

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

Only one optional parameter 'as_of' is fully described with semantics (stored capture at date/timestamp, append-only history, not subject to freshness limit), format (UTC date or ISO timestamp), and example. Schema description coverage is 100%, and the description adds practical meaning beyond the parameter name and 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?

States a specific verb ('get' implied via 'reads stored data') and resource ('US macroeconomic indicators from the St. Louis Fed'), listing exact metrics (effective federal funds rate, CPI, core PCE, unemployment rate, M2) with units. Scope (latest or as-of date) and cost are clear. It distinguishes itself from sibling tools by covering macro indicators exclusively, leaving FX, crypto, rates, and prediction markets to 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?

Explicitly states when to use it (macro data) and when not to (not live FRED; snapshot may be stale). Notes freshness checks ('check snapshot.captured_at and snapshot.age_hours before relying'), cost, payment failure behavior, and equivalent HTTP route. Clear guidance on as_of for historical data, and distinction from sibling tools for FX/crypto/rates.

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?

Beyond the readOnly/idempotent annotations, the description discloses the snapshot nature, the reason for it (FRED blocks workers), the payment requirement, and the behavior on unpaid calls. This is thorough transparency about how the tool behaves.

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 well-structured: it leads with the data provided, then explains the snapshot nature, then the cost/payment, and finally the equivalent HTTP route. Each sentence adds value without 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?

The description covers the data, snapshot mechanism, cost, and check instructions, which is sufficient for usage. It does not explicitly define the response format, but mentions the snapshot fields, so it's mostly complete. Slightly more detail on the response structure would push it to 5.

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 documents the 'as_of' parameter with a clear description. The tool description adds nothing further about this parameter, so it stays at the baseline. No additional clarity is provided 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 clearly states the resource (US Treasury yields) and lists the specific data points: 2, 10, 30 year yields, 10s2s spread, and mortgage rate. It also clarifies it's a stored snapshot, distinguishing it from live data tools. This is unambiguous and actionable.

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 usage guidance: check snapshot.captured_at and snapshot.age_hours before trading/quotes, explains that it's refreshed out of band due to FRED blocking, and details the payment mechanism (cost, unpaid challenge, no settlement on no data). This helps the agent decide when and how to use it.

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