btcmatic-mcp-server
OfficialServer 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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| btcmatic_discoverA | Free. What the BTCMatic agent API offers, what one call costs in sats, the prepaid bounds and the payment flow. Call this first. |
| btcmatic_radarA | Open and corroborated self-custody security incidents (hardware/software wallets, nodes, payment stacks), per-product feed chatter counts with the number of distinct sources behind them, and the per-source precision ledger from manually labeled items. Counts and labels only — no verdicts. Costs one call; without payment the 402 offer is returned as data. |
| btcmatic_contextA | Latest BTC price with 1h/24h/7d change, next-block fee (sat/vB) with its percentile over the trailing 90 days of hourly averages, and mempool size. Values older than 5 minutes come back null; missing history is reported in data_quality, never interpolated. Descriptive only. |
| btcmatic_condition_frequencyA | Counts, at hourly resolution, how often a single condition became true in the trailing 90 days (rising edges — what a throttled rule would have fired) and how many hours it held. Metrics: price_change_pct (needs window 1h|24h|7d), fee_next_block (sat/vB), mempool_vsize (vbytes). Operators: <, <=, >, >=. Past frequency, not a forecast. |
| btcmatic_topupA | Free. Mints a Lightning invoice for a prepaid balance (see btcmatic_discover for the min/max). Pay it with a wallet you control, then call btcmatic_topup_claim with the preimage. The payment hash alone never yields a token. |
| btcmatic_topup_claimB | Proves the top-up payment with its preimage and receives the prepaid token EXACTLY ONCE. Store it and restart this server with BTCMATIC_AGENT_TOKEN= so every paid tool debits the balance automatically. |
| btcmatic_creditsB | Free. The balance behind the configured prepaid token (BTCMATIC_AGENT_TOKEN) and how many calls it still covers. |
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 7 tools
Each tool addresses a distinct concern: discovery, security radar, market context, historical condition frequency, pre-payment minting, token claiming, and balance checks. There is no overlap or ambiguity between them; even the related topup and topup_claim are clearly stage-separated.
All tools share the 'btcmatic_' prefix, but the second part mixes nouns (radar, context, credits) and verbs (discover, topup_claim). The pattern is predictable and readable, but not a strict verb_noun convention, so it loses a point for minor stylistic inconsistency.
Seven tools is well within the ideal range for a focused MCP server. Each tool earns its place covering the API's core functions (information, data, condition analysis, payment lifecycle, and account status) without redundancy or bloat.
The tool surface covers the full lifecycle: discovery, market data, historical condition analysis, the prepaid payment flow (mint, claim, balance), and security radar. There are no obvious missing operations that would hinder an agent's ability to accomplish the server's intended tasks.