Skip to main content
Glama

Bitcoin signals: market data

mcw-signals-market-data
Read-onlyIdempotent

Bitcoin only, beta. The BTC derivatives market: funding, open interest, liquidations, long/short, taker volume, ETF flows, options max pain and two fear and greed indexes from two publishers (each 0 to 100, 100 = extreme greed; fear_greed and fear_greed_alternative, each with its own reading, label and date, never averaged or combined), each with its own observed time and cadence. stats is TSP's open, high, low, close and range over its latest hourly bars, from window_start to window_end (TSP's window, not always 24 hours): newest_partial is true when the newest hour was still open when TSP read it, at as_of (null when not known), and newest_bar_open says whether it is open at the moment of the answer. Open interest comes for one contract (instrument, its venue in exchange) and for several together: contracts lists the perpetual contracts in that one figure, contracts_unlisted counts any leg it does not name, and includes_single_contract says whether the one contract is among them; a venue not shown here is null. flow.retail is the all-accounts long/short ratio (the global account ratio, by number of accounts), set against the top-trader position ratio. A pending ETF day has a null flow, never 0, whatever TSP's own word for it (tsp_status: reported, provisional or null). stopped_refreshing is true on ETF flows two days after their row was last written, and on max pain, which has no cadence of its own, six hours after its chain was captured. Clock verdicts (cadence_check, open_bucket.closed, newest_bar_open, stopped_refreshing, max pain's nearest expiry) are judged at the moment of the answer. By default the latest reading of every metric is complete and the back-history beside it is the newest 3 points per series; the answer's history block reports how many older points were left out. Set history to true for the full stored series. TSP's sentiment readings are in mcw-signals-sentiment, and its verdict on each price feed in mcw-signals-meta. Not investment advice.

Input Schema

NameRequiredDescriptionDefault
historyNoTrue returns every stored point of each series instead of the newest 3. The answer is about twice as large.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / history
      Added value: +{
      +  "default": false,
      +  "description": "True returns every stored point of each series instead of the newest 3. The answer is about twice as large.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the read-only annotations: default truncation to the newest 3 points per series, the `history` block reporting omitted points, pending ETF days having null flows rather than 0, `stopped_refreshing` timing rules, and clock verdicts being judged at answer time. These details materially help an agent interpret results and avoid misreading nulls or stale data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense, run-on wall of text with many embedded caveats and parentheticals. Although much of the detail is useful for a complex data tool, it is not scannable and could be structured into shorter sections or bullets. The opening sentence is front-loaded, but later sentences pack multiple concepts together.

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?

With no output schema, the description carries the burden of explaining returns, defaults, null semantics, timing rules, and metric definitions. It does this thoroughly, including what `stats`, `flow.retail`, ETF flows, open interest fields, and clock verdicts mean, and how default history is truncated.

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

Parameters5/5

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

There is only one parameter, `history`, and the schema already documents its boolean behavior. The description adds meaningful context: the default returns the latest complete reading plus the newest 3 back-history points, and the answer includes a `history` block showing how many older points were omitted. This goes beyond the schema's brief note about answer size.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool returns BTC derivatives market data and enumerates the included metrics: funding, open interest, liquidations, long/short, taker volume, ETF flows, options max pain, and fear/greed. It also distinguishes two sibling tools by saying sentiment data lives in mcw-signals-sentiment and price-feed verdicts in mcw-signals-meta. It does not explicitly differentiate itself from siblings like mcw-signals-overview or mcw-signals-charts.

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

Usage Guidelines3/5

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

Usage is mostly implied through the metric list and the note that sentiment and meta data live in sibling tools. The description does not say when to choose this tool over mcw-signals-overview, mcw-signals-charts, or mcw-signals-thesis. It does give clear guidance on the `history` flag, but not on tool-level alternatives.

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