Voipstudio MCP
Server Details
VoIPstudio provides an MCP server for compatible AI assistants and MCP clients. The public bootstrap endpoint is https://mcp.voipstudio.workers.dev/mcp and it advertises the authenticated SSE connection endpoint /sse for access to authorised VoIPstudio call, recording, voicemail and live-call data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of VoIP data: CDRs, call history per number, live calls, recording audio, recordings with transcripts, and voicemails. There is no overlap in functionality.
All tool names follow a consistent 'get_<resource>' pattern in snake_case, making them predictable and easy to remember.
With 6 tools covering essential read-only operations for a VoIP system (CDRs, live calls, recordings, voicemails, history), the count is well-scoped and each tool serves a clear purpose.
The server covers the main data types for a read-only VoIP API, but lacks a dedicated tool to retrieve a single CDR by ID (though filtering can approximate that). Minor gap but overall sufficient.
Available Tools
6 toolsget_cdrsBRead-onlyInspect
Fetch call detail records (CDRs) from VoIPstudio — duration, cost, disposition etc. Supports filtering by any field: {"call_id":"number","duration":"number","id":"number","live_id":"number","is_root":"boolean","root_live_id":"number","parent_live_id":"number","user_id":"number","sip_endpoint_id":"number","server_id":"number","type":"string","calldate":"string","clid":"string","src_id":"string","src_name":"string","src":"string","src_ua":"string","src_codec":"string","dst_id":"string","dst":"string","dst_name":"string","dst_ua":"string","dst_codec":"string","billsec":"number","disposition":"string","destination":"string","context":"string","rate":"number","charge":"number","t_cause":"string","info":"string","labels":"array","metadata":"object","nb_notes":"number","nb_children":"number"}
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| sort | No | Sorts results by given property and direction | |
| limit | No | Number of CDRs to fetch | |
| filters | No | Optional filters. Examples: - Date range: [{property:"some_date_propery",operator:"gte",value:"2026-01-01 00:00:00"},{property:"some_date_propery",operator:"lte",value:"2026-12-31 23:59:59"}] - By string: [{property:"some_string_property",operator:"eq",value:"EXPECTED VALUE"}] - Greather than: [{property:"some_number_property",operator:"gt",value:10}] As a 'property' you can use any property from output schema. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| total | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the 'Fetch' verb is consistent. The description adds that filtering is supported on many fields, but does not disclose pagination behavior, rate limits, or any side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states purpose, the second lists filterable fields in a compact JSON format. No redundant words, though the field list is long but necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description does not explain pagination, sorting, or filter construction beyond 'supports filtering'. The schema covers some details, but the description could be more helpful for a tool with nested parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the list of filterable fields but does not add any nuance beyond what the schema already documents for page, sort, limit, or filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Fetch' and the resource 'call detail records (CDRs) from VoIPstudio', and distinguishes from siblings like get_live_calls, get_recordings, etc. by focusing on raw historical CDR data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings (e.g., get_history_for_number for per-number history). The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_history_for_numberARead-onlyInspect
List all conversations (call/SMS) with given number on the VoIPstudio account.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | ||
| toDateTime | No | Datetime (YYYY-MM-DD H:i:s) | |
| fromDateTime | No | Datetime (YYYY-MM-DD H:i:s) |
Output Schema
| Name | Required | Description |
|---|---|---|
| history | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's addition that it lists conversations (call/SMS) is helpful but minimal. It does not disclose other behavioral traits like pagination, result limits, or error handling, which would be expected for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the purpose without any filler or redundant information. It is perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality but lacks details on how date parameters affect results, ordering, pagination, and how this tool differs from siblings like get_cdrs. Given the simple nature and existence of output schema, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two parameters have descriptions), so the baseline is 3. The description adds that the 'number' parameter is the focus ('with given number'), but it does not specify format or examples, and the optional date parameters are not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'List', the resource 'conversations (call/SMS)', and the constraint 'with given number' on the VoIPstudio account. This distinguishes it from sibling tools like get_cdrs, get_live_calls, get_recordings, and get_voicemails, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus the listed sibling tools. It lacks context such as prerequisites, typical use cases, or when to avoid it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_live_callsARead-onlyInspect
List all currently active (live) calls on the VoIPstudio account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| total | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by specifying the scope (live calls only). It provides context about the nature of the data without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all necessary information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description fully covers the tool's purpose. It tells the agent exactly what the tool does without needing further details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is trivial (100%). With no parameters, the baseline is 4, and the description adds no extra parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all currently active (live) calls on the VoIPstudio account, using a specific verb and resource. It distinguishes from sibling tools like get_cdrs (completed calls) and get_recordings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing live calls, but does not explicitly state when to use it versus alternatives like get_cdrs for history. The context is clear but lacks exclusions or explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recording_audioARead-onlyIdempotentInspect
Get a direct download URL for a call recording MP3 audio file by recording ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recording ID (the 'id' field from get_recordings results) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| note | Yes | |
| called | No | |
| caller | No | |
| mp3_url | No | |
| duration | No | |
| timestamp | No | |
| auth_header | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's safety profile is covered. The description adds that it returns a direct download URL for an MP3 file, which is consistent and provides no contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's purpose. Every word contributes meaning, with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, presence of output schema, and clear annotations, the description fully informs the agent about the tool's behavior. It does not need additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value to the parameter by stating that 'id' is the recording ID from get_recordings results, linking to a sibling tool. This cross-reference goes beyond the schema's generic description, aiding correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's action: 'Get a direct download URL for a call recording MP3 audio file by recording ID.' It specifies the resource (call recording MP3 audio file) and the operation (get direct download URL), distinguishing it from siblings like get_recordings which likely return metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: it provides a direct download URL given a recording ID. While it does not explicitly state when not to use it, the simple purpose and sibling tools (e.g., get_recordings for listing) imply appropriate use. Could be improved by suggesting to use after get_recordings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recordingsARead-onlyInspect
Fetch call recordings from VoIPstudio with transcripts, summaries and CX scores. Supports filtering/sorting by any field: {"call_id":"number","dst_name":"string","transcript":"string","id":"number","live_id":"number","user_id":"number","sip_endpoint_id":"number","type":"string","src_id":"string","src":"string","src_name":"string","dst_id":"string","dst":"string","context":"string","timestamp":"datetime","caller":"string","called":"string","duration":"number","size":"number","summary":"string","sentiment":"string","metadata":"object","cx_score":"number","transcript_speakers":"array"}
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| sort | No | Sorts results by given property and direction | |
| limit | No | Number of recordings to fetch | |
| filters | No | Optional filters. Examples: - Date range: [{property:"some_date_propery",operator:"gte",value:"2026-01-01 00:00:00"},{property:"some_date_propery",operator:"lte",value:"2026-12-31 23:59:59"}] - By string: [{property:"some_string_property",operator:"eq",value:"EXPECTED VALUE"}] - Greather than: [{property:"some_number_property",operator:"gt",value:10}] As a 'property' you can use any property from output schema. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| total | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat safety. It adds context about the content (transcripts, summaries) but no behavioral details like rate limits or error handling. There is an internal annotation contradiction (readOnly=true vs idempotent=false), but the description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence contains a large inline JSON list of fields, making it less concise. It is adequate but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the main purpose and filtering capability. Missing explicit usage guidelines, but otherwise complete for a read-only tool with documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds marginal value. It summarizes that filtering/sorting works on any field and lists fields, but the schema already details each parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and resource 'call recordings from VoIPstudio'. It distinguishes itself from sibling tools by mentioning transcripts, summaries, and CX scores, which other tools like get_recording_audio or get_live_calls do not offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching recordings with analysis data but does not explicitly state when to use this tool over siblings. No mention of prerequisites 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.
get_voicemailsBRead-onlyInspect
Fetch voicemail messages from VoIPstudio. Supports filtering by: {"id":"number","live_id":"number","parent_live_id":"number","extension_id":"number","caller":"string","callerid":"string","dialled":"string","origtime":"datetime","duration":"number","folder":"string","is_new":"boolean","transcript":"string"}
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| sort | No | Sorts results by given property and direction | |
| limit | No | Number of voicemails to fetch | |
| filters | No | Optional filters. Examples: - Date range: [{property:"some_date_propery",operator:"gte",value:"2026-01-01 00:00:00"},{property:"some_date_propery",operator:"lte",value:"2026-12-31 23:59:59"}] - By string: [{property:"some_string_property",operator:"eq",value:"EXPECTED VALUE"}] - Greather than: [{property:"some_number_property",operator:"gt",value:10}] As a 'property' you can use any property from output schema. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| total | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds the list of filterable fields beyond schema. No contradictions, but does not disclose any additional behavioral traits like pagination details or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with verb and resource, and includes structured JSON list of filter fields. Somewhat verbose with the JSON inline, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and well-documented parameters in the input schema, the description covers the core purpose and filter capabilities sufficiently. Could mention default pagination or sorting behavior, but schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage), but description adds a detailed list of filterable field names (e.g., id, caller) that are not in the schema, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch voicemail messages from VoIPstudio' with specific verb and resource. Does not explicitly differentiate from sibling tools like 'get_recordings' or 'get_cdrs', but the filtering field list provides some specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool versus alternatives. Lacks context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!