@sentimentracker/signals-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SNT_SIGNALS_API_KEY | No | Long-lived snt_mcp_… key minted via POST /api-keys. Recommended for headless / production. Required if no session token. | |
| SNT_SIGNALS_ENDPOINT | No | Override for staging / local dev. | https://api.sentimentracker.com/api |
| SNT_SIGNALS_SESSION_TOKEN | No | Bearer JWT from your authenticated session. Expires; refresh manually. Required if no API key. | |
| SNT_SIGNALS_DEFAULT_PROVIDER | No | One of auto / hyperliquid / binance / tiingo / intrinio / databento. Per-call override via tool input. | auto |
| SNT_SIGNALS_REQUEST_TIMEOUT_MS | No | Fetch timeout (1000-60000 ms). | 15000 |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_indicatorsA | Catalog of every indicator the Sentimentracker backend can compute, read live from its registry. Returns key, displayName, signalKind (directional / regime / levels / divergence / mixed) and a one-line description per indicator. Call this once at session start so the agent knows which key to ask about. |
| get_indicator_signalA | Latest signal envelope for the given (indicator, symbol, resolution). Returns the proprietary metadata only — signals[], trades[], currentTrade — without the full per-bar plot arrays. Use this for 'what is sniperV3 saying about BTC on 15m right now?'. Optional |
| get_indicator_fullA | FULL calculator output — every per-bar plot array AND the metadata envelope. Large payload (100-300 KB). Use only when the agent needs per-bar context; otherwise prefer |
| get_signal_confluenceA | Run N indicators in parallel against the same (symbol, resolution) and return a compact confluence table. Each row: indicator key, displayName, signalKind, latest signal side (BUY/SELL/null), latest signal ts (ms), error (if any). The LLM judges agreement from the table — there's no built-in voting rule. Max 20 indicators per call; unknown keys fail the whole call before any fetch. |
| subscribe_signalA | Long-poll for a NEW signal on (indicator, symbol, resolution). Holds the call for up to |
| propose_trade_from_signalA | PURE COMPUTE: compose a Hyperliquid |
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 6 tools
Each tool maps to a distinct operation: catalog discovery, single-indicator signal envelope, full per-bar payload, multi-indicator confluence, long-poll subscription, and order composition. The two get_indicator_* tools are clearly separated by payload intent, and get_signal_confluence is explicitly a parallel multi-indicator view.
All tool names follow a clean snake_case verb_noun pattern: list_indicators, get_indicator_signal, get_indicator_full, get_signal_confluence, subscribe_signal, propose_trade_from_signal. The shared get_ prefix and logical object naming make the API predictable.
Six tools is well-scoped for a signals MCP: discovery, light read, heavy read, aggregation, streaming, and downstream trade proposal. No tool feels redundant or missing from the core workflow.
The tool surface covers the full signal lifecycle: enumerate indicators, fetch current signals, retrieve full history, compare confluence, subscribe to changes, and convert signals into trade payloads. There are no obvious dead ends or critical missing operations.