Loading ToolBench
MCP server for managing SignalWire communications infrastructure, including AI agents, call flows, SWML scripts, phone numbers, webhooks, RELAY applications, knowledge management, call testing, and diagnostics.
Strong foundation with 15 well-named tools, comprehensive input schemas using Zod, and consistent output envelopes. All tools have descriptions (avg 150 chars) and parameter annotations. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present and accurate. Key gaps: descriptions lack explicit WHEN/WHY guidance for agent selection; some parameter descriptions are minimal (e.g., 'Phone number in E.164 format' without explaining why E.164 matters); no documented error recovery paths; confirmation gates present but not consistently explained as preventing accidental execution.
Add one URL-backed document to Datasphere for RAG ingestion. Use to index a knowledge source. Ingestion is asynchronous; the tool reports the returned status truthfully without polling.
Create or update a named RELAY application registration and connect a development number to it. Use for RELAY-based real-time call control applications.
Route a development number to externally deployed SWML or cXML at an HTTPS URL. Use to point a number at your own application endpoint. Configures routing only; it does not deploy or probe the external app.
Interact with an AI session already running on a live call (message, hold, unhold, stop). Use only when an AI session is active on the call.
Perform a high-level lifecycle action (end or transfer) on a live test call. Use with a call id from a prior test call.
Parameter descriptions lack actionable constraints and format guidance. E.g., 'Phone number in E.164 format' does not explain why E.164 is required or what happens if a different format is passed. LLMs cannot infer validation rules from names alone.
Tool descriptions do not explain WHEN to use each tool or how to choose between similar tools. E.g., signalwire_deploy_ai_agent vs signalwire_deploy_call_flow_version both deploy resources but the distinction is unclear from descriptions alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
Create or update one managed Fabric AI Agent (by exact id or unique name) and optionally bind a development number to it. Use after discovering an agent definition you want to make reachable.
Deploy a known version of an existing Call Flow and optionally bind a development number to it. Use when a Call Flow is authored and you want to publish a specific version live.
Create or fully replace a managed SWML Script (Calling or Messaging) from a validated document. Use to store SWML behavior in the Dashboard. Does not bind a number directly.
Assemble read-only evidence about a past voice call or message from SignalWire logs. Use to diagnose why an interaction succeeded or failed. Returns evidence, inferences, and gaps.
Exercise one non-AI media feature (playback, recording, digit collection, detection, transcription) on a live call. Start actions return a control id for a later stateless stop.
Discover SignalWire phone numbers, Fabric resources (AI agents, call flows, SWML scripts, RELAY applications, webhooks), and Datasphere documents. Read-only. Use this to find identifiers and inspect what exists before configuring or testing.
Purchase one exact phone number previously returned by discovery. Use to acquire a development number. Carrier charges may apply; does not search or select automatically.
Start one bounded outbound development call that speaks given text and hangs up. Use to verify voice reachability. Returns the call id and initial status; it does not claim the call was answered.
Send one text-only development SMS via the Compatibility API. Use to verify messaging reachability. Returns the message SID and initial status as accepted.
Read-only semantic search over Datasphere documents. Use to retrieve relevant excerpts and scores from indexed knowledge.
No documented error recovery paths. Tools return errors but descriptions do not explain what the LLM should do next (retry, ask user, call a different tool). E.g., if signalwire_find_resources returns 'agent not found', should the agent create one or ask the user?
Confirmation gates (confirm_route_change, confirm_purchase, confirm_call) are present but not explained in tool descriptions as preventing accidental execution. LLMs may not understand why these parameters exist or when to set them to true.
signalwire_exercise_call_feature has ambiguous parameter relationships. The 'feature' enum (play, record, collect, detect, transcribe) determines which optional parameters apply (e.g., 'text' only for 'play'), but this dependency is not documented in parameter descriptions.