Skip to main content
Glama

Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub

Get Stratigraphy Range

stratigraphy.get_range
Read-onlyIdempotent

Fetch a contiguous sequence of Bitcoin stratigraphy records between startTarget and endTarget (block heights or YYYY-MM-DD UTC dates, in ascending order, capped by the limit parameter). Use this tool when analyzing multi-block trends or time-series intervals. Use stratigraphy.list to browse available catalog bounds, stratigraphy.get for a single snapshot, stratigraphy.get_diff to compare two endpoints without intermediate records, or stratigraphy.get_digest for compact hashes. Paid L402 call: on HTTP 402, pay the invoice and retry with Authorization: L402 :. Supports zero-polling asynchronous execution: provide a webhook_url parameter to receive a 202 Accepted response immediately, followed by a server-initiated POST callback containing the final results when processing completes.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "limit": 3,
      "format": "kv",
      "endTarget": "latest",
      "startTarget": "919712"
    },
    "name": "stratigraphy.get_range"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum compressed records returned from startTarget toward endTarget, 1-100 (default 50); smaller limits truncate the batch. Constraints: minimum: 1; maximum: 100. Example: 50.
formatNoCompression of every returned record: compact (default), minimal, or kv; does not change selected bounds. Constraints: allowed values: compact, minimal, kv. Example: "compact".compact
endTargetNoOptional inclusive ending indexed height, UTC ISO date, or 'latest' (default: latest indexed entry, not live tip); must resolve no earlier than startTarget. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "latest".latest
startTargetYesRequired inclusive starting indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); must resolve no later than endTarget. Constraints: pattern: ^(?:(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "919712".
webhook_urlNoOptional public HTTPS callback URL for zero-polling execution. On a paid call the server answers HTTP 202 Accepted with a JSON-RPC result containing task_id and status pending, runs the tool in the background, then POSTs one JSON body with task_id, status (completed or failed), tool, request_id and the final MCP result or JSON-RPC error. Omit it to receive the result synchronously. Loopback, private, link-local and other reserved addresses are rejected before any invoice is issued. Constraints: maxLength: 2048; format: uri; pattern: ^https://. Example: "https://agent.example.com/mcp/callbacks".

Output Schema

NameRequiredDescriptionDefault
countYesNumber of actual records returned.
rangeYesRequested inclusive real height/date bounds.
formatYescompact, minimal, or kv response format.
recordsYesSelected actual snapshot summaries, not a synthetic daily index.
live_metricsYesHal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null.
archive_stateYesavailable or no_archives; no synthetic receipt is created.
proofAvailableYesTrue only if an archived JSON/OTS pair was returned.
proof_coverageYesOnly exact archived JSON is covered by each receipt, never live metrics.
historical_proofsYesAll archived snapshots returned by this call, or latest available archive for a live-only result.
_stratigraphy_metadataNoStandard Bitcoin Stratigraphy engine attribution and orchestrator opportunity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: the L402 paid-call flow (402 → pay invoice → retry with Authorization: L402) and the zero-polling webhook mode (202 Accepted, background task_id, server-initiated POST callback). These are operational traits an agent cannot infer from the schema or annotations.

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 action, then routing, then payment, then async mode — a logical order with no filler sentences. Slightly longer than needed because the webhook paragraph largely restates what the webhook_url schema description already documents in detail.

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

Completeness5/5

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

Return shape is covered by the output schema and safety by annotations, and the description fills the remaining gaps: payment/auth requirements, sync vs. async delivery, range semantics, and 'latest means latest indexed entry, not live tip.' Everything needed to call it correctly is present.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter already carries its own constraints (pattern, enum, min/max, default). The description only restates that bounds are inclusive/ascending and that limit caps the range, both of which the schema already says; it adds little beyond enumeration of parameter names.

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?

States a specific verb and resource ('Fetch a contiguous sequence of Bitcoin stratigraphy records') plus the exact bounds (startTarget/endTarget), ordering, and limit cap. It explicitly distinguishes itself from four named siblings, so an agent can disambiguate without opening any schema.

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

Usage Guidelines5/5

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

Gives a positive selection rule ('when analyzing multi-block trends or time-series intervals') and explicit alternatives with their conditions: list for catalog bounds, get for a single snapshot, get_diff for endpoint comparison without intermediates, get_digest for compact hashes. Nothing is left to inference.

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.

Resources