Crypto prices, gas, DeFi TVL, and live Polymarket odds. x402 pay-per-call, $0.001, no API key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 4 of 4 tools scored. Lowest: 3.3/5.
Each tool targets a distinct data domain: crypto_prices for spot prices, defi_tvl for DeFi TVL, gas_prices for gas fees, and service_info for server details. No overlap in purpose.
All tool names follow a consistent snake_case pattern with two words: crypto_prices, defi_tvl, gas_prices, service_info. Predictable and readable.
4 tools for a real-time crypto data server is well-scoped. Each tool serves a clear and essential sub-domain without being too few or too many.
The set covers core real-time crypto data needs: spot prices, DeFi TVL, gas fees, and service information. No obvious gaps for the stated purpose.
crypto_pricesAInspectReal-time USD spot prices for crypto assets. Accepts major symbols (BTC, ETH, SOL, USDC, USDT, DAI, BNB, XRP, ...), any CoinGecko id as "coingecko:", or any token by ":". Aggregated feed with per-coin confidence score, ~15s freshness. Paid tool: $0.001 per call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| coins | Yes | Assets to price, e.g. ["ETH","BTC","coingecko:solana","base:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides key behavioral traits beyond the schema: it is a paid tool ($0.001 per call via x402), uses an aggregated feed with per-coin confidence score, and has ~15s freshness. No annotations are provided, so the description fully carries this burden and does so thoroughly.
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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value: accepted formats, feed characteristics, pricing. No waste, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return values (confidence score, freshness), pricing, and input formats. It is complete for the complexity of a crypto price tool. No gaps in critical information.
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 covers 100% of parameters, and the description adds significant meaning: it explains accepted formats (major symbols, coingecko:<id>, <chain>:<tokenAddress>), maxItems of 50, and example inputs. This enriches understanding beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real-time USD spot prices for crypto assets. It specifies multiple accepted symbol formats (major symbols, CoinGecko IDs, chain:address), distinguishing it from sibling tools like defi_tvl or gas_prices which serve different purposes.
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 when to use this tool: for real-time USD spot prices of crypto assets. It mentions aggregated feed with confidence score and freshness, and pricing details. Sibling tools are clearly different, so no confusion about when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
defi_tvlAInspectCurrent total value locked (USD) for DeFi protocols by DefiLlama slug (e.g. uniswap, aave, lido). Paid tool: $0.001 per call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| protocols | Yes | DefiLlama protocol slugs, e.g. ["uniswap","aave"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behaviors. It mentions the tool is paid ($0.001 per call), which is a key behavioral trait. However, it does not disclose rate limits, auth requirements, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one for purpose and one for pricing. No redundant text, but could be slightly more structured with separate sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states it returns 'total value locked (USD)', which is adequate. It handles the input array well. Could mention if output is per protocol or aggregated, but sufficient for an agent.
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% (the one parameter is fully described). The description adds practical context by providing example slugs and clarifying they are DefiLlama slugs, which goes beyond the schema's generic 'DefiLlama protocol slugs'.
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 current TVL (USD) for DeFi protocols using DefiLlama slugs, with concrete examples (uniswap, aave, lido). It is distinct from sibling tools like crypto_prices or gas_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?
The description implies use for fetching TVL but does not explicitly state when to use this tool versus alternatives. The pricing note is a usage constraint, but no guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gas_pricesAInspectLive gas across chains (ethereum, base, arbitrum, optimism, polygon): current gas price, next-block base fee, slow/standard/fast priority-fee tiers straight from chain RPC, native token USD price, and the USD cost of a simple transfer so chains compare without unit math. Paid tool: $0.001 per call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| chains | No | Chains to query; omit for all supported chains |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses output fields (gas price, base fee, priority tiers, USD prices) and source (chain RPC). Does not mention read-only nature, rate limits, or caching, but covers key behavioral aspects.
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?
One sentence conveying all key information (chains, output, pricing). Front-loaded with main purpose. Slightly dense but efficient; could be broken into two sentences for readability.
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, but description fully explains return values (gas price, base fee, priority fees, native token price, USD transfer cost). Includes pricing and chains. Complete for a simple query tool with one optional parameter.
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?
Single parameter 'chains' is already well-described in schema with enum values and default behavior. Description adds value by explicitly listing the chains and noting that omission returns all chains, enhancing clarity.
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?
Clear verb+resource: 'Live gas across chains' specifies the action (get gas prices) and the resource (chains: ethereum, base, arbitrum, optimism, polygon). Distinguishes from siblings (crypto_prices, defi_tvl, etc.) by focusing on gas metrics.
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?
States it's a paid tool with cost per call, which guides usage decisions. Lacks explicit when-to-use vs alternatives, but the domain (gas prices) is distinct from siblings, making usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
polymarket_moversAInspectPolymarket prediction markets with the biggest odds swings in the last 24 hours, filtered to liquid markets (default $10k+ daily volume), most-moved first. The fastest way to spot where consensus is shifting. Paid tool: $0.001 per call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max markets to return (default 10) | |
| minVolume24h | No | Ignore markets below this 24h USD volume (default 10000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses pricing ($0.001 per call via x402 on Base) and filtering criteria (liquid markets, default $10k+ daily volume). It doesn't detail return format but covers key behavioral traits. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a pricing note, no wasted words. It front-loads the main purpose and logically presents filtering, ordering, and cost 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 the simple tool and no output schema, the description covers purpose, filtering, ordering, and pricing. It lacks precise definition of 'odds swings' but is sufficient for an agent to select and invoke 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% with descriptions for both parameters. The description reinforces the default for minVolume24h ($10k) but adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Polymarket prediction markets with the biggest odds swings in the last 24 hours, filtered to liquid markets, most-moved first. It uses a specific verb+resource and distinguishes from siblings like polymarket_odds and polymarket_resolving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: 'fastest way to spot where consensus is shifting.' It implies when to use this tool for checking odds swings, and the pricing note adds practical guidance. However, it does not explicitly exclude alternatives or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
polymarket_oddsBInspectLive Polymarket prediction market odds. Search any topic free-text ("fed rate cut", "world cup winner") or fetch one market by its slug. Returns normalized markets: outcomes, prices, bid/ask spread, 24h volume, liquidity, resolution date, and the polymarket.com URL. ~15s freshness. Paid tool: $0.001 per call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Exact Polymarket market slug (alternative to query) | |
| limit | No | Max markets to return (default 10) | |
| query | No | Free-text search across Polymarket markets, e.g. "argentina world cup" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses ~15s freshness, cost ($0.001/call), and payment method (x402), but lacks details on authorization, rate limits, or error handling. Does not contradict any annotations (none).
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 reasonably concise, front-loaded with purpose, and includes examples and return fields. Could be slightly tighter, but no wasted sentences.
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, but description explicitly lists all returned fields (outcomes, prices, spread, volume, liquidity, resolution date, URL). Combined with param schema, provides adequate context for a moderately complex tool. Missing some usage boundaries (e.g., max offset), but acceptable.
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 parameter descriptions. The description adds contextual examples (e.g., 'fed rate cut') and explains the return format, but does not provide meaningful new details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides live Polymarket odds via free-text search or slug lookup, and lists returned fields. It differentiates from siblings (polymarket_movers, polymarket_resolving) implicitly by naming but not explicitly, leaving some ambiguity.
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?
No guidance on when to use this tool versus siblings like polymarket_movers or crypto_prices. Agent must infer from name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
polymarket_resolvingAInspectActive Polymarket prediction markets resolving within the next N hours (default 24), sorted by 24h volume, with live prices. For tracking imminent event outcomes. Paid tool: $0.001 per call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Window in hours (default 24) | |
| limit | No | Max markets to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the paid nature via x402 (cost), but does not explicitly state read-only status, authentication needs, rate limits, or side effects. The default window and sorting are described, but overall disclosure is moderate.
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 one sentence plus a brief payment note. It is highly concise, front-loaded with the core action, and contains no extraneous 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 the tool has no output schema and 2 optional parameters with no annotations, the description provides adequate context: what is returned (markets resolving, sorting, prices), the payment model, and the default window. It is complete for its complexity, though return format details are omitted.
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% (both 'hours' and 'limit' have descriptions in the schema). Baseline is 3. The tool description does not add any additional meaning beyond the schema, so the score remains at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Active Polymarket prediction markets resolving within the next N hours… sorted by 24h volume, with live prices.' It specifies the verb 'resolving' and the resource 'prediction markets', and the focus on imminent outcomes distinguishes it from sibling tools like polymarket_movers and polymarket_odds.
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 indicates usage is 'for tracking imminent event outcomes,' providing clear context. However, it does not explicitly state when not to use this tool versus alternatives like polymarket_movers or polymarket_odds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
service_infoBInspectFree. Service, pricing, and payment details for the chainpulse tools on this server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the tool is 'Free', indicating no cost, but does not disclose whether authentication is required, rate limits, or if any side effects exist. Minimal behavioral disclosure for a tool that likely returns safe, read-only 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?
Single sentence front-loaded with 'Free.' is efficient. However, it is somewhat terse and could be slightly more descriptive without becoming verbose. The structure is clear and to the point.
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 parameterless tool with no output schema, the description provides basic context but lacks specifics on what aspects of service/pricing/payment are returned. It is adequate but leaves ambiguity about the exact output format or contents.
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?
Input schema has zero parameters (100% coverage). The description adds context by explaining the tool's purpose (service/pricing/payment details), which helps the agent understand the output nature. However, it does not add meaning beyond what the schema already indicates (no params). 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 states it provides 'Service, pricing, and payment details for the chainpulse tools on this server.' It identifies the resource (chainpulse tools) and type of information (pricing, payment), distinguishing it from sibling tools that cover external data. However, it lacks a specific verb like 'retrieve' and could be more precise about what 'details' entails.
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?
No explicit guidance on when to use this tool versus siblings. The context of sibling tools (crypto prices, DeFi TVL, etc.) implies this is for internal service info, but the description does not state when to choose it or when not to use it. Implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!