BTC Intel

BTC Intel Score classification history

get_classification_history

Read-only

Use for the periods the Score spent in each classification (Low, Moderate-low, Neutral, Elevated, High): the start, end and length in days of each, newest first, 100 a page, each marked live or backtested. Choose it to see when a classification last held and for how long; for daily values use get_score_history, for shares and counts across the record get_score_statistics. 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).

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

Input Schema

Name	Required	Description
`to`	No	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).
`from`	No	First day, YYYY-MM-DD, included. Default: July 18, 2011, the start of the record.
`live`	No	true: data through the latest published day, paid ($0.25). Omit or false: the free answer, through the Delayed date.
`page`	No	Page number, from 1. Without from, to or page the answer is the latest 20 stretches; page 1 gives the first 100, newest first, and next_page the rest.
`payment`	No	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.

Output Schema

Name	Required	Description
`link`	Yes
`note`	Yes
`page`	No
`as_of`	Yes	UTC: the last day the answer covers (YYYY-MM-DD), or for the Brief and methodology the time it was published (ISO 8601)
`pages`	No
`range`	No
`total`	No
`access`	No
`source`	Yes
`next_page`	No
`page_size`	No
`price_usd`	No
`stretches`	No
`basis_note`	No
`score_note`	No
`attribution`	Yes
`delayed_through`	No	The Delayed date: free answers stop here
`payment_required`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / page / description

Previous value: -"Page number, from 1 (default 1). A page is 100 rows; take next_page from the answer, null on the last page."New value: +"Page number, from 1. Without from, to or page the answer is the latest 20 stretches; page 1 gives the first 100, newest first, and next_page the rest."

Changed5 schema fields changedNov 7, 2026

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)."

Changed2 schema fields changedNov 7, 2026

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."

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only mark it read-only with a closed world; the description adds the commercially critical behavior: free through the Delayed date, $0.25 over Lightning beyond it, one payment per page of that query, and the first paid call returns an invoice plus macaroon instead of data. It even states the proof is valid for 24 hours and that a used, expired or mismatched proof is refused. That is substantial context the agent cannot get from annotations or schema.

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 purpose and alternatives before the pricing detail, and every sentence contains a fact. The payment paragraph is long and slightly redundant with the 'payment' parameter description, which keeps it from a 5.

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 paginated, partly paid, read-only endpoint with an output schema, the description covers selection, defaults, ordering, pagination, the free cut-off and the complete payment retry loop. Nothing an agent needs in order to call it correctly or interpret the invoice response is missing.

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% and the parameter docs already cover defaults, date format and the payment/macaroon flow, so the baseline is 3. The description mostly restates that, adding only the per-page payment scoping and the no-parameters default of the latest 20 stretches, which is already in the 'page' field description.

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 opening line names a specific resource (the periods the Score spent in each classification) and the exact payload: start, end, length in days, ordering (newest first), page size, and the live/backtested marker. It is immediately distinguishable from a history tool that returns daily values and from a statistics tool.

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?

It gives a positive selection rule ("Choose it to see when a classification last held and for how long") and routes two named alternatives: get_score_history for daily values and get_score_statistics for shares and counts. The free/paid boundary and the shared 'payment' argument are also stated up front, so the agent knows what a call will cost before invoking.

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

All BTC Intel 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.

Resources

Need Help?