@bridgenode/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BRIDGENODE_DAILY_CAP | No | Spending policy: maximum total payment per day in USDC | 1.0 |
| BRIDGENODE_WALLET_KEY | Yes | Solana wallet private key (base58) — agent's payment wallet | |
| BRIDGENODE_MAX_PER_CALL | No | Spending policy: maximum payment per call in USDC | 0.05 |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| chat_completionsA | Send a chat completion request to any supported model. Free models are served without payment; the first calls to a PAID model are also free per client (free trials), after which x402 payment (Solana USDC) is required — an unpaid call returns 402 with the exact price; retry with _meta["x402/payment"]. Responses are non-streaming. Pass either mode (auto/eco/premium) or model (explicit id) — one of the two is required; model wins if both are sent. Use this tool to generate text; inspect models and prices first with the free list_models tool. Start with a FREE model (no payment at all) and keep max_tokens >= 200 — a thinking model spends part of that budget on reasoning, so a smaller limit can return an empty answer. |
| list_modelsA | List available models and their prices — free, no payment, no authentication required. Read-only: no state changes; data is served from the server's local config, so repeated calls return identical results (idempotent). Accepts no parameters: the input schema is an empty object, and any arguments passed are ignored. Calling it without arguments returns the complete catalog with per-token prices; there is no filtering, pagination, or configuration. Use this tool to inspect models and prices before calling the paid chat_completions tool. Same data as GET /v1/models (§5.2). Do not use it to generate text (use chat_completions) or to estimate a specific request's cost (use get_price_estimate). |
| get_price_estimateA | Estimate the USDC cost of a chat completion request before paying — free, no payment, no authentication required. Read-only: no state changes and no external calls; the estimate is computed locally from server pricing config, so repeated calls with identical inputs return identical results (idempotent). Use this tool to check the exact price for a given model/mode, messages, and max_tokens before calling the paid chat_completions tool. Provide either mode (auto/eco/premium routing) or model (explicit id, mutually exclusive with mode); one of the two is required — if both are sent, model wins. mode values: auto = cheapest model fitting the context, eco = cheapest available, premium = best model. |
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
Each tool has a clearly distinct role: list_models returns the catalog, get_price_estimate prices a specific request, and chat_completions performs inference. The descriptions explicitly cross-reference each other ('use chat_completions', 'use get_price_estimate'), eliminating any realistic misselection.
get_price_estimate and list_models follow a clean verb_noun pattern, but chat_completions is a bare noun naming a resource/action endpoint. The deviation is minor and the naming remains predictable and readable.
Three tools is lean but plausibly matches the narrow gateway scope: inspect models, estimate cost, generate text. It sits at the low edge of the ideal range, with little redundancy, though it leaves almost no room for ancillary operations.
The core pay-per-request lifecycle (discover models, price a request, execute) is fully covered, including the 402 payment retry flow. Minor gaps exist: no streaming option, no balance/usage or payment-status tool, and no embeddings or other model modalities.