Skip to main content
Glama

Sats4AI - Bitcoin-Powered AI Tools

create_payment

Create a Lightning invoice to pay for one AI service call. Returns JSON: { paymentId, invoice (BOLT11), amount (sats), expiresAt }. Each payment covers exactly one tool call — call this once per operation. Typical flow: list_models → create_payment → check_payment_status → call tool. The invoice expires in 10 minutes. Call list_models first to discover modelId values. modelId is optional — omit it to use the default (best) model. Some tools require extra params at payment time because pricing depends on them: generate_text requires prompt (price = f(char count)); text_to_speech requires text (price = f(char count) by tier); transcribe_audio / transcribe_translate take durationMinutes (10 sats/min — declare your audio length, default 1); send_sms, place_call, ai_call require phoneNumber; generate_video and animate_image require duration, and take an optional resolution (250-400 sats/sec by resolution — quote with the SAME duration and resolution you will execute with); edit_image requires resolution (1K=200, 2K=300, 4K=450 sats); epub_to_audiobook requires characterCount (total text characters in the book — price is per-character by voice tier, minimum 500 sats). If required params are missing, the response includes an error with the missing field names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ocrNoFor receive_fax: include the OCR text-extraction add-on (+200 sats). Must be set HERE at payment time — receive_fax refuses ocr=true at execution unless the charge covered it.
modeNoLegacy alias for generate_video: 'standard'→768p, 'pro'→2K. Prefer 'resolution'.
textNoRequired for text_to_speech: the exact text to synthesize (price is per-character by tier, locked to payment)
promptNoRequired for generate_text: the exact prompt (price calculated from char count, locked to payment)
messageNoRequired for send_sms: message text (max 1544 chars; billed per SMS segment, so longer or accented messages cost more)
modelIdNoOptional. AI model ID from list_models. Omit for default (best) model.
durationNoRequired for generate_video / animate_image: duration in seconds (5-15)
quantityNoUnits to pay for when the price scales: passes for boardingpass_wallet, pages for extract_document / extract_receipt / send_fax. Default 1 — under-counting is rejected at execution with the exact price to re-pay.
toolNameYesTool name to pay for (e.g., 'generate_text', 'generate_image', 'generate_video', 'send_sms', 'place_call')
resolutionNo768p (default) or 2K for generate_video / animate_image — priced by resolution × duration, native audio free; 2K is upscaled from a 768p render. 480p/720p/1080p are retired Seedance rungs, still accepted (480p/720p→768p, 1080p→2K). For edit_image: 1K=200, 2K=300, 4K=450 sats.
fileContextNoFor generate_text: include extracted file text if attaching a file (affects price)
phoneNumberNoRequired for send_sms and place_call: phone in E.164 format (e.g., +14155550100)
systemPromptNoFor generate_text: include if using a custom system prompt (affects price)
characterCountNoRequired for epub_to_audiobook: total text characters in the book (price is per-character by voice tier, minimum 500 sats). Send the count, not the book — the file goes to epub_to_audiobook itself. Execution re-derives the price from the real file and rejects a short-pay with the exact amount to re-pay.
generate_audioNoAccepted and IGNORED — H3 audio is native and always on, at no extra cost. There is no way to request a silent render.
durationMinutesNoMinutes of audio/call. Required for place_call with audioUrl (1-30); for transcribe_audio / transcribe_translate it sets the per-minute price (10 sats/min) — declare your audio length (default 1). Audio longer than paid is rejected + refunded at execution.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations present, the description carries the full behavioral burden. It discloses the return shape, the 10-minute expiry, the one-payment-per-tool-call rule, the 'SAME' duration/resolution requirement, underpayment rejection and refund behavior, and the error format for missing fields. This is rich, non-obvious behavioral context.

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?

The description is long but every sentence contributes to the tool's contract—purpose, flow, expiry, required scene parameters, and error behavior. It is front-loaded with the most important facts, although the long parameter-specific paragraphs are dense and could have been broken into a bullet list for faster parsing.

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?

No output schema is supplied, so the description correctly includes the return value. It also covers the full operational loop, the one-shot scope, timeout, price-determining parameters, and behavior of payment-time validation. Given the complexity of the parameter space, the description is complete enough for an agent to know exactly what to pass and what to expect.

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

Parameters5/5

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

Although schema coverage is 100%, the description still adds meaningful semantics by mapping parameters to specific tools and pricing rules. For example, it notes ai_call requires phoneNumber (the schema does not mention ai_call for that field), says transcribe durationMinutes default to 1, and emphasizes 'quote with the SAME duration and resolution you will execute with' — critical guidance not in the schema.

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?

The description opens with a clear action and resource: 'Create a Lightning invoice to pay for one AI service call.' It further narrows the scope by stating 'Each payment covers exactly one tool call', which distinguishes this tool from related operations like check_payment_status or request_refund even without naming them.

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?

Explains the typical flow 'list_models → create_payment → check_payment_status → call tool', instructs to 'call this once per operation', and explicitly says to call list_models first to discover modelId. It also flags when extra parameters are mandatory at creation time, so the agent knows what to provide when.

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.

TDQS

A4/5.0
Disambiguation4/5

Most tools have distinct purposes, but there is some overlap, especially among call tools (ai_call, place_call, open_voice_bridge) and image generation/editing tools (generate_image, edit_image, animate_image). Descriptions help differentiate, but an agent might still select the wrong one.

Naming Consistency4/5

The vast majority of tools follow a verb_noun pattern (e.g., generate_image, send_sms). A few exceptions exist (await_result, check_job_status, epub_to_audiobook) but the overall pattern is strong and predictable.

Tool Count3/5

With 50 tools, the server is very extensive. While each tool earns its place given the broad scope of AI services, the count feels high and could overwhelm agents, making selection less efficient.

Completeness5/5

The tool surface is remarkably comprehensive, covering generation, editing, conversion, communication, async management, payments, and error handling. There are no obvious gaps for the stated Bitcoin-powered AI toolkit purpose.