NakamotoNotes Bitcoin Barometer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_market_snapshotB | Current Bitcoin Barometer reading: Heat Score 0-100, zone and zone bands, yesterday and last week, BTC price with 24h and 7d change, and the ten indicators with value, heat and a one-line meaning. Descriptive only. |
| explain_indicatorA | What one Barometer indicator measures, its current value and heat, and how it feeds the score. |
| get_historyA | Heat Score history from the public daily history. from is required (YYYY-MM-DD), to defaults to the last day. interval day|week|month|auto (auto picks the finest that fits 400 points); a summary covers the whole range. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a distinct angle: get_market_snapshot is the current full reading, get_history is a time series, and explain_indicator is a deep dive on a single indicator. There is mild overlap since the snapshot already includes indicator values and one-line meanings, but the descriptions distinguish 'current overview' from 'explanation' clearly enough.
All names are snake_case verb_noun, but two use the get_ prefix while explain_indicator uses explain_. The deviation is minor and readable, so the pattern is still mostly predictable.
Three tools is on the lean side, but for a read-only, descriptive barometer the small surface is well-scoped: one for the current reading, one for history, one for indicator education. Nothing feels redundant.
The lifecycle of a read-only data source is largely covered: current snapshot, historical series, and per-indicator explanation. Minor gaps remain, such as listing all valid indicator names or fetching a full snapshot for a past date, but agents can work around these via get_history.