Loading ToolBench
MCP server providing access to the sipgate API for account information, phone numbers, SMS messaging, call history, and device management
This server has well-structured tool definitions with proper naming conventions and mostly complete schemas. However, it suffers from critical gaps in parameter descriptions, missing output schema documentation, and weak error handling guidance. All 7 tools follow verb_noun naming (get_*, send_, initiate_), which is excellent. Schemas are present for all tools. However, most parameter descriptions are minimal (e.g., 'The SMS ID to use for sending' lacks format/constraint details), and critically, NO tools document their output schemas, the LLM has no way to know what fields to expect in responses. Error handling exists but provides no recovery guidance. The STDIO-only transport is a hard blocker for production use with hosted MCP clients.
Get information about your sipgate account
Get call history
Get a list of devices associated with your sipgate account
Get a list of phone numbers associated with your sipgate account
Get information about the authenticated user
Initiate a phone call
Send an SMS message
NO TOOL returns documented output schema. LLMs cannot infer what fields the response contains, breaking downstream tool chaining and forcing agents to guess at field names. For example, get_phone_numbers() likely returns a list with phone number objects, but does each contain 'id', 'number', 'type', 'alias'? Unknown.
Parameter descriptions lack constraint details. E.g., 'The SMS ID to use for sending (e.g., \'s0\')' mentions one example but does not explain the format (must match /^s\d+$/?), range, or how to discover valid SMS IDs. Similarly, 'recipient\'s phone number in E.164 format' assumes the LLM knows what E.164 is, no fallback or validation hint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 16 | - | v1 |
Missing error recovery guidance. Error handling exists (line 'try/catch' in handlers), but errors only emit McpError with generic messages like 'Sipgate API error: {error.message}'. No guidance for the LLM on whether to retry, how to fix input, or what alternative actions to take. E.g., if send_sms fails due to invalid recipient, does the LLM know to call get_phone_numbers() first?
Tool descriptions are generic and lack 'when to use' context. E.g., 'Get information about your sipgate account' does not explain what this returns or when an agent should call it vs. get_user_info(). Agents need hints like 'Returns account billing, subscription status, and feature enablements. Call this to check if SMS is available before calling send_sms().'
send_sms and initiate_call are destructive operations (WRITE risk) but lack confirmation or dry-run support. An agent could accidentally send an SMS to the wrong recipient or dial the wrong number. No mention of idempotency, retryability, or confirmation workflow.
get_call_history accepts optional 'types' enum array but does not explain what each type returns or which is most common. 'CALL', 'VOICEMAIL', 'FAX', 'SMS', are these mutually exclusive filters or cumulative? What does a voicemail entry contain vs. a call entry?
Authentication via environment variables (SIPGATE_TOKEN_ID, SIPGATE_TOKEN) is exposed in plaintext startup code and is checked at server init time. If environment variables are missing, the entire server fails to start with a cryptic error. Better to validate lazily on first tool call and return a clear error.