Skip to main content
Glama

Bitcoin signals: sentiment

mcw-signals-sentiment
Read-onlyIdempotent

Bitcoin only, beta. TSP's sentiment readings for BTC, each with its own time and none combined with another. hourly: TSP's hourly rollup (TSP says its sentiment is global by design: one TSP-wide series, not scoped to one org), its newest hourly buckets (up to 48), each with its hour, mean_sentiment, stddev_sentiment and sample_count; a bucket with fewer than thin_below readings is thin; a null mean is no data, never 0; an hour with no readings has no bucket; TSP rewrites an hour after it closes, and newest_bucket_open says whether the newest is still open at the moment of the answer. ema: TSP's 24-hour EMA of that rollup, each point with its hour and the computed_at TSP gives it. TSP says the scores run roughly -1 to 1; a score outside -1 to 1 is published as null (the Wire's filter). news_index: TSP's own daily news index (0 to 100, 100 = extreme greed), with TSP's label and article_count; a day with too few articles has a null value, never a low one. blend: TSP's blend, the weighted_sentiment, confidence and source_count of its canonical row over that row's own window (window_start to window_end); it is not a combination of the indexes. The hourly, EMA and news blocks each carry their own cadence_check, and the blend its age_s and stale, judged at the moment of the answer. By default each series is the newest 3 points; the answer's history block reports how many older points were left out. Set history to true for the full stored series. Not investment advice.

Input Schema

NameRequiredDescriptionDefault
historyNoTrue returns every stored point of each series instead of the newest 3 (up to 48 hourly buckets, 24 EMA points and 30 days of the news index).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent, closed read, but the description goes well beyond them: null means 'no data, never 0', sub-threshold buckets are thin, an hour with no readings has no bucket, TSP rewrites a closed hour, out-of-range scores are published as null, and staleness is judged at answer time via cadence_check/age_s. This is unusually rich behavioral disclosure for a read tool.

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?

The critical scoping constraint is front-loaded and almost every clause conveys a field name or edge-case rule that an agent cannot get elsewhere (there is no output schema). It is dense, single-paragraph prose that would scan better with structure, but little is padding.

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 must carry the full return-shape burden, and it does: each of the four series blocks is described with its fields and edge cases, plus defaults, history behavior, and freshness signals. An agent has everything needed to call and interpret it.

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 100% and the single param's own description already explains the newest-3 default and the caps. The prose reinforces this and adds a genuinely new detail beyond the schema: the answer's 'history' block reports how many older points were omitted. That extra meaning lifts it above the baseline 3.

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?

States a specific resource and scope up front: 'TSP's sentiment readings for BTC' and 'Bitcoin only, beta'. It then enumerates exactly which series it returns (hourly, ema, news_index, blend), which lets an agent recognize the tool. It never names or contrasts a sibling (e.g. mcw-signals-overview), so it stops short of full differentiation.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named despite many sibling signals tools. The only conditional behavior given ('Set history to true for the full stored series') is parameter mechanics, not tool-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