Skip to main content
Glama

Foundry: prepaid AI compute in USDF

Chat completion

chat

Runs a chat completion through the metered gateway and returns the text with its receipt (tokens, price, cost, balance, settlement). Needs Authorization: Bearer sk_... and spends from that key's balance; a hold for the maximum cost is placed first. Not streamed. Output is capped at 4096 tokens. A call without a progress token answers within 55 s of arriving. With a progress token, progress is sent every 15 s and the call may run 10 minutes, so the client must reset its timeout on progress (resetTimeoutOnProgress: true in the TypeScript SDK) or wait that long. At its deadline, or when the client's connection closes, a call is cut: the text produced so far is returned with finish_reason "length" and billed on the provider's usage report where the provider gives one, otherwise on an estimate never above max_tokens; for a model whose reasoning is not streamed, at the held output budget. Cancellation messages are not supported: a call the client stops waiting for without disconnecting runs to completion or its deadline and is billed. With no key, the call is paid with x402 in USDF (Permit2) or USDG (EIP-3009), as POST /x402/v1/chat/completions: without a payment it returns isError with the payment requirements (x402Version, resource, accepts) as structuredContent; sign one accept and call again with the payment in _meta["x402/payment"], the payment argument or the PAYMENT-SIGNATURE header. The quote is the call's maximum cost at the published price (prompt at one token per byte, output at max_tokens, capped as above, no minimum), paid up front; the call is charged what it uses at that price and the rest is refunded in the asset paid, the gateway paying the gas. A paid call runs to its end or its deadline whether or not the client waits and returns the receipt and _meta["x402/payment-response"]; at the deadline the text so far is returned with finish_reason "length" and a note, charged what it used and the rest refunded. A call no provider accepted before its deadline, or whose provider failed or ended with nothing, is refunded in full in the asset paid; so is one cut by the deadline after the provider accepted it, with nothing produced. A call with less than 20 s left before its deadline is refused before the payment is settled (deadline_too_close), nothing charged. MPP clients pay the same quote: the payment-required result also carries _meta["org.paymentauth/payment-required"] with evm charge challenges (USDG by EIP-3009 authorization, USDF by Permit2); call again with the credential in _meta["org.paymentauth/credential"], and the paid result carries _meta["org.paymentauth/receipt"].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYesModel id from list_models
paymentNoWith no key: the x402 payment for this call's quote, as the PAYMENT-SIGNATURE value (base64 JSON) or the payload object; _meta["x402/payment"] and the PAYMENT-SIGNATURE header are read too
messagesYesChat messages in the OpenAI format: objects with a role (system, user, assistant or tool) and content (text, or an array of content parts)
max_tokensNoOutput token budget, a positive integer; defaults to the model's default_max_output, capped at max_output
temperatureNoSampling temperature, 0 to 2

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

With annotations present, the bar is only that the description add behavior beyond them, and this one is exceptionally forthcoming: an up-front hold for maximum cost, non-streamed output, a 4096-token cap, the 55 s / 15 s / 10 min timing model, truncation to finish_reason 'length', refund and gas behavior, the 20 s deadline_too_close refusal, and that cancellation messages are unsupported and stopped-but-not-disconnected calls are still billed. The declared non-read-only, non-idempotent, open-world profile is consistent with this 'metered, spending, stateful' account.

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

Conciseness3/5

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

The first sentence is well front-loaded, but the body is a single dense paragraph mixing key-auth, x402, MPP, refunds and deadlines. It is not padded with fluff, yet the truncation-to-'length' rule is effectively restated for the x402 case, and the material would be far more usable as structured bullets. Size is defensible for the complexity but structure is poor.

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?

There is no output schema, so the description must cover returns, and it does: text plus a receipt with tokens, price, cost, balance and settlement, plus _meta x402/payment-response and org.paymentauth/receipt. For a tool involving metered payment, proofs and deadline-driven refunds, the failure modes an agent could hit are all covered.

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 description coverage is 100%, so a 3 is the baseline. The description exceeds it by explaining the payment parameter's mechanics beyond the schema text: sign one accept and resubmit via _meta["x402/payment"], the payment argument, or the PAYMENT-SIGNATURE header, and by tying max_tokens to the hold, the 4096 cap, and the output-price calculation.

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?

The opening sentence gives a specific verb and resource: 'Runs a chat completion through the metered gateway and returns the text with its receipt (tokens, price, cost, balance, settlement).' That is unambiguous and far better than a tautology. However, it never explicitly routes the agent relative to siblings like quote, receipt or x402_pay, so the differentiation is left implicit.

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?

The description gives rich conditional usage: with a Bearer key it spends the key's balance, with no key it switches to the x402 flow, and it spells out the progress-token timeout semantics and the deadline/cancellation conditions. What is missing is guidance on when to call this tool versus the sibling quote/receipt/x402_pay tools, so context selection is implied rather than stated.

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