Skip to main content
Glama

Foundry: prepaid AI compute in USDF

Chat completion

chat

Runs a chat completion and returns the text with its receipt (tokens, price, cost, balance, settlement). With an API key it spends from that key's balance, holding the most the request can cost 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 (signature transfer) or USDG (signed transfer), 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 signed transfer authorization, USDF by signature transfer); call again with the credential in _meta["org.paymentauth/credential"], and the paid result carries _meta["org.paymentauth/receipt"].

Input 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.3/5.0
Behavior5/5

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

Annotations only give the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false); the description goes far beyond, disclosing fund holding up front, refund mechanics in the paid asset, what happens at deadline and on disconnect, billing on provider usage vs. estimate, the no-cancellation rule, and the 20-second refusal with nothing charged.

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?

Front-loaded with the core action and no filler sentences, but it is one long, undifferentiated paragraph with no headings or bullets, and the deadline/cut/refund behavior is restated several times (connection-close cut, paid-call deadline, provider-accepted-then-cut), which costs the reader on re-parse.

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 no output schema, the description carries the return contract itself — text plus receipt fields, finish_reason "length" on truncation, structuredContent payment requirements on the first unpaid call, and the _meta receipt keys — which is exactly what an agent needs for a paid, non-idempotent, open-world call.

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, and the description adds real meaning on top: it establishes that payment applies only "with no key," that model ids come from list_models, and that the payment value may also arrive via _meta["x402/payment"] or the PAYMENT-SIGNATURE header rather than the named argument.

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?

"Runs a chat completion and returns the text with its receipt" is a precise verb+resource statement, and the scope (non-streamed, 4096-token output cap, paid per call) immediately separates it from read-only siblings like balance, list_models and receipt.

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

Usage Guidelines3/5

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

It branches clearly on the two payment modes (API key balance vs. no-key x402/MPP), which is genuine usage guidance for this tool. However it never routes the agent to the siblings that exist for that purpose — quote/quote_tool for previewing the cost, balance for funds, receipt for retrieving receipts — so the agent must infer whether to call those first.

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