Skip to main content
Glama

BTC Intel Score statistics

get_score_statistics
Read-only

Use for a summary of the record: the historical position (the share of recorded days below and above the latest reading), mean, median and range, days per 10-point band, the share of days per classification, and counts of stretches and moves between classifications. Choose it to see how unusual a reading is; for the stretches themselves use get_classification_history, for daily values get_score_history, for recent change get_score_momentum. Free through the Delayed date (the free cut-off, three months before the latest published day). A later "to", or live = true, costs $0.25 in bitcoin over Lightning, one payment per answer, no subscription: the first call returns an invoice instead of data (steps under payment). The historical position describes where today's Score sits in the record, not what comes next.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_score_statistics"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast day, YYYY-MM-DD, included. Default: the Delayed date, or the latest published day with live = true. A day after the Delayed date is paid ($0.25).
fromNoFirst day of the range for the mean, median, range, bands and shares, YYYY-MM-DD, included. Default: the start of the record. The historical position and the current classification always use the whole record.
liveNotrue: data through the latest published day, paid ($0.25). Omit or false: the free answer, through the Delayed date.
paymentNoOmit on the first call: a paid request then returns a Lightning invoice (valid 10 minutes) and a macaroon instead of data. Pay it, then repeat the call with the same other arguments and payment = "<macaroon>:<preimage>" (the preimage your wallet shows once paid) within 24 hours. A used, expired or mismatched proof is refused with the reason; call again without payment for a new invoice.

Output Schema

NameRequiredDescriptionDefault
linkYes
noteYes
as_ofYesUTC: the last day the answer covers (YYYY-MM-DD), or for the Brief and methodology the time it was published (ISO 8601)
pagesNo
rangeNo
accessNo
sourceYes
throughNo
price_usdNo
basis_noteNo
score_noteNo
statisticsNo
attributionYes
delayed_throughNoThe Delayed date: free answers stop here
payment_requiredNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / from / description
      Previous value: -"Optional: the statistics on days from here (YYYY-MM-DD); the historical position and classification are always on the whole record."New value: +"First day of the range for the mean, median, range, bands and shares, YYYY-MM-DD, included. Default: the start of the record. The historical position and the current classification always use the whole record."
    • changedInput schema / properties / live / description
      Previous value: -"Set true for data through the latest published day (paid, $0.25 a call). Leave out for the free answer, which stops at the Delayed date."New value: +"true: data through the latest published day, paid ($0.25). Omit or false: the free answer, through the Delayed date."
    • changedInput schema / properties / payment / description
      Previous value: -"Leave out at first. After paying the invoice a paid call returned, send \"<macaroon>:<preimage>\" with the same arguments to receive the answer."New value: +"Omit on the first call: a paid request then returns a Lightning invoice (valid 10 minutes) and a macaroon instead of data. Pay it, then repeat the call with the same other arguments and payment = \"<macaroon>:<preimage>\" (the preimage your wallet shows once paid) within 24 hours. A used, expired or mismatched proof is refused with the reason; call again without payment for a new invoice."
    • changedInput schema / properties / to / description
      Previous value: -"Optional: the statistics on days up to here (YYYY-MM-DD); after the Delayed date is paid."New value: +"Last day, YYYY-MM-DD, included. Default: the Delayed date, or the latest published day with live = true. A day after the Delayed date is paid ($0.25)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / live / description
      Previous value: -"Optional: true for data through the latest published day (paid, $0.25 a call). Free answers stop at the Delayed date."New value: +"Set true for data through the latest published day (paid, $0.25 a call). Leave out for the free answer, which stops at the Delayed date."
    • changedInput schema / properties / payment / description
      Previous value: -"Optional: \"<macaroon>:<preimage>\" after paying the invoice a paid call returned. Send the same arguments again with it."New value: +"Leave out at first. After paying the invoice a paid call returned, send \"<macaroon>:<preimage>\" with the same arguments to receive the answer."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the substantive behavior an agent needs: free through the Delayed date (three months before latest published day), a later "to" or live=true costs $0.25 over Lightning, and the first paid call returns an invoice plus macaroon instead of data. It also discloses the non-predictive nature of the historical position.

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 answer content and then the routing alternatives, with the pricing caveat after. It is dense but composed of short clauses that each carry information; only the payment restatement overlaps what the schema already says.

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?

Output schema exists, so return values need no explanation, and annotations cover the safety profile. The description fills the remaining gaps an agent needs: free/paid boundary, invoice-first failure mode, and the interpretive limit of the statistics.

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 coverage is 100% and the schema already explains "to", "from", "live" and the payment/macaroon flow in detail, including defaults and the fact that position/classification always use the whole record. The description largely restates the free-vs-paid boundary rather than adding new parameter-level semantics, so the baseline 3 applies.

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?

The description names a specific resource and enumerates exactly what the summary contains: historical position (share of days below/above the latest reading), mean, median, range, days per 10-point band, share of days per classification, and counts of stretches/moves. It explicitly differentiates itself from get_classification_history, get_score_history and get_score_momentum.

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 ("Choose it to see how unusual a reading is") and routes three specific alternatives by purpose: stretches detail, daily values, recent change. It also states an important usage boundary: the historical position describes where today's Score sits, not what comes next.

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