Skip to main content
Glama

BTC Intel Score history

get_score_history
Read-only

Use for the raw daily series: one row per day with the Score, its classification and a live or backtested mark (daily since July 18, 2011, backtested with the current method before live publication), as JSON or CSV, 100 rows a page. Choose it to chart or export values; for one day use get_score_for_day, for summaries get_score_statistics, for classification periods get_classification_history. 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 for every page of that query, no subscription: the first call returns an invoice instead of data (steps under payment). Example: from 2024-01-01, to 2024-03-31 and format csv return that quarter as one table; a range longer than a page comes back in parts, so repeat the same call with page = next_page until next_page is null.

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_history"
  }
}

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, YYYY-MM-DD, included. Default without from, to or page: the last 30 days of the free record, newest last; give from (for example 2011-07-18, the start) for an earlier range.
liveNotrue: data through the latest published day, paid ($0.25). Omit or false: the free answer, through the Delayed date.
pageNoPage number, from 1 (default 1). A page is 100 rows; take next_page from the answer, null on the last page.
exportNotrue: the whole record through the latest published day, 1000 rows a page, $1.00 once for all its pages within 24 hours. Default false.
formatNojson (default): rows as objects. csv: one text table with the header date,score,score_exact,level,change,pct_below,basis, for spreadsheets.
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
toNo
csvNo
fromNo
linkYes
noteYes
pageNo
rowsNo
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
next_pageNo
page_sizeNo
price_usdNo
basis_noteNo
score_noteNo
total_rowsNo
attributionYes
delayed_throughNoThe Delayed date: free answers stop here
payment_requiredNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / rows / items / properties / basis / enum
      Previous value: -[
      -  "live",
      -  "back-calculated"
      -]New value: +[
      +  "live",
      +  "backtested"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / from / description
      Previous value: -"First day, YYYY-MM-DD, included. Default: July 18, 2011, the start of the record."New value: +"First day, YYYY-MM-DD, included. Default without from, to or page: the last 30 days of the free record, newest last; give from (for example 2011-07-18, the start) for an earlier range."
  3. Changed7 schema fields changed
    • changedInput schema / properties / export / description
      Previous value: -"Optional: true for the full live export, $1.00, 1000 rows a page."New value: +"true: the whole record through the latest published day, 1000 rows a page, $1.00 once for all its pages within 24 hours. Default false."
    • changedInput schema / properties / format / description
      Previous value: -"json (default) for rows as objects; csv for one text table, for spreadsheets."New value: +"json (default): rows as objects. csv: one text table with the header date,score,score_exact,level,change,pct_below,basis, for spreadsheets."
    • changedInput schema / properties / from / description
      Previous value: -"Optional first day, YYYY-MM-DD. The start of the record when left out."New value: +"First day, YYYY-MM-DD, included. Default: July 18, 2011, the start of the 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 / page / description
      Previous value: -"Optional page, from 1. A page is 100 rows; next_page in the answer gives the next one (null on the last)."New value: +"Page number, from 1 (default 1). A page is 100 rows; take next_page from the answer, null on the last page."
    • 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 last day, YYYY-MM-DD. The Delayed date when left out (the latest published day with live = true); a day 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)."
  4. Changed3 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"Optional: json (default) or csv."New value: +"json (default) for rows as objects; csv for one text table, for spreadsheets."
    • 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."
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only supply readOnlyHint and openWorldHint; the description adds substantial behavior beyond them: $0.25 per query in bitcoin over Lightning regardless of page count, a $1.00 export tier valid 24 hours, a 100-row page size, an invoice-validity window of 10 minutes, and the macaroon:preimage payment replay. It also warns what a paid first call actually returns (an invoice, not data) and how expired or mismatched proofs are refused.

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 resource definition, then the sibling routing, then the payment model, then pagination. Every sentence carries information, but the opening sentence is a long run-on packing series shape, date provenance, formats and page size, which costs some scannability.

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?

For a 7-parameter tool with a metered payment flow and pagination, the definition covers the full call lifecycle: free vs paid selection, the two-step invoice/payment handshake, page advancement, and format choice. An output schema exists, so the absence of return-value detail is not a gap, and the mention of next_page is the one field the caller must act on.

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; the description goes further by giving a worked example (from 2024-01-01, to 2024-03-31, format csv returning one table) and the pagination loop — repeat the same call with page = next_page until next_page is null. That procedural detail about how 'page' is meant to be driven is meaning the schema does not carry.

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 resource and shape: the raw daily series, one row per day with Score, classification and live-or-backtested mark, spanning daily since 2011-07-18. It explicitly names what it is not (get_score_for_day for one day, get_score_statistics for summaries, get_classification_history for classification periods), so an agent can separate it from all named siblings without opening a 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 (chart or export values) and three explicit alternatives keyed to different intents. It also states the free/paid boundary precisely — free through the Delayed date, paid for a later 'to' or live=true — so the agent knows when the call will divert into an invoice rather than data.

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