MangroveAI

get_onchain_series

Read-onlyIdempotent

Per-bar on-chain metric time series for a token. One request returns a bar-indexed series with any combination of SmartMoneyNetflow, SmartMoneyHoldings, ExchangeNetflow, WhaleNetInflow and HolderConcentration. Interval is 1h, 4h, 1d or 1w; top_n is how many top holders HolderConcentration sums; the only provider is nansen. Native ETH is read as WETH, and the token must be deployed on the chain asked for. The window defaults to the last 10 days and is at most 366 days; a window that would exceed 1,000 bars is read at the next coarser interval instead (1h, 4h, 1d, 1w), and interval says which was used. Prefer this over firing many point queries when the user wants a historical or trailing-window view.

[Access: pay 0.05 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "metrics": "<metrics>",
      "symbol": "<symbol>"
    },
    "name": "get_onchain_series"
  }
}

Input Schema

Name	Required	Description	Default
`chain`	No	Chain name or slug, e.g. ethereum or base.	ethereum
`top_n`	No	Return only the first this many.
`symbol`	Yes	Asset symbol, e.g. BTC or ETH.
`date_to`	No	ISO date string for the end of the window.
`metrics`	Yes	Metric names to include in the series.
`interval`	No	Candle size, e.g. 15m, 1h, 4h, 1d.	1h
`provider`	No	Optional upstream override; omitted uses the existing server default.
`date_from`	No	ISO date string for the start of the window.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the default 10-day window, the 366-day cap, automatic interval coarsening when the window exceeds 1,000 bars with the actually-used interval echoed back, the WETH substitution for native ETH, the requirement that the token be deployed on the requested chain, and the two payment/auth paths (0.05 USDC via x402 or API key). These are exactly the operational facts an agent needs before calling.

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

Conciseness4/5

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

Front-loaded with the core behavior, then constraints, then routing advice; nearly every clause carries operational meaning. The bracketed access/payment block is dense and slightly tangential to tool selection, but it is still decision-relevant.

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?

With 8 parameters, no output schema, and strong annotations, the description covers behavior, limits, and access fully. The only gap is that the shape of the returned bar-indexed series (field names per metric, timestamp key) is left implicit beyond 'interval says which was used'.

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 coverage is 100%, so baseline is 3, but the description earns more: it redefines top_n as the number of top holders summed into HolderConcentration (the schema's 'return only the first this many' is misleading), constrains interval to 1h/4h/1d/1w versus the schema's mention of 15m, and states nansen is the only provider despite the schema's generic 'override'. The remaining params (symbol, date_from/date_to, chain) are left to the schema.

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

Purpose5/5

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

Opens with a specific verb+resource+granularity ('Per-bar on-chain metric time series for a token') and enumerates the five metrics it can return in one call. The closing sentence positions it against the point-query siblings (get_smart_money_netflows, get_token_flows, etc.), so an agent can distinguish it without opening the schema.

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

Usage Guidelines4/5

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

Explicitly says to prefer this over many point queries when the user wants a historical or trailing-window view, which is a real routing rule. It does not name the specific sibling tools it replaces or state exclusions (e.g. single-point current snapshots), so it stops short of a 5.

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

All MangroveAI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.