Prices and rates that state when they were observed, so you know what you are trusting.
Current Base mainnet gas price read live from JSON-RPC, in both wei and gwei. Use this to estimate the cost of a Base transaction before submitting it. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /gas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Coinbase spot price in USD for up to ten crypto assets. Use this for a current crypto price. Returns an explicit per-symbol error rather than a guessed number when an asset is unavailable. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /crypto.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | No | Comma-separated asset symbols (default BTC,ETH,SOL) Example: 'BTC,ETH'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the payment model ($0.005 USDC per call via x402), the unpaid-call behavior (payment challenge instead of data), and the no-data no-settlement policy. It also explains that unavailable assets produce explicit per-symbol errors rather than guessed numbers, adding genuinely useful behavioral context.
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 and front-loaded: purpose, then usage, then error behavior, then cost and payment details. Every sentence delivers distinct, valuable information with no filler or tautology.
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, intended usage, error semantics, cost and payment failure modes, and the equivalent HTTP route. The absence of an output schema is acceptable because the first sentence makes clear that the tool returns current Coinbase prices in USD, and the annotations cover safety characteristics.
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 fully documents the optional `symbols` parameter with a default and example, so baseline is 3. The description adds meaningful extra constraints: 'up to ten crypto assets' and the per-symbol error behavior for unavailable assets, which help the agent set expectations 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 opens with a specific verb-resource pair: 'Coinbase spot price in USD for up to ten crypto assets,' which clearly states what the tool returns and the source. The line 'Use this for a current crypto price' reinforces the purpose and helps distinguish it from related sibling tools like defi_token_prices or 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?
The description explicitly says 'Use this for a current crypto price,' giving clear usage context. However, it does not name sibling alternatives or specify when not to use this tool, stopping 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.
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. Use it to compare chains by capital deployed or to check where a chain sits. A chain with no published TVL keeps a null figure and is excluded from the total rather than counted as zero. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /defi/chains.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return, 1-100 (default 25) Example: '25'. | |
| search | No | Chain name substring Example: 'Base'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with strong annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description adds valuable behavioral context: null TVL is excluded from totals rather than counted as zero, each call costs $0.005 USDC, unpaid calls return a payment challenge, and no-data calls are never settled. This goes well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core resource definition and ranking behavior, then adds use case, null handling, payment details, and an HTTP equivalent. Every sentence carries useful, non-redundant information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description carries the burden of explaining what the tool returns, and it does so thoroughly: chain TVL, ranking order, token symbol, EVM chain id, cross-chain total, and null handling. Payment behavior and route equivalence further complete the picture for an agent deciding whether and how to call this 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?
Schema description coverage is 100%, so the input schema already fully documents both limit and search parameters. The description adds no parameter-specific details beyond the schema, such as search case-sensitivity or default limit behavior, but it is not required to compensate for any schema gap here.
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 that this tool returns total value locked per blockchain from DefiLlama, ranked high to low, and lists the key returned fields (native token symbol, EVM chain id, cross-chain total). It is immediately distinguishable from sibling tools like defi_protocols or defi_yields by focusing specifically on chain-level TVL 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 gives explicit use cases: compare chains by capital deployed or check where a chain sits in the ranking. It does not name alternative tools or state when not to use it, but the context is clear enough for an agent to select it for chain-level TVL comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full DefiLlama detail for one protocol by slug: current TVL in USD with its observation time, per-chain TVL breakdown, category, token symbol, chain list, description and links. Use it after finding a slug with the protocols list. An unknown slug returns an honest not_found and is not billed. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /defi/protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | DefiLlama protocol slug (required) Example: 'aave-v3'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond those hints: cost of $0.005 USDC via x402 on Base, unpaid calls returning a payment challenge, no data being never settled, and unknown slugs returning an honest not_found. This is highly valuable for an agent to avoid surprise billing and understand failure semantics.
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 with no filler: it states what the tool returns, when to use it, how billing and errors behave, and the equivalent HTTP route. Every sentence adds distinct, decision-relevant information, and the most critical usage guidance appears 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?
Despite having no output schema, the description compensates by enumerating the returned fields and covering billing, payment challenge behavior, no-data settlement, and unknown-slug handling. For a single-parameter read-only lookup, this gives an agent everything needed to call it and interpret the result.
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 fully documents the single parameter 'slug' with an example, so coverage is 100%. The description reinforces that slug is the lookup key and describes what happens for unknown slugs, but it does not add new format or syntax guidance beyond what the schema provides. Baseline of 3 is appropriate given full 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 states a specific operation: it returns 'Full DefiLlama detail for one protocol by slug' and enumerates the response fields (current TVL, per-chain breakdown, category, token symbol, chain list, description, links). It also distinguishes itself from the sibling defi_protocols by emphasizing the singular 'one protocol' and '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?
The description explicitly says 'Use it after finding a slug with the protocols list', which gives clear sequencing and directs agents to first obtain a slug. It does not name defi_protocols as the alternative tool explicitly, but 'protocols list' is recognizable enough. It could be stronger with an explicit when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank DeFi protocols by total value locked from DefiLlama, filtered by chain, category or name substring, with each protocol's slug, category, chain list, TVL in USD, 1d/7d TVL change and market cap. Use it to size a protocol, find the biggest venues on a chain, or resolve the slug the protocol-detail tool needs. A protocol DefiLlama publishes no TVL for keeps a null figure, never a zero. Read live at request time and held for 5 minutes. Costs $0.008 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /defi/protocols.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Only protocols deployed on this chain Example: 'Base'. | |
| limit | No | How many to return, 1-100 (default 20) Example: '20'. | |
| search | No | Name or slug substring Example: 'aave'. | |
| category | No | Exact DefiLlama category Example: 'Lending'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. The description adds high-value behavioral details beyond those: null instead of zero TVL, 5-minute caching, x402 payment mechanics on Base, unpaid calls returning a payment challenge, and no settlement on empty data. This is rich, non-redundant 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 dense but every sentence carries operational value: purpose, filters, use cases, null handling, caching, cost, payment failure behavior, and the HTTP equivalent. It front-loads the core function and keeps the details organized without fluff.
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?
Even though there is no output schema, the description enumerates the returned fields, explains the null-vs-zero convention, and covers caching, cost, payment challenges, and failure semantics. For a paid, externally sourced tool with no output schema, this is enough for an agent to call it and interpret results.
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 every parameter already has a clear description with examples. The tool description reinforces that filtering is by chain, category, or name substring, but it doesn't add meaningful per-parameter semantics beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: ranks DeFi protocols by TVL from DefiLlama, with explicit filter dimensions (chain, category, name substring) and return fields. The description also distinguishes it from the protocol-detail sibling by noting it can resolve the slug that the detail tool needs.
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?
Gives explicit use cases: sizing a protocol, finding the biggest venues on a chain, and resolving slugs for the protocol-detail tool. It doesn't enumerate when-not-to-use conditions against all siblings, but the context and naming are enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price arbitrary on-chain tokens with DefiLlama's coins API, addressed as chain:address (or coingecko:id), returning price in USD, symbol, decimals, a confidence score and the pricing timestamp for each. Use it to value a DeFi position holding tokens no exchange lists. This is NOT the exchange spot-price tool: use the crypto spot tool for a plain price of a major asset. A token DefiLlama cannot price inside search_width returns null, never a substituted price. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /defi/token-prices.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | Comma-separated DefiLlama coin ids as chain:address or coingecko:id, up to 20 (required) Example: 'base:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913,coingecko:ethereum'. | |
| search_width | No | How far back a price may be taken from (default 6h) Example: '6h'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description adds substantial context beyond them: unpriced tokens return null rather than a substituted price, unpaid calls return a payment challenge, and no-data calls are never settled. These edge cases are crucial for correct invocation and interpretation.
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 serves a purpose: it identifies the tool, its use case, its output, its relation to a sibling tool, null behavior, cost model, and equivalent HTTP route. No filler or repetition exists, and the most important identifying 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 paid, read-only data tool with no output schema, the description covers the essential context: input format, output fields, pricing failure mode, null behavior, and alternative routing. An agent has enough information to call it correctly and interpret results in the context of the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by restating the chain:address / coingecko:id addressing convention and clarifying the search_width semantics by explaining that tokens not priced within that window return null. It slightly reinforces the schema without fully compensating for the missing required-field indication, but it remains useful.
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 ('Price arbitrary on-chain tokens') and resource ('DefiLlama's coins API'), and explains the addressing scheme and output fields. It also explicitly distinguishes itself from the crypto spot-price tool, so an agent can tell them apart without inspecting schemas.
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 a clear use case ('value a DeFi position holding tokens no exchange lists') and an explicit when-not-to-use statement with the alternative tool ('use the crypto spot tool for a plain price of a major asset'). It also explains relevant cost and failure behavior, which helps the agent decide whether to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen DefiLlama's yield-pool universe by chain, project, token symbol, minimum TVL and stablecoin-only, ranked by APY, returning each pool's stable pool_id, chain, project, symbol, TVL in USD, total/base/reward APY, 30-day mean APY, impermanent-loss risk and exposure. Use it to find where a given asset earns yield. An unpublished APY stays null, never zero. Costs $0.008 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /defi/yields.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Only pools on this chain Example: 'Base'. | |
| limit | No | How many to return, 1-100 (default 20) Example: '20'. | |
| symbol | No | Token symbol substring Example: 'USDC'. | |
| project | No | Only pools from this DefiLlama project Example: 'aave-v3'. | |
| min_tvl_usd | No | Minimum pool TVL in USD (default 1000000) Example: '1000000'. | |
| stablecoin_only | No | Only stablecoin pools Example: 'true'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses non-obvious behavior: unpublished APY stays null rather than zero, each call costs $0.008 USDC on Base via x402, unpaid calls return a payment challenge, and no-data calls are not settled. 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?
Several dense sentences, front-loaded with functionality and returned fields before payment/settlement details. There is no filler; even the cost and HTTP-route notes are valuable for an expensive, pay-per-call API.
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 present, the description enumerates the key returned fields, explains null APY semantics, and discloses cost and settlement behavior. Combined with the 100% schema coverage and annotations, an agent has enough context to invoke 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?
The input schema covers all six parameters at 100% with examples and defaults, so the baseline is 3. The description restates the filter concepts and adds 'ranked by APY,' but it does not carry additional parameter-level semantics 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?
States an exact action ('Screen DefiLlama's yield-pool universe'), enumerates the filtering dimensions and returned fields, and closes with the user goal ('find where a given asset earns yield'). This clearly distinguishes it from sibling price, protocol, and chain 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?
Gives a direct use case: 'Use it to find where a given asset earns yield.' It does not explicitly name alternatives or exclusion conditions, but the stated context is clear enough for an agent to choose this tool for yield-pool screening.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
European Central Bank reference foreign-exchange rates for a chosen base currency, with the ECB observation date. Refreshed automatically by a Worker cron from Frankfurter. These are daily reference rates, not live tradable quotes, and every response carries snapshot.captured_at and snapshot.age_hours. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /fx.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency ISO-4217 (default USD) Example: 'USD'. | |
| as_of | No | Return the stored capture in effect at this UTC date or ISO timestamp instead of the latest one (append-only history; not subject to the freshness limit) Example: 'undefined'. | |
| symbols | No | Comma-separated target currencies Example: 'EUR,GBP,JPY'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the cron refresh mechanism, the daily/reference nature, the response fields `snapshot.captured_at` and `snapshot.age_hours`, the per-call cost, the payment challenge on unpaid calls, and that no-data calls are never setted. That is comprehensive behavioral disclosure for a read-only data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earns its place: first defines the resource, second explains data nature and freshness fields, third explains cost and payment behavior plus the equivalent HTTP route. It is front-loaded with purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers freshness, payment/settlement behavior, and the key response fields, which matters because there is no output schema. It omits the precise rate-mapping format, but the core semantics are complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both `base` and `as_of` already have clear schema-level descriptions. The tool description adds only marginal input-relevant context, such as 'chosen base currency' and 'ECB observation date', but does not meaningfully compensate or extend parameter semantics beyond what the schema 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 identifies a specific resource — European Central Bank reference foreign-exchange rates for a chosen base currency — and explains that these are daily reference rates, not live tradable quotes. This makes the tool distinct from the crypto/defi/treasury siblings and leaves no doubt about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when official ECB daily reference rates are needed, with freshness information. It also explicitly excludes live tradable quotes, which is a key usage boundary. It does not name alternative sibling tools or provide when-not-to conditions beyond the 'not live' qualifier, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or browse Manifold Markets questions, returning each one's probability, outcome type, volume, liquidity, unique bettor count, close time, creator and resolution state. Manifold is a PLAY-money venue denominated in MANA, so treat a probability as a crowd forecast rather than a real-money price; every response says so and reports the token. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /manifold/markets.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | score, newest, liquidity, close-date or most-popular Example: 'score'. | |
| limit | No | How many markets, 1-50 (default 10) Example: '10'. | |
| filter | No | all, open, closed or resolved (default open) Example: 'open'. | |
| search | No | Question text to search for Example: 'bitcoin'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints, lowering the burden. The description goes well beyond this by disclosing the real cost per call ($0.005 USDC), the x402 payment mechanism, the unpaid-call behavior, the no-data-no-cost guarantee, and the play-money/MANA token semantics. This is rich, actionable behavioral context that structured fields could not convey.
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 main function is front-loaded in the first sentence, followed by essential caveats (play-money, cost, payment failure mode) and an HTTP equivalent. Each sentence carries distinct information, and there is no redundant or filler 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?
Here we have no output schema, so the description carries the full burden of explaining returns; it does so by listing all returned fields. It also covers payment cost, the no-cost-on-no-data behavior, token reporting, and the HTTP route. For this simple read-only listing tool, everything needed to invoke and interpret the response is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (sort, limit, filter, search) are already documented with examples. The description adds no additional parameter-level meaning beyond implying that 'search' maps to question text, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search or browse Manifold Markets questions', and enumerates the exact returned fields (probability, outcome type, volume, liquidity, unique bettor count, close time, creator, resolution state). This clearly distinguishes it from sibling Polymarket and prediction-market tools by naming the Manifold venue, making the tool's 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 makes it clear the tool is for Manifold Markets questions, giving an agent sufficient context to select it when Manifold-specific data is needed. However, it does not explicitly name alternatives or state when not to use it, such as directing to polymarket_markets for Polymarket or prediction_market_search for cross-venue searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Polymarket events — the grouped questions such as an election or a rate decision — ordered by volume, each with title, slug, end date, volume, 24h volume, liquidity, open interest, its full market count and the priced member markets themselves. Use it when a question has many candidate outcomes and you want them together rather than one at a time. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /polymarket/events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many events, 1-25 (default 5) Example: '5'. | |
| closed | No | Return closed events instead of open ones Example: 'false'. | |
| ascending | No | Sort ascending instead of descending Example: 'false'. | |
| markets_per_event | No | Member markets per event, 1-25 (default 5) Example: '5'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Alongside strong annotations (readOnly, openWorld, idempotent, non-destructive), the description adds valuable behavioral details: per-call cost, the x402 payment mechanism, the payment-challenge response for unpaid calls, and the no-data-no-settlement guarantee. This exceeds the annotations' coverage and helps the agent anticipate real call outcomes.
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 longer than average but remains dense and purposeful: it front-loads the tool's function, then the use case, then cost and failure behavior, then the HTTP route. Each sentence adds distinct value, though a slightly tighter wording could improve scannability.
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 carefully enumerates the response fields (title, slug, end date, volume, 24h volume, liquidity, open interest, market count, member markets), making the return shape understandable. It also covers cost, failure semantics, the no-data-cost guarantee, and the HTTP route, so an agent has everything needed to call and interpret this 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?
The input schema already describes all four parameters with 100% coverage, including defaults and ranges, so the description need not repeat them. The description does mention ordering by volume, which relates to the default sort behavior, but does not add further parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Polymarket events') and defines events as grouped questions such as an election or rate decision, distinguishing them from individual markets. It also enumerates the returned fields, making the tool's scope and output immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it when a question has many candidate outcomes and you want them together rather than one at a time, which gives clear context. It implies alternatives (individual market tools) but does not name them explicitly, and it omits explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polymarket's public trader leaderboard by traded volume or realised profit over a 1d, 7d, 30d or all-time window, returning each trader's rank, published pseudonym and display name, wallet address and USDC amount. Use it to find who is moving size on the venue. A trader who publishes no name stays null; no name is inferred. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /polymarket/leaderboard.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many traders, 1-50 (default 10) Example: '10'. | |
| metric | No | volume or profit (default volume) Example: 'volume'. | |
| window | No | 1d, 7d, 30d or all (default 7d) Example: '7d'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds valuable behavioral context beyond them: the $0.005 USDC x402 payment requirement, the unpaid-call challenge behavior, the no-data/no-cost guarantee, and the null pseudonym behavior. It also discloses the equivalent HTTP route. 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 earns its place: scope and return fields, use case, null handling, payment and failure semantics, and HTTP route. The core purpose is front-loaded, and nothing is redundant.
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 compensates by listing the returned fields. It fully explains invocation-relevant side effects such as payment, unpaid responses, and the no-data/no-cost rule. For a 3-parameter optional-parameter read-only tool with full schema coverage, this description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions, defaults, and examples for all three parameters: limit, metric, and window. The description's mention of 'volume or realised profit' and '1d, 7d, 30d or all-time' does not add meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Polymarket trader leaderboard), the core sorting metrics (traded volume or realised profit), the available windows, and the returned fields. It distinguishes this tool from siblings like polymarket_trades or polymarket_markets by focusing specifically on leaderboard rankings rather than market or trade 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?
The description gives a clear use case: 'Use it to find who is moving size on the venue.' It does not explicitly name alternative tools or state when not to use it, but the context is strong enough that an agent can infer when this leaderboard is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Polymarket market by Gamma id, slug or condition id, with its full outcome pricing and the LIVE CLOB order book for each outcome token: best bid, best ask, midpoint, spread and the top price levels with sizes. Use it before taking a position, to see real depth rather than only a last price. An outcome with no order book returns a null book rather than a fabricated price; an unknown identifier returns not_found and is not billed. Costs $0.008 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /polymarket/market.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Polymarket Gamma market id Example: '908713'. | |
| slug | No | Market slug, if you have no id Example: 'fed-rate-hike-in-2026'. | |
| depth | No | Order-book levels per side, 1-20 (default 5) Example: '5'. | |
| condition_id | No | Full 0x-prefixed 32-byte condition id (66 chars), as returned by the markets/events/search tools Example: '0xf708d6652a477c59d7da116df8ff3d393b993e7037367b96cc33aa519cb48354'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent hints, the description discloses specific behaviors: a null order book is returned if none exists (rather than fabricating a price), an unpaid call returns a payment challenge, and calls returning no data are never settled. This goes beyond the annotation hints and clarifies 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 well-structured in a few sentences, each adding essential information about the return, usage context, and error handling. It is concise yet thorough, with no redundant or filler 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 the absence of an output schema, the description thoroughly explains what the output contains (outcome pricing and order book details) and how edge cases are handled (null book, unpaid call, no data). It also covers the cost and settlement behavior, making it complete for an agent to decide when and how to invoke the 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 schema already provides detailed descriptions for each of the four optional parameters, with examples. The tool description reinforces that these are alternative identifiers (gamma id, slug, condition id) and clarifies the depth parameter usages, adding slight context beyond the schema descriptions.
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 fetches a single Polymarket market by Gamma id, slug, or condition id, and returns outcome pricing and a live CLOB order book. It is specific and distinguishes from related tools by focusing on real order book depth rather than just last price.
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 guidance to use this tool before taking a position to see real market depth, contrasting with only a last price. It also explains the cost (0.008 USDC via x402 on Base), potential payment challenge, and settlement behavior when no data is returned, covering practical usage considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List live Polymarket markets ordered by volume or liquidity, each with its question, Gamma id, condition id, every outcome with its USDC price and CLOB token id, best bid/ask, last trade price, volume, liquidity and end date. Use it to see what the largest real-money prediction markets are pricing right now. Prices are probabilities between 0 and 1. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /polymarket/markets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many markets, 1-50 (default 10) Example: '10'. | |
| order | No | volumeNum, liquidityNum, startDate or endDate Example: 'volumeNum'. | |
| closed | No | Return closed markets instead of open ones Example: 'false'. | |
| ascending | No | Sort ascending instead of descending Example: 'false'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds important behavior beyond that: the $0.005 USDC cost per x402 call, the unpaid call returning a payment challenge, and the rule that a call returning no data is never settled. It also clarifies that prices are probabilities in the 0-1 range.
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 earns its place: returned fields, use case, probability semantics, payment behavior, and equivalent HTTP route. The most decision-relevant content is front-loaded, with payment/route details kept until the end.
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?
Since there is no output schema, the description compensates by enumerating the response fields directly: question, Gamma id, condition id, each outcome's USDC price and CLOB token id, best bid/ask, last trade price, volume, liquidity, and end date. It also covers sorting, closed-market behavior, and the payment/failure model, making the tool safe and correctly invokable without external 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?
Schema description coverage is 100%, so parameter details like limit range, allowed order values, and closed/ascending flags are already fully documented. The description adds only the high-level sort intent ('ordered by volume or liquidity') and does not provide extra per-parameter meaning beyond what the schema already gives.
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: 'List live Polymarket markets ordered by volume or liquidity,' and enumerates the returned fields. It also frames the tool's value as showing 'what the largest real-money prediction markets are pricing right now,' which distinguishes it from singular-market, event, and trade siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a direct use case ('Use it to see what the largest real-money prediction markets are pricing right now') and clear context for market-wide listing and sorting. It does not explicitly contrast itself with siblings like polymarket_events, polymarket_market, or prediction_market_search, so the routing guidance is good but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent public trade prints for one Polymarket market, addressed by its condition id: timestamp, side, outcome, price, size, notional in USD, the trader's published pseudonym and wallet, and the transaction hash. Use it to see whether a quoted price is actually trading and who is behind the flow. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /polymarket/trades.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many trades, 1-100 (default 20) Example: '20'. | |
| market | No | Full 0x-prefixed 32-byte condition id (66 chars) of the market, as returned by the markets/events/search tools (required) Example: '0xf708d6652a477c59d7da116df8ff3d393b993e7037367b96cc33aa519cb48354'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent), the description discloses the $0.005 USDC per-call cost, the payment challenge behavior for unpaid calls, and that no data means no cost. It also lists the output fields, providing transparency about what to expect.
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 each sentence serves a purpose: stating the result, the use case, and the cost/technical details. It is well-structured and avoids unnecessary fluff, though it could be slightly more compact.
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 two-parameter tool, the description covers input (condition id), output fields, cost, and a use case. It doesn't specify the exact response format, but given the lack of an output schema, this is acceptable. Overall, it provides enough context for correct usage.
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 full descriptions for both parameters (limit range and full condition id format with examples). The description repeats these without adding new semantic meaning, so it aligns with the baseline for 100% 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 it retrieves recent public trade prints for a specific Polymarket market, specifying the key identifier (condition id) and the output fields. It distinguishes itself from sibling tools by focusing on trades rather than events, markets, or other 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?
It provides a concrete use case ('see whether a quoted price is actually trading and who is behind the flow') and mentions cost and payment behavior, which informs when to use it. While it doesn't explicitly contrast with alternative tools, the use case is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a prediction market by question text across two venues at once — Polymarket (USDC, real money) and Manifold (MANA, play money) — returning a single normalised list with the venue, its currency, the question, the YES probability, volume, end date and a direct URL, plus a per-venue status so a venue that failed is visible rather than silently dropped. Use it when you know the question but not the venue or the id. Kalshi is deliberately not included: its API answers Cloudflare Workers with HTTP 429 on every attempt. Costs $0.008 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /prediction-markets/search.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Question text to search for (required) Example: 'fed rate'. | |
| venues | No | Comma-separated subset of polymarket,manifold Example: 'polymarket,manifold'. | |
| limit_per_venue | No | Results per venue, 1-20 (default 5) Example: '5'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-desstructive, and the description adds substantial further behavioral context: per-venue status so failures are visible, payment mechanics ('$0.008 USDC per call via x402 on Base'), challenge behavior on unpaid calls, zero cost for no-data calls, and the Kalshi 429 issue. It also provides the equivalent HTTP route. 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?
Every sentence earns its place: purpose and output fields, use case, Kalshi exclusion, cost and payment behavior, HTTP route. It is longer than average but density is high, and the most important information is front-loaded. The structure flows logically from what -> when -> caveats -> cost.
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 monetized cross-venue search tool with no output schema, the description covers return fields, failure semantics, payment flow, cost, and routing. An agent has all information needed to invoke the tool correctly and interpret results, even without seeing anything else.
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%, with each parameter (q, venues, limit_per_venue) already documented with types, defaults, and examples. The description adds no new parameter-level meaning; it mostly restates the purpose. Per the baseline for full schema coverage, 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: 'Find a prediction market by question text across two venues at once', and details the exact normalized output fields. It clearly distinguishes itself from single-venue sibling tools by explicitly saying 'Use it when you know the question but not the venue or the id.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use condition ('when you know the question but not the venue or the id') and a concrete exclusion ('Kalshi is deliberately not included' with a reason). This effectively instructs the agent to prefer single-venue siblings when the venue is already known, without naming them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USDC, USDT and DAI spot price against USD plus each one's peg deviation in basis points. Use this to check whether a stablecoin is holding its dollar peg before settling or holding value in it. Costs $0.005 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /stablecoin.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
US macroeconomic indicators from the St. Louis Fed (FRED): effective federal funds rate in percent, CPI and core PCE index levels, unemployment rate in percent, and M2 money stock, each with its own observation date. IMPORTANT: this is a STORED SNAPSHOT, not a live read of FRED at request time — fred.stlouisfed.org blocks Cloudflare Workers (HTTP 520), so the snapshot is refreshed out of band. Every response carries snapshot.captured_at and snapshot.age_hours; check them before relying on the figures, and read as_of for the underlying observation date. CPI/PCE/M2 are index levels, not year-over-year rates. Costs $0.01 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /macro.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Return the stored capture in effect at this UTC date or ISO timestamp instead of the latest one (append-only history; not subject to the freshness limit) Example: '2026-08-11'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description substantially exceeds the annotations by disclosing the stored-snapshot behavior, the FRED HTTP 520 limitation, the need to check snapshot.captured_at and age_hours, the fact that CPI/PCE/M2 are index levels rather than year-over-year rates, and the x402 payment mechanics. This provides critical behavioral context beyond readnoly/idempotent hints and contradicts nothing.
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 longer than average but every sentence earns its place: it leads with the data content, then the critical snapshot caveat, then freshness guidance, index-level semantics, payment behavior, and an equivalent HTTP route. The IMPORTANT marker highlights the key operational constraint and the structure is well 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?
Even without an output schema, the description tells the agent what response metadata to watch (snapshot.captured_at, snapshot.age_hours, as_of), that the data is a snapshot rather than live, the limitations of the FRED source, and the payment/cost model. This is sufficient for an agent to decide whether and how to invoke the 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 sole parameter 'as_of' is already fully explained in the schema, so the baseline score of 3 applies. The description adds a brief note about reading 'as_of' for the underlying observation date, but this is slightly ambiguous as to whether it refers to the request or response field and provides little extra clarity over 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 identifies the tool as providing US macroeconomic indicators from the St. Louis Fed (FRED) and enumerates the specific series (federal funds rate, CPI, core PCE, unemployment, M2). This makes the resource unmistakable and distinct from the crypto, defi, and prediction-market siblings, though it lacks an explicit verb like 'retrieve' or 'get'.
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 by listing the exact indicators and their semantics, but it does not explicitly state when to prefer this tool over alternatives or mention any sibling tools. The guidance is mostly about snapshot behavior and cost, not about selection versus alternates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US Treasury constant-maturity yields for the 2, 10 and 30 year tenors in percent, the computed 10s2s curve spread with an explicit inverted flag, and the 30-year fixed mortgage rate. IMPORTANT: this is a STORED SNAPSHOT, not a live read — the FRED host blocks Cloudflare Workers (HTTP 520), so it is refreshed out of band. Every response carries snapshot.captured_at and snapshot.age_hours; check them before trading or quoting off these numbers. Costs $0.01 USDC per call via x402 on Base; an unpaid call returns the payment challenge instead of data, and a call that returns no data is never settled so it costs nothing. Equivalent HTTP route: GET /rates.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Return the stored capture in effect at this UTC date or ISO timestamp instead of the latest one (append-only history; not subject to the freshness limit) Example: '2026-08-11'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: it is a stored snapshot, refreshed out of band due to FRED blocking Cloudflare Workers, and responses include snapshot.captured_at and snapshot.age_hours. It also discloses the $0.01 USDC cost, payment challenge behavior, and no-data-no-charge guarantee. This aligns with and enriches readOnlyHint and idempotentHint.
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?
Every sentence earns its place: content summary, snapshot freshness warning, cost/payment behavior, and equivalent HTTP route. The most important caveat is marked IMPORTANT and appears early, and the length is justified by the critical operational details.
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 does enough by naming the exact data series, the snapshot metadata fields, the freshness check, and payment semantics. The optional as_of behavior is fully covered in the schema. An agent has enough context to invoke the tool and interpret the result 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% for the single optional as_of parameter, including format and an example, so the schema carries the parameter semantics. The tool description does not add parameter-specific meaning, but the snapshot context helps clarify what 'capture in effect' means. 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 precisely enumerates the returned data: 2/10/30-year constant-maturity yields, the 10s2s spread with inverted flag, and the 30-year mortgage rate. This clearly distinguishes it from sibling tools like fx_reference_rates and defi_yields, although it lacks an explicit verb like 'returns'.
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?
Usage context is implied by the data content, and the snapshot warning tells users to check freshness before trading or quoting. However, it does not explicitly state when to prefer this tool over sibling data tools, name alternatives, or specify exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Real-time & historical crypto and fiat exchange rates, median-aggregated from multiple sources.
Live US savings, CD, mortgage & HELOC rates with source + timestamp on every figure.
One public fact when you have no API key: where, what time, what rate. 31 lookups.
Free, source-labeled FX rates: 465 pairs across 31 currencies, majors update ~60s intraday.
Add one secure layer between your agents and this server.
Most tools target distinct resources: defi_protocol vs defi_protocols are clearly list-vs-detail, and crypto_spot_prices vs defi_token_prices are explicitly differentiated. The main overlap is prediction_market_search vs polymarket_markets/manifold_markets, but the cross-venue purpose is clearly stated.
All tool names use snake_case with a consistent resource-noun pattern (defi_, polymarket_, us_, etc.). Plural/singular variants are logical (defi_protocol vs defi_protocols, polymarket_market vs polymarket_markets), and no unconventional casing or verb-style mixing appears.
18 tools is slightly above the ideal 3-15 range, but the server covers a broad domain (crypto, DeFi, prediction markets, macro, FX, rates), so each tool serves a distinct data type. The count feels justified by the breadth rather than redundant.
The surface covers major market intelligence categories well: prices, yields, TVL, prediction markets, macro indicators, and FX. Minor gaps exist (e.g., no equities/commodities, limited macro series, no historical crypto data), but the core workflows for macro and market overview are supported without dead ends.
