Skip to main content
Glama
Sign In

BytNode

by com.bytnode.api
OverviewDiscussionsAdmin

Get Onchain Data

get_onchain_data
Read-only

Bitcoin and Ethereum on-chain, no target. No window = current value; since_ms/until_ms/last = history. Rows newest first, dated at the START of their bucket (first_time + i x step_s); for a total, an extreme or a change read summary, for the period covered read ranges; null + unavailable = no data; _pct = percent, _ratio = fraction; every unit: describe_fields. timeframe: btc_fees only (others keep their source cadence); dataset: the btc_mining history.

EXAMPLE: MVRV over 90 days: fields=["btc_mvrv"], last="90d"

FIELDS:

  • btc_network: Difficulty, block height, next adjustment.

  • btc_mempool: Mempool size, fees and trend.

  • btc_fees: Recommended fees, sat/vB, by urgency. [tf with N or history]

  • btc_mining: Mining pool concentration, pool ranking and block rewards. [dataset in history]

  • btc_mvrv: MVRV, label, 30-day change (source ~7 days behind).

  • btc_nvt: NVT and NVT signal (label: the signal).

  • btc_active_addresses: Active addresses, 7- and 30-day averages.

  • btc_revenue_per_difficulty: Miner revenue per unit of difficulty, in USD.

  • eth_supply: Supply, issuance, burn, net issuance.

  • eth_gas: Gas prices (gwei) and block usage.

  • eth_staking: Staking ratio, total staked, APR.

  • eth_deflation: 24h burn and net issuance (and annualised).

  • eth_defi: DeFi TVL, DEX volume, health ratio.

  • eth_gas_momentum: Gas trend: 7-day vs 30-day averages.

  • eth_squeeze: Supply squeeze index (staking, issuance).

  • eth_price_btc: ETH price in BTC and USD, 7-day change.

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": {
      "fields": "<fields>"
    },
    "name": "get_onchain_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
lastNoHistory over the last '48h' / '30d' (whole buckets).
limitNoN latest points per series (default 1).
detailNosummary: one row per series + summary; full: every column.compact
fieldsYesFields (FIELDS below).
columnsNoColumns to keep, e.g. ["close", "volume"].
datasetNobtc_mining history (default concentration).
dry_runNoPlans the call without making it: its quota cost, your remaining rate and quota, the checks. No data, no quota.
since_msNoHistory start: epoch ms, ISO date or '48h' ago.
until_msNoHistory end.
timeframeNoStep of btc_fees.
max_tokensNoResponse budget, estimated tokens (default 6000).
max_quota_costNoRefuses the call, before any request, if it would use more quota requests than this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior on top: rows are newest first, dated at the START of the bucket (first_time + i x step_s), null + unavailable means no data, _pct is percent and _ratio is a fraction, btc_mvrv source lags ~7 days, timeframe applies only to btc_fees, and dry_run reports quota cost without spending it. It stops short of describing error conditions or response truncation behavior under max_tokens.

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?

It is front-loaded with the core scope, then semantics, then the example, then a per-field catalog, so nothing is buried. The main paragraph is a dense semicolon run that takes effort to parse, but every clause carries information and the 16-line FIELDS list earns its space because the schema enum gives no per-field descriptions.

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 12-parameter tool with no output schema, the definition covers what an agent needs: row ordering, bucket dating convention, null semantics, unit suffixes, source lag, detail modes, quota guardrails, and token budget. Remaining gaps are minor (error handling, behavior when max_tokens truncates), and the annotations already carry the safety profile.

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 the baseline is 3; the description exceeds it by explaining relationships the schema cannot express: 'No window = current value' clarifies the last/since_ms/until_ms interaction, 'timeframe: btc_fees only' scopes a parameter to one field, 'dataset: the btc_mining history' scopes another, and the EXAMPLE (fields=["btc_mvrv"], last="90d") shows the intended call shape.

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 names the concrete resource and scope: 'Bitcoin and Ethereum on-chain, no target', which distinguishes it from sibling pair-scoped tools (get_pair_data) and from macro/options data. It is telegraphic and never states a full verb phrase, and it never explicitly routes to alternatives by name, but the domain is unambiguous and the FIELDS list pins down exactly which metrics come back.

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?

It gives real usage rules: 'No window = current value; since_ms/until_ms/last = history', 'for a total, an extreme or a change read summary, for the period covered read ranges', and points to describe_fields for units. What is missing is when to prefer this tool over siblings like get_market_indicators or get_pair_data, so the agent gets mode-selection guidance but not tool-selection guidance.

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

All BytNode toolsInspect
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.

Resources