BTC Intel

BTC Intel read for a day

get_read_for_day

Read-only

Use for a past day's record, by date: the Full Read and the five market areas with their state words (Adverse, Cautionary, Neutral, Constructive or Supportive) as stored that day, and for the latest stored day the Brief's headline. Choose it to look up what the read was on a given day; for today use get_bitcoin_today, for the areas' 26 components get_market_detail, for the Score get_score_for_day. The stored reads begin in October 2026, so free answers start in early January 2027. Free through the Delayed date (the free cut-off, three months before the latest published day). A later date, or live = true for the latest day with its headline, 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).

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

Input Schema

Name	Required	Description
`date`	No	A past day, YYYY-MM-DD; the stored reads begin in early October 2026 and an earlier day says where they begin. Default: the Delayed date, or the latest day with live = true. A day after the Delayed date is paid ($0.25).
`live`	No	true: data through the latest published day, paid ($0.25). Omit or false: the free answer, through the Delayed date.
`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
`date`	No
`link`	Yes
`more`	No
`note`	Yes
`areas`	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
`access`	No
`latest`	No
`source`	Yes
`stories`	No
`headline`	No
`sentence`	No
`price_usd`	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.

AddedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the data-availability floor (stored reads begin October 2026, free answers from early January 2027), the free cut-off (Delayed date, three months before the latest published day), and the full payment-required behavior: the first call returns a Lightning invoice rather than data, priced at $0.25 per answer. This is exactly the kind of non-obvious operational detail annotations cannot convey.

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?

Purpose, returned content, sibling routing and cost model are front-loaded in a logical order, and the parenthetical state-word list is a useful disambiguation. It is dense with long parentheticals and repeats the payment mechanics that the payment parameter already spells out, which costs some economy.

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 date-scoped read tool with a payment gate, all the decision-critical facts are present: return content, date bounds, free-tier cut-off, and the invoice/retry flow. An output schema exists, so the description needn't enumerate response fields, yet it still characterizes the payload usefully.

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%, so date, live and payment are already fully documented in the schema, including the macaroon:preimage format and the 10-minute/24-hour windows. The description largely restates those facts (free vs. paid, invoice-then-retry) rather than adding syntax or edge-case meaning on top. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a specific verb and resource ('Use for a past day's record, by date') and enumerates exactly what is returned: the Full Read, the five market areas with their state words, and the latest day's Brief headline. It explicitly distinguishes itself from get_bitcoin_today, get_market_detail and get_score_for_day, so an agent can route without opening the 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?

It gives an explicit selection rule ('Choose it to look up what the read was on a given day') and pairs each sibling with the condition that selects it (today, the 26 components, the Score). The free/paid boundary and the earliest available date are stated as conditions, leaving nothing to inference.

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?