Sats4AI - Bitcoin-Powered AI Tools

open_voice_bridge

Open a phone call you drive one turn at a time: we dial, transcribe what the other side says, and speak whatever text you send. You call voice_bridge_say to talk, poll_voice_bridge to read transcripts, end_voice_bridge to hang up. ⚠ Turn-based, NOT full-duplex conversation. After the callee stops talking, about 2 seconds of ours pass before your reply starts to play (we recognise the end of their turn, then speech starts under a second after you send the text), on top of your own model's thinking time: slower than the ~0.8s a natural back-and-forth needs. The callee cannot interrupt you while you speak. Pass filler (a short phrase such as 'One moment, please.') to cover a slow reply: we say it once if you have not started answering about 3.5 seconds after they stop. The loop: poll_voice_bridge with waitMs (e.g. 20000) returns when the callee has finished talking; answer with a short voice_bridge_say (one or two sentences); repeat. Good for: leaving a spoken message, navigating a voice-driven IVR (keypad tones are not supported yet), reading something out, a slow exchange where a pause is fine. For a real conversation with a human, use ai_call — we run the agent at conversational speed and return the transcript. Unused deposit time is refunded automatically when the call ends — including when the callee hangs up. Pass refundAddress (a Lightning address your user gave you; never invent one) and the remainder is SENT there with no further action; without it the refund is held as a claimable LNURL-withdraw link returned by end_voice_bridge. Use this when the content of the call must never leave your side, and the pace can tolerate a pause between turns. When NOT to use: not for fully-managed agent-style calls where we handle the brain (use ai_call). Not for one-shot TTS broadcasts or IVR playback (use place_call). Not when live transcript polling adds no value — the per-turn overhead isn't worth it. Privacy: transcripts held in memory only, garbage-collected 30 minutes after the call ends; call audio is never persisted. Pay with Bitcoin Lightning — no telecom account, no signup. Requires create_payment with toolName='voice_bridge_open', phoneNumber, durationMinutes. Deposit is priced per destination off the carrier rate sheet and is BTC-pegged, so call create_payment for the exact figure; premium-rate and satellite ranges are refused.

Input Schema

Name	Required	Description
`codec`	No	PCMU 8kHz (default, universal) or L16_16000 for HD voice when both endpoints support it
`filler`	No	Optional. A short phrase (at most 60 characters) we say ONCE when you are slow: if about 3.5 seconds pass after the callee stops talking and your voice_bridge_say has not started, the callee hears it, so they know you are still there. Example: "One moment, please." Write it in the callee's language. It is made while the phone rings and spoken in our default voice. It plays at most once until you speak again, the callee is not heard while it plays, and poll_voice_bridge then shows a filler_played event (do not say "one moment" yourself). Leave it out for a voicemail or a phone menu, where it is noise, and when you wait for long pauses (quietMs of several seconds): it would fire inside the pause and cut into their next words.
`greeting`	No	Spoken the instant the callee answers (max 500 chars). Synthesized while the phone rings, so there is no pause before the first word — without it the callee hears silence until your first voice_bridge_say lands. Strongly recommended for any call a human answers.
`language`	No	BCP-47 language tag (default en-US). See /api/l402/voice-bridge/coverage for the matrix.
`paymentId`	Yes	Valid payment ID from create_payment (toolName=voice_bridge_open)
`sttEnabled`	No	Default true. Set false for TTS-only broadcast calls.
`ttsEnabled`	No	Default true. Set false to bring-your-own-audio via voice_bridge_say.
`phoneNumber`	Yes	Destination phone number in E.164 format (e.g., +14155550100)
`refundAddress`	No	Lightning address of YOUR user (for example name@wallet.com), only if the user gave you one. Never invent or guess an address: the refund is paid out at once and cannot be called back. The unused deposit is sent here when the call ends. With no address, or if that payment fails, the refund waits as an LNURL-withdraw link.
`durationMinutes`	No	Deposit for N minutes, 2-30 (default 3). Unused time refunded.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / refundAddress / description

Previous value: -"Lightning address (e.g. you@wallet.com). Strongly recommended: the unused deposit is sent here automatically when the call ends, so nobody has to claim anything. Without it the refund waits as an LNURL-withdraw link."New value: +"Lightning address of YOUR user (for example name@wallet.com), only if the user gave you one. Never invent or guess an address: the refund is paid out at once and cannot be called back. The unused deposit is sent here when the call ends. With no address, or if that payment fails, the refund waits as an LNURL-withdraw link."

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / filler

Added value: +{
+  "description": "Optional. A short phrase (at most 60 characters) we say ONCE when you are slow: if about 3.5 seconds pass after the callee stops talking and your voice_bridge_say has not started, the callee hears it, so they know you are still there. Example: \"One moment, please.\" Write it in the callee's language. It is made while the phone rings and spoken in our default voice. It plays at most once until you speak again, the callee is not heard while it plays, and poll_voice_bridge then shows a filler_played event (do not say \"one moment\" yourself). Leave it out for a voicemail or a phone menu, where it is noise, and when you wait for long pauses (quietMs of several seconds): it would fire inside the pause and cut into their next words.",
+  "maxLength": 60,
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / greeting

Added value: +{
+  "description": "Spoken the instant the callee answers (max 500 chars). Synthesized while the phone rings, so there is no pause before the first word — without it the callee hears silence until your first voice_bridge_say lands. Strongly recommended for any call a human answers.",
+  "type": "string"
+}

Changed1 schema field changedSep 21, 2026

changedInput schema / properties / refundAddress / description

Previous value: -"Lightning address for automatic refund of unused time"New value: +"Lightning address (e.g. you@wallet.com). Strongly recommended: the unused deposit is sent here automatically when the call ends, so nobody has to claim anything. Without it the refund waits as an LNURL-withdraw link."

First observedJul 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations carry only openWorldHint, so the description bears the load and delivers: turn-based not full-duplex, ~2s turn latency with the ~0.8s natural target as a comparison, callee cannot interrupt, filler fires at ~3.5s and only once, unused deposit refunded automatically on hangup including callee-initiated, refund paid out irreversibly vs. held as an LNURL-withdraw claim, transcripts GC'd after 30 minutes, audio never persisted, and premium-rate/satellite ranges refused. This is exactly the behavioral context annotations don't provide.

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 core concept and the poll/say loop, and every paragraph is information-dense rather than filler. It is long, and the filler behavior plus refund mechanics are restated across the description and schema, which is some avoidable duplication for a definition this size.

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?

For a 10-parameter, annotation-thin, no-output-schema tool, the description covers payment setup, call loop, timing budget, refund path, privacy, and failure modes. An agent has everything needed to open the call, drive it, and close it out correctly.

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, but the description adds real meaning beyond the schema: it tells the agent to call create_payment for the exact BTC-pegged figure rather than guessing a deposit, and it stresses 'never invent' a refundAddress and why (immediate, non-reversible payout). The filler and greeting semantics are mostly duplicated in the schema, so it earns one step above baseline rather than more.

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 opening states a specific verb and resource ('Open a phone call you drive one turn at a time') and immediately explains the mechanism: we dial, transcribe, and speak your text. It names the three loop partners (voice_bridge_say, poll_voice_bridge, end_voice_bridge) and contrasts itself with ai_call and place_call, so an agent can place it among siblings without opening a schema.

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?

Explicit when-to-use ('leaving a spoken message, navigating a voice-driven IVR, reading something out, a slow exchange') and an explicit 'When NOT to use' block naming ai_call for managed conversational calls and place_call for one-shot TTS/broadcast, plus the exclusion for cases where live polling adds no value. Prerequisites (create_payment with toolName='voice_bridge_open') are stated up front.

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

All Sats4AI - Bitcoin-Powered AI Tools tools Inspect

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.

open_voice_bridge

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources