Skip to main content
Glama

47620 Multichain On-chain Data API

snapshot

Whole-network picture in ONE call: cluster health, slot/epoch (Solana) or chain status (EVM), native/USD price and top trending pairs. chain -> /x/solana/snapshot | /x/base-fac/snapshot | /x/polygon-fac/snapshot. Pay-per-call ($0.01 USDC).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesChain to query

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / chain
      Added value: +{
      +  "description": "Chain to query",
      +  "enum": [
      +    "solana",
      +    "base",
      +    "polygon"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / required
      Added value: +[
      +  "chain"
      +]
  2. First observed

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses pay-per-call cost ($0.01 USDC) and the data returned, but does not state that the operation is read-only, nor describe auth requirements, rate limits, or error behavior.

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

Conciseness4/5

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

The description is front-loaded with the core benefit ('Whole-network picture in ONE call') and uses compact sentences. Endpoint mapping and cost are included efficiently, with little wasted language.

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

Completeness4/5

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

For a one-parameter query tool with no output schema and no annotations, the description explains what data is returned, the per-call cost, and the endpoint mapping. It is complete enough to select and invoke correctly, though it omits usage alternatives.

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

Parameters4/5

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

Schema description coverage is 100%, giving a baseline of 3. The description adds value by mapping each enum value to a specific endpoint path, clarifying chain-specific behavior beyond the schema's 'Chain to query' text.

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

Purpose4/5

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

The description states a clear resource and scope: a whole-network snapshot containing cluster health, chain status, price, and trending data. It distinguishes itself from narrower sibling tools through the phrase 'in ONE call', though it does not explicitly name the siblings it aggregates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Whole-network picture in ONE call' implies usage for an aggregated overview rather than topic-specific calls, but no explicit when-to-use, when-not-to-use, or alternative tools are named. Sibling tools like health, trending, and solana_health are left unaddressed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.