rail-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RAIL_LIVE | No | Set to `1` for explicit live approval alongside the Stripe secret key. | |
| RAIL_MODE | No | `dry_run` (default) or `live`. Defaults to `dry_run` when unset. | |
| RAIL_DATA_DIR | No | Ledger directory. Default is `~/.rail` in the user home directory. An explicit value overrides the default. | |
| LINK_ACCESS_TOKEN | No | Link OAuth token. Required before the scaffolded POST actually runs. | |
| STRIPE_SECRET_KEY | No | Required for live mode. Not used to issue cards or as a Link bearer token. | |
| RAIL_ALLOW_LIVE_CHARGE | No | Set to `1` for an additional gate before any Link HTTP request. |
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 |
|---|---|
| set_budgetA | Overwrite the local spend budget. Changes the ledger limit only. Does not spend money, approve a card, settle a purchase, or contact Stripe or Link. Passing the same amount again does not add to the budget. |
| get_budgetA | Read the active budget, amount spent, amount remaining, and the count of pending proposals. Does not change the ledger, spend money, or contact Stripe or Link. |
| propose_purchaseA | Record a pending purchase intent only. Moves no money, creates no receipt, approves no card, and does not contact Stripe or Link. Needs a later human approval via decide_proposal before anything settles. When a budget exists and the amount is above what remains, the proposal is stored with over_budget set and still spends nothing. |
| list_proposalsA | Read purchase proposals filtered by status: pending (default), approved, rejected, or all. Does not approve, reject, spend money, or contact Stripe or Link. |
| decide_proposalA | Approve or reject one pending proposal. This is the step a human should confirm. decision=approve settles the purchase: in the default dry-run mode it writes a settled_dry_run receipt, stamps a fake settlement ref (lsrq_dry_…), and decrements the remaining budget, without calling the network. decision=reject spends nothing and writes no receipt. The proposal can be decided only once; repeating the call does not settle again. Live charging stays off unless separate live gates are set on purpose. |
| get_receiptsA | Read receipts, newest first, including dry-run settlements and refunds. Does not refund, spend money, or contact Stripe or Link. |
| refund_receiptA | Reverse a settled dry-run receipt and restore that amount to the remaining budget. This is the step a human should confirm. Does not contact Stripe or Link. A receipt can be refunded only once; repeating the call does not refund again. Refuses receipts that are not settled_dry_run. |
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 maps to a distinct resource+action: budgets (set/get), proposals (propose/list/decide), and receipts (get/refund). Descriptions explicitly clarify boundaries, e.g. set_budget vs propose_purchase vs decide_proposal, leaving no real overlap.
Every tool follows a clean verb_noun snake_case pattern (set_budget, get_budget, propose_purchase, list_proposals, decide_proposal, get_receipts, refund_receipt). No mixing of conventions.
Seven tools is well-scoped for a spend-governance ledger, each covering a necessary stage of the budget/proposal/receipt lifecycle with no filler.
Covers the full lifecycle: budget set/read, proposal create/list/decide, receipt read/refund. Minor gaps like filtering or clearing stale proposals exist but core workflows have no dead ends.