routstr-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROUTSTR_NODES | No | Comma separated node URLs to use instead of discovery. Default: found on Nostr | |
| ROUTSTR_RELAYS | No | Nostr relays for discovery. Default: damus, nos.lol, relay.routstr.com | |
| ROUTSTR_CURATOR | No | Pubkey whose reviews approve nodes. Default: the Routstr curator | |
| ROUTSTR_MCP_HOME | No | Where the wallet lives. Default: ~/.routstr-mcp | |
| ROUTSTR_SATS_PER_CALL | No | What one call may cost when the agent does not say. Default: 100 | |
| ROUTSTR_MAX_SATS_PER_CALL | No | The most one call may cost, whatever the agent asks. Default: 500 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
routstr-mcp lets you call AI models sold on Routstr, an open market of nodes paid in bitcoin, as tools.
Use it for a second opinion from a different model, to compare several models with council, or to hand a simple sub-task to a cheaper model.
Each call costs a few sats from the user's prepaid Routstr balance and shows the cost. The prepaid balance is a hard limit.
Use find_models when you are unsure of a model id. Never ask the user for API keys, Cashu tokens or invoices. To add sats, the user runs npx routstr-mcp fund <sats> in a terminal and pays the Lightning invoice it shows. npx routstr-mcp refund takes unspent sats back.
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 |
|---|---|
| askA | Ask any model sold on Routstr and get its answer, paid in sats from the user's prepaid balance. Good for a second opinion, a model with different strengths, or a cheap model for a simple job. The cost is shown. |
| councilA | Ask 2 to 5 models the same question at once and get every answer with its cost, to compare them. You weigh the answers yourself. |
| find_modelsA | Search the models sold by approved Routstr nodes, cheapest first, with prices in sats. Every word of the query must match, e.g. "claude", "gpt 5", "qwen coder". Empty lists the cheapest. |
| balanceA | Show the sats left in the user's Routstr wallet, per node, and how to add more. |
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 4 tools
Each tool targets a clearly distinct action: discovery (find_models), single-model query (ask), multi-model comparison (council), and wallet inspection (balance). The only close pair, ask vs council, is explicitly separated by 'one model' vs '2 to 5 models at once'. An agent can select correctly from names alone.
Names mix verbs (ask, find_models) with bare nouns (council, balance), so there is no predictable verb_noun pattern. Each name is still short and readable, but the convention is inconsistent across the set.
Four tools is on the thin side but each maps to a genuine step in the workflow: find a model, query one, compare several, check funds. Nothing is redundant and nothing feels bolted on.
The read/query lifecycle is covered, but there is no tool to actually add sats to the balance (only a description of 'how to add more'), and no request/cost history for auditing spend. These gaps force agents into dead ends for anything beyond a one-shot query.