Skip to main content
Glama

BridgeNode MCP

by io.github.bridgenode-ai
OverviewDiscussionsAdmin

Chat completions with x402 payment

chat_completions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoSmart routing profile (auto/eco/premium).
modelNoExplicit model id (see list_models / /v1/models). Mutually exclusive with mode.
toolsNoOpenAI-style tool schemas the model may call. Forwarded unchanged; they count as input tokens for the price (§4.2/§5.3).
messagesYesChat messages (text content only). An assistant turn that calls a tool may carry content: null with tool_calls.
max_tokensNoMax output tokens (billed upfront, §4.2). MCP calls are non-stream: cap per config. Use >= 200 — reasoning models share this budget with their thinking and a smaller limit can return an empty answer.
tool_choiceNoOpenAI tool_choice: 'auto', 'none', 'required', or {type: function, function: {name}}.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
modelNo
usageNo
objectNo
choicesNo
createdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / max_tokens / description
      Previous value: -"Max output tokens (billed upfront, §4.2). MCP calls are non-stream: cap per config."New value: +"Max output tokens (billed upfront, §4.2). MCP calls are non-stream: cap per config. Use >= 200 — reasoning models share this budget with their thinking and a smaller limit can return an empty answer."
  2. Changed7 schema fields changed
    • changedInput schema / properties / messages / description
      Previous value: -"Chat messages (text content only)."New value: +"Chat messages (text content only). An assistant turn that calls a tool may carry content: null with tool_calls."
    • changedInput schema / properties / messages / items / properties / content / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • addedInput schema / properties / messages / items / properties / tool_call_id
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / messages / items / properties / tool_calls
      Added value: +{
+  "type": "array"
+}
    • changedInput schema / properties / messages / items / required
      Previous value: -[
-  "role",
-  "content"
-]New value: +[
+  "role"
+]
    • addedInput schema / properties / tool_choice
      Added value: +{
+  "description": "OpenAI tool_choice: 'auto', 'none', 'required', or {type: function, function: {name}}.",
+  "type": [
+    "string",
+    "object"
+  ]
+}
    • addedInput schema / properties / tools
      Added value: +{
+  "description": "OpenAI-style tool schemas the model may call. Forwarded unchanged; they count as input tokens for the price (§4.2/§5.3).",
+  "items": {
+    "properties": {
+      "function": {
+        "type": "object"
+      },
+      "type": {
+        "enum": [
+          "function"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "function"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnly/destructive/idempotent flags): discloses per-client free trials, the 402 payment-required response and retry mechanism, non-streaming behavior, and billing semantics for tools/max_tokens. This is the kind of operational context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and payment, then routing rules and finally practical guidance. Dense but each sentence carries information; the max_tokens advice is partially duplicative of the schema description, which is the only minor slack.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description still covers payment lifecycle, routing rules, streaming behavior, and a critical failure mode (empty answer from small max_tokens). Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: the model-vs-mode precedence rule ('model wins if both are sent') is stronger than the schema's bare 'mutually exclusive' note, and the max_tokens >= 200 guidance explains the reasoning-budget failure mode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('send a chat completion request to any supported model') and clarifies which sibling to use for model/price discovery. An agent can distinguish this from list_models and get_price_estimate without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to inspect models and prices first with list_models, to start with a free model, and describes the paid flow (402 then retry with _meta["x402/payment"]). When-to-use, prerequisites, and the alternative sibling tool are all named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BridgeNode MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources