agentring
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XAI_API_KEY | No | Key for Grok Voice, if that is the voice provider. | |
| GEMINI_API_KEY | No | Key for Gemini Live, the default voice AI (only needed for the call tool). | |
| OPENAI_API_KEY | No | Key for OpenAI Realtime, if that is the voice provider. | |
| PHONIC_API_KEY | No | Key for Phonic, if that is the voice provider. | |
| AGENTRING_API_KEY | Yes | The relay's API key (starts with ak_). | |
| AGENTRING_RELAY_URL | Yes | URL of your agentring relay, e.g. https://relay.example.com (self-hosted; see docs/setup.md). | |
| AGENTRING_VOICE_PROVIDER | No | Voice AI for calls: gemini, openai, grok, phonic or local. | gemini |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
agentring reaches the user on their phone. Use send_message for anything that can wait and get_replies to read their answers (wait_s to wait for one). Use call only when it is urgent or a conversation is really needed: the phone rings and a voice AI talks to the user for you, then you get the transcript.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_messageB | Send a text message to the user's phone (it shows as a notification they can reply to). |
| get_repliesA | The user's new replies (each one is returned once). With wait_s, waits up to that many seconds for a reply if there is none yet. |
| callA | Call the user's phone; it rings like a real call. When they answer, a voice AI tells them why you are calling, talks with them, and hangs up when done. Returns the transcript. Blocks until the call ends (or nobody answers, ~30 s of ringing; then the reason and context are sent as a message, |
| statusA | Whether the relay is reachable and which phones are paired. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct action: outbound text (send_message), inbound text (get_replies), outbound voice (call), and health/pairing info (status). The only near-overlap is send_message vs call, but the modality difference (text notification vs live voice call) is stated explicitly, so misselection is unlikely.
Two tools follow a clean verb_noun pattern (send_message, get_replies) while the other two are a bare verb (call) and a bare noun (status). Still readable and unambiguous, but the convention is mixed rather than predictable.
Four tools is a tight, well-scoped surface for a phone-relay server; every tool has a clear role. It sits at the thin end—one or two more (e.g. message history or a cancel/hangup) would round it out without bloat.
The core loop (send text, read replies, place a call, check relay health) is covered with no obvious dead ends. Gaps are minor: no message/call history beyond the consume-once replies, and no explicit cancel/hangup or delivery-status check.