mcp-vapi

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources (assistants, calls, squads, phone numbers) and actions (create, get, list, update, delete, end). No overlap exists; for example, vapi_create_assistant and vapi_update_assistant are clearly differentiated by their operations on the same resource.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with the prefix 'vapi_' (e.g., vapi_create_assistant, vapi_get_call, vapi_list_squads). The naming is uniform across all 16 tools, using snake_case and clear action-resource pairs without any deviations.
Tool Count5/5
With 16 tools, the server is well-scoped for managing Vapi's core entities (assistants, calls, squads, phone numbers). Each tool serves a specific CRUD or operational function, and the count aligns with the domain's complexity without being excessive or insufficient.
Completeness5/5
The tool set provides complete CRUD and lifecycle coverage for all key resources: assistants, calls, squads, and phone numbers. It includes creation, retrieval, listing, updating, and deletion, plus operational tools like vapi_end_call, ensuring no gaps for agent workflows in this domain.
Average 3.2/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions configurable attributes but doesn't disclose whether this is a mutating operation (implied by 'Create'), what permissions are needed, whether there are rate limits, what happens on success/failure, or what the return value contains. This leaves significant gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured as a single sentence that front-loads the core purpose and enumerates key parameters. While it could be slightly more polished, every word serves a purpose and there's no redundancy.
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?
For a creation tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns an assistant ID), what errors might occur, authentication requirements, or how this tool relates to the broader Vapi workflow. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds marginal value by listing some key parameters (name, first message, system prompt, LLM model, voice) but doesn't provide additional context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
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 action ('Create') and resource ('Vapi voice assistant'), and lists key configurable attributes. It distinguishes from siblings like vapi_update_assistant or vapi_get_assistant by focusing on creation, but doesn't explicitly contrast with vapi_create_squad which creates a different resource type.
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 this tool versus alternatives like vapi_update_assistant for modifications or vapi_create_squad for creating a different entity. The description simply states what the tool does without providing context about prerequisites, timing, or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is 'permanently delete', which implies a destructive, irreversible operation, but lacks details on permissions required, side effects (e.g., impact on related calls or assistants), error handling, or confirmation steps. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple deletion operation and front-loaded with the key action, making it easy to parse quickly.
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?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address critical context like what 'permanently' entails (e.g., irreversibility), potential dependencies, or what happens post-deletion (e.g., success confirmation or error responses), leaving gaps that could hinder safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'squadId' parameter fully documented in the schema itself. The description adds no additional meaning beyond what the schema provides (e.g., format examples or sourcing guidance), so it meets the baseline score of 3 for high schema coverage without extra value.
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 action ('permanently delete') and resource ('a squad'), which is specific and unambiguous. However, it doesn't explicitly distinguish this tool from sibling deletion tools like 'vapi_delete_assistant' beyond the resource name, missing an opportunity to clarify what makes a squad different from other deletable entities.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the squad ID from a list operation), consequences of deletion, or when to choose this over similar tools like 'vapi_delete_assistant', leaving the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), which implies it's non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error handling, or what 'details' include. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core purpose and efficiently conveys the essential information without unnecessary elaboration.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' are returned, potential errors, or behavioral traits like idempotency. For a read operation with no structured output documentation, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'phoneNumberId' fully documented in the schema. The description adds no additional semantic context about the parameter, such as where to find the ID or format examples, so it meets the baseline for high schema coverage without compensating value.
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 action ('Get details') and resource ('specific Vapi phone number'), making the purpose evident. It distinguishes from sibling 'vapi_list_phone_numbers' by focusing on a single item rather than listing multiple, though it doesn't explicitly name this distinction.
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?
The description provides no guidance on when to use this tool versus alternatives like 'vapi_list_phone_numbers' or 'vapi_get_call', nor does it mention prerequisites such as needing a valid phoneNumberId. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns call IDs, status, cost, and basic info, but lacks critical details like whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, or error handling. For a list tool with 5 parameters, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the core purpose. Every sentence contributes: the first states the action and filtering capability, the second specifies return values. No wasted words, though it could be slightly more structured with bullet points for return fields.
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?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., read-only nature, pagination), doesn't explain the return structure beyond high-level fields, and provides no usage guidelines. For a list tool with filtering capabilities, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional filters' which aligns with the 5 parameters in the schema, but adds no specific meaning beyond what the schema already provides (schema description coverage is 100%). The baseline score of 3 is appropriate since the schema fully documents parameters, though the description doesn't compensate with additional context like filter combinations or examples.
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 action ('List calls') and resource ('calls'), and mentions optional filtering. However, it doesn't explicitly differentiate from sibling tools like 'vapi_get_call' (singular retrieval) or 'vapi_list_assistants' (different resource type), which would be needed for a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'vapi_list_calls' over 'vapi_get_call' for a specific call, or when to use it versus other list tools like 'vapi_list_assistants'. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions 'partial update' but doesn't disclose permission requirements, rate limits, idempotency, or what happens to unspecified fields. For a mutation tool, this leaves critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Update an existing assistant') and adds essential qualification ('partial update'). There's no wasted verbiage or redundancy.
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?
Given no annotations and no output schema, the description is insufficient for a mutation tool. It lacks details on permissions, error handling, response format, and behavioral traits like whether updates are atomic or reversible, leaving the agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds the key constraint 'partial update — only send the fields you want to change,' which clarifies usage beyond schema details, but doesn't provide additional semantic context for individual parameters.
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 ('Update') and resource ('existing assistant'), and specifies it's a partial update. However, it doesn't explicitly differentiate from sibling tools like vapi_update_squad, which has a similar pattern for a different resource.
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. It doesn't mention prerequisites (e.g., needing an existing assistant ID), contrast with vapi_create_assistant for new assistants, or specify error conditions like invalid IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action 'update' but doesn't specify whether this requires specific permissions, if changes are reversible, what happens to unspecified fields, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that efficiently conveys the core functionality without any wasted words. It's front-loaded with the main action and resource, making it easy to scan and understand quickly.
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?
Given the complexity of an update operation, lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like error handling, response format, or side effects. While the schema covers parameters well, the overall context for safe and effective use is incomplete, especially for a tool that modifies resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (squadId, name, members) with clear descriptions. The description adds minimal value by listing 'rename it or change its members,' which aligns with the schema but doesn't provide additional syntax, format details, or examples beyond what's in the structured fields.
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 action ('update') and resource ('squad'), specifying what can be modified ('rename it or change its members'). It distinguishes from sibling tools like vapi_create_squad and vapi_delete_squad by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from vapi_update_assistant, which might have similar functionality for a different resource.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing squad ID), exclusions, or comparisons to sibling tools like vapi_update_assistant. Usage is implied through the action 'update,' but no explicit context or decision criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'creates' a call, implying a write/mutation operation, but lacks details on permissions, side effects, error handling, or response format. The description doesn't address rate limits, authentication needs, or what happens after the call is fired.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief (two sentences) and front-loaded with the core purpose. Every sentence serves a purpose: the first states the action, the second highlights key requirements. No wasted words, though it could be slightly more structured.
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?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after the call is created, what the return value contains, error conditions, or important behavioral aspects. The description leaves too many contextual gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description mentions only 2 parameters (phoneNumberId and customerNumber) and adds minimal context about E.164 format. It provides no additional meaning beyond what's already in the comprehensive schema descriptions.
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 specific action ('Fire an outbound call') and resource ('using a Vapi assistant'), distinguishing it from sibling tools like vapi_get_call or vapi_end_call. It precisely communicates the core function without ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives like vapi_list_calls or vapi_end_call. It mentions required parameters but offers no context about prerequisites, timing, or exclusions for this outbound call operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the handoff functionality but doesn't cover critical aspects like required permissions, whether this is a mutating operation (implied by 'Create'), error conditions, rate limits, or what the response contains. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the core purpose. The second sentence adds useful context about use cases without being redundant. It could be slightly more structured but efficiently conveys key information without waste.
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?
Given the complexity of creating a multi-assistant squad with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., mutation effects, permissions), response format, error handling, and doesn't fully compensate for the absence of structured metadata. For a creation tool in this context, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (name and members). The description doesn't add any parameter-specific information beyond what's in the schema, such as format details for members beyond the example. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 action ('Create a squad of assistants') and the resource ('assistants that can hand off to each other on a call'), making the purpose understandable. It distinguishes from siblings like vapi_create_assistant by specifying it's for multiple assistants working together, though it doesn't explicitly contrast with vapi_update_squad or vapi_get_squad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('Great for receptionist → qualifier → closer flows'), suggesting when this tool is appropriate. However, it doesn't explicitly state when to use this versus alternatives like vapi_create_assistant for single assistants or vapi_update_squad for modifications, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what data is retrieved (transcript, recording URL, etc.), which adds some context beyond the basic 'get' action. However, it lacks critical details such as authentication requirements, rate limits, error handling, or whether the operation is idempotent/safe. For a read operation with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get full details of a call') and follows with specific data fields. Every word contributes to understanding the tool's output, with no wasted text or redundancy. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is moderately complete. It explains what data is returned, which compensates for the lack of output schema. However, it misses behavioral details like error cases or security requirements. For a basic read tool, it's adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'callId' documented as 'The ID of the call to retrieve'. The description does not add any additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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's purpose with a specific verb ('Get') and resource ('full details of a call'), and lists key data fields (transcript, recording URL, etc.). It distinguishes from sibling tools like 'vapi_list_calls' by focusing on retrieving details for a single call rather than listing multiple calls. However, it doesn't explicitly differentiate from other 'get' tools like 'vapi_get_assistant' beyond the resource type.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid call ID), exclusions (e.g., not for creating or listing calls), or comparisons to siblings like 'vapi_list_calls' for bulk retrieval. Usage is implied by the action 'Get', but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details, implying a read-only operation, but does not specify if it requires authentication, has rate limits, or what happens if the squad ID is invalid. For a tool with zero annotation coverage, this is insufficient to inform safe and effective usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and includes relevant details ('member assistants'), making it easy to understand quickly. There is no wasted information, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., error handling) and return values. The description covers the basic purpose but does not fully compensate for the missing structured data, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'squadId' parameter clearly documented. The description does not add any additional semantic details beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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's purpose: 'Get details of a specific squad including its member assistants.' It specifies the verb ('Get details') and resource ('squad'), and includes the scope of details ('member assistants'). However, it does not explicitly differentiate from sibling tools like 'vapi_get_assistant' or 'vapi_list_squads', which slightly reduces clarity.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a squad ID, or compare it to sibling tools like 'vapi_list_squads' for listing all squads or 'vapi_get_assistant' for individual assistant details. This lack of contextual usage information leaves gaps for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('IDs, names, and config'), which adds some value, but fails to address critical aspects like pagination behavior (implied by the 'limit' parameter), authentication requirements, rate limits, or error handling 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just one sentence that directly states the tool's purpose and return format. Every word earns its place with zero waste, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with filtering parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and return format but lacks details on behavioral traits, error cases, and relationships with sibling tools, leaving gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the input schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema, so it meets the baseline score for high schema coverage without compensating value.
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 action ('List all voice assistants') and resource ('in your Vapi account'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'vapi_list_calls' or 'vapi_list_squads' beyond mentioning the resource type, which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it over 'vapi_get_assistant' for retrieving a single assistant or how it relates to other list tools like 'vapi_list_calls', leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication needs, or what happens if no squads exist. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The second sentence adds useful context about squads without redundancy. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It explains what squads are but lacks details on return format, error handling, or integration with sibling tools. For a list tool with no output schema, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the schema provides. With 100% schema description coverage (the 'limit' parameter is fully documented in the schema), the baseline is 3. The description doesn't compensate with additional context like default values or usage examples.
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 ('List') and resource ('all squads in your account'), and explains what squads are ('groups of assistants that hand off to each other'). However, it doesn't explicitly differentiate from sibling tools like 'vapi_list_assistants' or 'vapi_list_calls', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'vapi_list_squads' over 'vapi_get_squad' for individual squad retrieval, or how it relates to other list tools like 'vapi_list_assistants'. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or response format. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and includes key details without waste. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate for basic understanding but incomplete. It lacks details on behavioral aspects and output, which are crucial for effective use without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'assistantId' well-documented in the schema. The description adds minimal value beyond the schema by implying the parameter is used to retrieve details, but doesn't provide additional context like ID format or examples.
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 resource ('full details of a specific Vapi assistant by ID'), specifying what information is retrieved ('model, voice, and prompt config'). It distinguishes from siblings like vapi_list_assistants by focusing on a single assistant, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'by ID,' suggesting it's for retrieving details of a known assistant. However, it doesn't explicitly state when to use this versus alternatives like vapi_list_assistants or vapi_get_call, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the output includes IDs for use in calls, which adds some context, but fails to describe key behaviors like pagination, error handling, authentication needs, or rate limits. For a list operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core purpose and following with a practical usage tip. Every sentence earns its place by adding value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is adequate but incomplete. It lacks output details (no output schema provided) and behavioral context, which are important for a list operation. It meets minimum viability but has clear gaps in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'limit' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 ('List') and resource ('all phone numbers in your Vapi account'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'vapi_get_phone_number' (singular vs. plural), though the distinction is implied by the naming convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Use the IDs when creating calls'), which helps guide the agent. It doesn't specify when not to use it or name alternatives, but the guidance is practical and relevant to the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool is 'force-end' and for 'stuck' calls, it doesn't specify whether this is a destructive operation, what permissions are required, whether it's reversible, or what happens to call data. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve a distinct purpose: the first states the core functionality, the second provides usage context. There's no wasted language or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation tool with no annotations and no output schema, the description provides basic purpose and usage context but lacks important behavioral details about side effects, error conditions, or what constitutes success. Given the complexity of force-ending calls, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with the single parameter 'callId' well-documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema, so it meets the baseline expectation when the schema does the heavy lifting.
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 specific action ('Force-end') and resource ('an active Vapi call'), distinguishing it from siblings like vapi_get_call or vapi_list_calls. It uses precise language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('if a call gets stuck or needs to be terminated from a workflow'), which helps differentiate it from normal call completion scenarios. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the destructive nature ('Permanently delete') and irreversible consequence ('This cannot be undone'), which are critical for a deletion tool. However, it lacks details on permissions, error handling, or response format, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and consequence in two concise sentences, with zero wasted words. Every sentence earns its place by emphasizing permanence and irreversibility, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive deletion with no output schema and no annotations), the description is mostly complete: it clearly states the action and warns of irreversibility. However, it could improve by mentioning potential side effects (e.g., impact on associated calls) or authentication needs, slightly reducing completeness for a high-stakes operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'assistantId' fully documented in the schema. The description does not add any meaning beyond what the schema provides (e.g., no extra context on ID format or sourcing). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 specific action ('Permanently delete') and resource ('a Vapi assistant'), distinguishing it from sibling tools like vapi_get_assistant or vapi_update_assistant. It directly addresses what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when deletion is needed by stating 'This cannot be undone,' which suggests caution, but it does not explicitly guide when to use this tool versus alternatives (e.g., vs. vapi_update_assistant for modifications) or mention prerequisites. The implication is present but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-vapi MCP server](https://glama.ai/mcp/servers/adhirajhangal/mcp-vapi/badges/card.svg)](https://glama.ai/mcp/servers/adhirajhangal/mcp-vapi)

Score Badge

Copy to your README.md:

[![mcp-vapi MCP server](https://glama.ai/mcp/servers/adhirajhangal/mcp-vapi/badges/score.svg)](https://glama.ai/mcp/servers/adhirajhangal/mcp-vapi)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/adhirajhangal/mcp-vapi'

If you have feedback or need assistance with the MCP directory API, please join our Discord server