Skip to main content
Glama

OpenAI-compatible chat completions

chat_completions

Use when an agent must call an LLM with no account and no token metering: chat completions with the exact request and response shape of the OpenAI API - point your existing client at this URL and it works, no code change. One flat price per call whatever the size of the prompt or the answer — no token metering, no API key, no account, no rate limit. Automatic failover across several large models. You are only charged if the completion is delivered. $0.005 per call, paid over x402 (USDC).

Input Schema

NameRequiredDescriptionDefault
modelNoIgnored on purpose: the service picks the model and fails over between several. Accepted so an OpenAI client can send it unchanged.
promptNoShortcut for a single user message, if you do not want to build the array.
messagesNoThe conversation, as in the OpenAI API: [{"role":"system|user|assistant","content":"..."}]. In a POST, send it as a real JSON array, exactly as an OpenAI client does; in a GET, pass that same JSON as text in the query string. Both are accepted.
max_tokensNoOutput token cap, up to 4000. Does not change the price.
temperatureNoPassed through to the model when given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / messages / description
      Previous value: -"The conversation, as in the OpenAI API: [{\"role\":\"system|user|assistant\",\"content\":\"...\"}]. In a GET, pass it as JSON in the query string."New value: +"The conversation, as in the OpenAI API: [{\"role\":\"system|user|assistant\",\"content\":\"...\"}]. In a POST, send it as a real JSON array, exactly as an OpenAI client does; in a GET, pass that same JSON as text in the query string. Both are accepted."
    • changedInput schema / properties / messages / type
      Previous value: -"array"New value: +"string"
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: flat $0.005 per call regardless of prompt size, x402/USDC payment, no API key/account/rate limit, automatic failover across models, and billing only on delivery. It also warns that the model parameter is ignored on purpose, which prevents a costly misunderstanding.

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 the 'use when' trigger, then the compatibility guarantee, then cost/payment facts. Slightly redundant: the no-account/no-token-metering/no-key idea is restated in both the first and second sentences.

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

Completeness4/5

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

Covers cost, payment mechanism, failover, model-parameter behavior, and the response shape (by reference to OpenAI) with no output schema to lean on. What remains thin is the mechanics of the x402 payment handshake and how a failed/undelivered call is actually handled by the client.

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 baseline is 3; the description adds the framing that parameters follow the OpenAI API exactly, which gives an agent a mental model for messages/prompt/max_tokens. The pricing-relevant claim ('does not change the price') for size is stated at the description level rather than per-parameter.

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

Purpose4/5

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

States a specific verb+resource (chat completions with the exact OpenAI request/response shape) and its distinguishing property (no account, no token metering). An agent knows the shape of the call immediately. It stops short of naming sibling llm_completion to make the distinction airtight.

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

Usage Guidelines4/5

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

'Use when an agent must call an LLM with no account and no token metering' is an explicit use condition, and the flat-price/no-key framing further clarifies the context. There is no explicit 'use X instead when...' routing and no exclusions, even though llm_completion sits right next to it in the sibling list.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources