Skip to main content
Glama

Bitcoin signals: chart

mcw-signals-charts
Read-onlyIdempotent

Bitcoin only, beta. One timeframe's analysis, its OHLCV candles and the support, resistance and FBB band levels the analysis lists. The analysis carries its own analyzed_at and cadence_check (its ok false past half an hour, three of TSP's ten-minute re-runs). granularity names the bars: 2H, 6H, 8H and 12H are built from TSP's 1h bars, and 1m, 3m, 5m and 15m have levels only, no bars (the finest bars the Signals run takes from TSP are 30m); note says so. A built series is judged on the 1h bars it is built from: its health and its freshness are the 1h series' (source_newest_bar_at and source_interval_ms say which bar and cadence). bars defaults to the newest 50 and accepts up to 200. The newest bar can carry a partial flag: when true it was read before it closed, ingested_at says when (null if not known), and its high, low and close are as of then. When TSP also marks it live, it has no ingested_at: its high, low and close are a live sample TSP took at as_of (null if not known; extremes is TSP's word for how its high and low were taken, sampled or null), and volume_ingested_at says when its volume was recorded (null if not known). On a built series, live, as_of and volume_ingested_at are its last 1h bar's: only its close is that sample, its high and low span the 1h bars it holds (extremes null), and its volume is their sum. A bar TSP makes from its sample before that interval's bar is recorded is left out, so a series ends at its newest recorded bar: partial is true there when TSP moved its flag from it onto the bar it made, or left it unlabelled with its volume recorded before it closed. Levels, not a trade plan. Not investment advice.

Input Schema

NameRequiredDescriptionDefault
barsNoHow many of the newest bars to return.
timeframeNo4H

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / bars / default
      Previous value: -100New value: +50
  2. Added

TDQS

B3.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses important data-freshness behavior: cadence_check timing, partial bar handling, live samples, built-series caveats, and low-timeframe level-only behavior. It is rich but dense, and some terms like FBB and TSP remain undefined.

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 purpose is front-loaded, but the description becomes a dense wall of technical caveats with nested parentheticals and repeated timestamps/flags. It contains useful detail, but structure and brevity are weak for a two-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description carries the return-value burden and does so extensively: analysis metadata, candles, levels, bars default/max, partial flags, live samples, and freshness fields. It is nearly complete, though some terminology and field-shape clarity could be improved.

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?

The schema already documents bars, while the description adds meaningful semantics for timeframe such as which timeframes have bars versus levels only. However, it refers to `granularity` rather than the actual `timeframe` parameter and the schema has no timeframe description, leaving some mismatch.

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 the resource: one timeframe's analysis, OHLCV candles, and support/resistance/FBB levels, with Bitcoin-only and beta scope. It distinguishes the asset scope but does not name sibling tools or explicitly contrast with mcw-signals-market-data, mcw-signals-overview, etc.

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

Usage Guidelines2/5

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

It does not say when to use this tool versus alternatives such as mcw-signals-market-data or mcw-signals-overview. Usage is only implied by the returned fields; there are no exclusions, prerequisites, or alternative-selection guidance.

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