Spend Brake
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BRAKE_KEY | Yes | The revocable virtual key (e.g. sb_live_…) that authenticates requests and enforces caps when the MCP server sends searches through the Spend Brake proxy. | |
| BRAKE_URL | No | The URL of the Spend Brake proxy that all MCP searches are routed through. | https://proxy.spendbrake.dev |
| BRAKE_API_URL | No | The URL of the Spend Brake admin API. | https://app.spendbrake.dev |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Web search through Spend Brake: every call is charged against a hard dollar cap. When a tool answers with STOP, do not retry or work around it, and do not switch to the other search tool: the same caps apply to both. Tell the user and ask them to raise the cap. A search that timed out may still have been forwarded and charged: do not repeat it blindly, check brake_budget first. brake_budget shows what is left.
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 |
|---|---|
| tavily_searchA | Search the web with Tavily. Each call is charged against a hard spend cap; the result shows its cost and the budget left. |
| exa_searchA | Search the web with Exa. Each call is charged against a hard spend cap; the result shows its cost and the budget left. |
| brake_budgetA | Show the spend caps that apply to this key and what is left of each. Read-only: it cannot change a cap. |
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
brake_budget is clearly a read-only budget inspection tool, distinct from the two search tools. tavily_search and exa_search serve the same purpose (web search) and differ only by provider, which the descriptions make explicit, but an agent has no strong basis to choose between them besides name recognition.
All names are snake_case and the two search tools follow a clean <provider>_search pattern. brake_budget breaks the action-first convention but is still readable and clearly grouped under the server's 'brake' concept.
Three tools is thin for a spend-control server; the surface is essentially one read-only status tool plus two interchangeable search backends. It is not wrong for the purpose, but each tool barely stakes out distinct territory.
There is no way to set, raise, or reset caps, nor to view spend history or usage over time, so the budget lifecycle is read-only by design and leaves dead ends. Coverage of search is also limited to two providers with no fallback or aggregate search option.