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

TableJSON 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

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Beyond that the description discloses genuinely non-obvious behavior: the partial-bar flag semantics, live sampling with null ingested_at, how built series inherit the 1h bar's health/freshness, and that built series' high/low span the underlying 1h bars. Auth and rate-limit behavior are not covered, but the disclosure is well above the annotation baseline.

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

Conciseness3/5

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

Front-loaded with 'Bitcoin only, beta' and the core content, which is good. But the remainder is roughly 300 words of dense, heavily parenthetical prose with run-on sentences for a two-parameter read-only tool; the partial/live/built-series edge cases could be structured far more legibly. Size is defensible for the semantics but the structure is not.

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?

No output schema exists, so the description carries the full burden of explaining returns, and it does so in depth: bars count, bar attributes, the partial and live flags, and built-series behavior. It stops short of explaining 'FBB' and exact response shape, but an agent has enough to interpret results correctly.

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 50% – bars is documented in the schema and the description merely repeats its default/max. The timeframe parameter has no schema description, and the description compensates substantially by explaining that 2H/6H/8H/12H are built from 1h bars while 1m/3m/5m/15m carry levels only and no bars, which is semantic information an enum list alone cannot convey.

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 opening sentence states a specific resource: one timeframe's analysis plus its OHLCV candles and the support/resistance/FBB band levels it lists. An agent knows exactly what data comes back. However, it never distinguishes itself from the nearby sibling mcw-signals-market-data, which plausibly also serves price series, so routing still requires inference.

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?

There is no when-to-use guidance against the eleven siblings, some of which (market-data, overview, thesis) overlap conceptually. The conditional phrasing about granularity ('note says so') explains how to read results, not when to select this tool. 'Levels, not a trade plan. Not investment advice.' is a disclaimer, not usage 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