F
licenseNot graded
qualityD
maintenanceEnables AI-driven interaction with Twilio call services, including initiating outbound calls and retrieving call history via FastMCP tools.
Bond-OpenAI MCP
by Caezarr
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Bond-OpenAI MCPcall the Italian restaurant on Main St to reserve a table for two at 7pm"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Bond-OpenAI — voice actions for every software agent
One local MCP server. Any compatible agent. One phone task completed.
Bond-OpenAI gives Bond, Codex and other MCP-compatible software a safe telephone action. Clone the repository, bootstrap once, connect the MCP, and let the agent turn a task such as “call the restaurant and reserve a table” into a real consented conversation.
The product
Bond task / Codex prompt
↓
Local Bond-OpenAI MCP
classify → clarify → preview → call
↓
Fredo phone runtime
Twilio verified caller + Deepgram voice agent
↓
Structured result returned to the originating taskBond finds the work. Codex understands the intent. Fredo makes the call.
Related MCP server: asterisk-voice-mcp
Quick start
git clone https://github.com/Caezarr/Bond-OpenAI.git
cd Bond-OpenAI
./scripts/bootstrap.sh
uv run bond-mcp doctor
uv run bond-mcp serveThe first run installs pinned dependencies and local tools. The user never
copies shell commands from an agent response and never puts a secret in a task.
For the public demo, provider credentials stay in the operator relay and the
user only needs the public demo/profile.json configuration. A local .env
is required only when running the provider directly.
MCP tools
bond.classify_task(task_text, context)
bond.create_phone_task(task_input, idempotency_key)
bond.get_phone_task_status(call_id)
bond.cancel_phone_task(call_id)The same contract works from Bond, Codex, an IDE agent, or any MCP client. The adapter is local and provider-neutral; Fredo is the default phone executor.
See docs/MCP.md for the two-click client setup. See docs/DEMO-RELAY.md for the no-credential jury flow.
Safety by default
explicit consent is required;
E.164 destinations and Fredo's exact allowlist are enforced;
only a verified caller identity is used;
a human confirmation happens before dialing;
one active call and a 180-second cap;
recording is disabled;
the agent discloses its synthetic voice and no recording;
duplicate requests are idempotent;
raw audio, secrets and full phone numbers stay out of logs.
Rejecting the preview means zero carrier call.
Project goals
GOAL-BOND-MCP.md — software and MCP contract.
GOAL-BOND-DESIGN.md — website, deck and visual system.
GOAL-BOND-VOICE.md — goal index.
Current runtime boundary
The current phone engine uses Twilio for PSTN access and Deepgram for hosted speech recognition, dialogue and text-to-speech. The MCP itself runs locally. This repository does not claim local inference, recording, voice cloning or unattended bulk calling.
Available Tools
4 toolsbond.cancel_phone_taskC
Cancel an active phone task.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| call_id | Yes |
TDQS
C2.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states 'Cancel' without side effects, reversibility, or permissions; no annotations to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Too brief, lacks necessary context beyond basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output details, error conditions, or prerequisites; inadequate for single-param action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and description does not explain call_id parameter.
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?
Description clearly states cancel action on phone task, differentiating from create/get status/classify siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use cancel vs other tools like get_phone_task_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bond.classify_taskC
Classify whether a task needs a phone call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| task_text | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states the purpose, omitting side effects, authentication needs, or whether it is read-only. The agent cannot assess safety or side effects.
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 description is extremely concise (one sentence). While front-loaded, it may be under-specified for a classification task with nested parameters. Some additional detail would improve usability without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (classification, nested object parameter, no output schema), the description is grossly incomplete. It does not specify return type, interpretation of results, or how the classification is determined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the meaning or format of any parameter. Critical context for 'task_text' and 'context' is missing, leaving the agent without guidance.
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 description clearly states the tool classifies whether a task needs a phone call, using a specific verb 'classify' and resource 'task'. It distinguishes from siblings (create, get status, cancel) by focusing on classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bond.create_phone_taskC
Validate, preview and create one consented phone task.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task_input | Yes | ||
| idempotency_key | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions 'validate' and 'preview' but does not elaborate on behavior, failure modes, idempotency despite idempotency_key, or consent requirements.
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 description is a single sentence, which is short but lacks necessary details. Not concise enough to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a complex object parameter, the description is severely incomplete. It does not cover return value, error handling, or input structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions are entirely missing. The schema has 0% coverage and the description does not explain 'task_input' (object) or 'idempotency_key' (string) beyond their names.
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 clearly states the tool creates a phone task, with additional steps of validate and preview. It distinguishes from siblings like classify, get status, and cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings. The description only states what the tool does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bond.get_phone_task_statusC
Get a structured phone task result.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| call_id | Yes |
TDQS
C2.1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the purpose without indicating side effects, error handling, or read-only nature. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks necessary detail, so it does not earn its place well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions, and no annotations, the description is far too minimal. It fails to provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate, but it does not mention the 'call_id' parameter at all. The agent gets no help understanding what the parameter represents.
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 description clearly states the verb 'Get' and the resource 'structured phone task result', and it distinguishes from siblings like classify, create, and cancel. However, it could be more specific about what 'structured' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as after creating a task or prerequisites. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3/5.0
Disambiguation5/5
Each tool has a distinct purpose: classifying, creating, checking status, and canceling phone tasks. There is no functional overlap, and descriptions clearly differentiate them.
Naming Consistency4/5
Three tools follow 'bond.<verb>_phone_task' pattern, but 'bond.classify_task' drops 'phone', causing a minor inconsistency. However, all use snake_case and the bond prefix.
Tool Count5/5
Four tools is well-scoped for a phone task workflow—neither too few nor too many. Each tool serves a necessary step in the lifecycle.
Completeness4/5
Covers the primary lifecycle (classify, create, get status, cancel). Missing an update operation, but the domain likely doesn't require it; the set is complete for basic management.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Give AI agents real phone numbers, messages, and voice calls via MCP.
Give AI agents a phone number. Voice calls, SMS, and phone number management for MCP clients.
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Let AI agents place real phone calls from your verified number, with transcripts and recordings.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to place VoIP phone calls via Asterisk, play TTS messages, capture DTMF input, and optionally record and transcribe voice responses.MIT
- AlicenseNot gradedqualityBmaintenanceA hosted MCP server that enables AI agents to place real phone calls from a verified caller ID, with async call management and built-in safety controls.771MIT
Dial MCP Serverofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to provision phone numbers, send SMS, place AI voice calls, and react to inbound events via the Dial communication stack, all through MCP tools.174MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Caezarr/Bond-OpenAI'
If you have feedback or need assistance with the MCP directory API, please join our Discord server