Vercel MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different aspects of deployments. The actions (cancel, delete, get, list) are well-differentiated and operate on specific resources like deployments, events, files, or file contents with no overlap in functionality.
Naming Consistency4/5
The naming follows a consistent verbNoun pattern with camelCase throughout, such as 'getDeployment' and 'listDeploymentFiles'. The only minor deviation is 'getDeploymentEvents' which uses plural 'Events' while others use singular or plural appropriately, but overall the pattern is highly predictable and readable.
Tool Count5/5
With 7 tools, the count is well-scoped for managing deployments in a Vercel context. Each tool earns its place by covering essential operations like listing, retrieving, canceling, deleting, and accessing deployment details and files, without being excessive or insufficient for the domain.
Completeness4/5
The toolset provides strong coverage for deployment lifecycle management, including create (implied by deployment actions), read (get/list), update (cancel as a state change), and delete operations. A minor gap is the lack of explicit tools for creating or updating deployments, but core workflows are well-supported with no dead ends.
Average 2.5/5 across 7 of 7 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/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 only states the action ('Gets') without any details on permissions, rate limits, error handling, or what the output looks like (e.g., file format, size limits). For a read operation with multiple parameters, this is inadequate and leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase 'Gets deployment file contents', which is overly concise to the point of under-specification. It lacks structure and fails to front-load useful information, such as purpose or context, making it inefficient despite its brevity. Every sentence should earn its place, but this one doesn't provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'deployment file contents' entails (e.g., raw data, metadata), how to handle the optional parameters ('slug' and 'teamId'), or any behavioral aspects. This leaves significant gaps for the agent to infer usage and outcomes.
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 clear descriptions for all parameters (e.g., 'deploymentId' as 'The ID of the deployment', 'fileId' as 'The ID of the file'). The description adds no additional meaning beyond this, such as explaining relationships between parameters (e.g., 'slug' and 'teamId' might be optional for scoping). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets deployment file contents' is a tautology that essentially restates the tool name 'getDeploymentFileContents' without adding meaningful specificity. It doesn't distinguish this tool from sibling tools like 'getDeployment' or 'listDeploymentFiles' beyond the obvious implication of file contents versus deployment metadata or file listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 any context, prerequisites, or exclusions, such as how it differs from 'getDeployment' (which might return metadata) or 'listDeploymentFiles' (which might list files without contents). This leaves the agent with no usage direction.
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 but only states the action without details on permissions, pagination, rate limits, or output format. It fails to address whether this is a read-only operation or has other behavioral traits, leaving significant 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 extremely concise with a single sentence, 'Lists deployment files', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, but for this dimension alone, it scores high due to efficient structure.
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, no output schema, and a tool with three parameters (one required), the description is incomplete. It doesn't explain what the tool returns, how to interpret results, or behavioral aspects, making it inadequate for effective agent use despite the schema covering parameters.
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. The description adds no meaning beyond the schema, such as explaining parameter relationships or usage context. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists deployment files' is a tautology that merely restates the tool name 'listDeploymentFiles' without adding specificity. It doesn't clarify what type of files are listed, their format, or the scope of the listing, making it minimally informative beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like 'getDeploymentFileContents' or 'getDeployment'. The description lacks context about prerequisites, such as needing a deployment ID, or distinctions from sibling tools, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. It doesn't mention whether deletion is permanent or reversible, what permissions are required, whether it affects associated resources, or what happens to the deployment's data. For a destructive operation with zero annotation coverage, this is dangerously inadequate.
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 maximally concise - a single three-word phrase that communicates the core function. There's zero waste or redundancy. While it's under-specified for a destructive operation, this dimension scores purely on efficiency of expression.
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 destructive tool with no annotations and no output schema, the description is severely incomplete. It doesn't address critical context like permanence, side effects, error conditions, or return values. The agent cannot safely use this tool based on the provided information alone.
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 all parameters are documented in the schema. The description adds no parameter information beyond what's already in the structured data. The baseline score of 3 reflects adequate schema coverage where the description doesn't need to compensate, but also doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a deployment' clearly states the action (delete) and resource (deployment), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'cancelDeployment' - both involve stopping deployments but likely through different mechanisms. The description is vague about what type of deployment is being deleted (e.g., cloud, container, application).
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 'cancelDeployment'. There's no mention of prerequisites, consequences, or appropriate contexts for deletion versus cancellation. The agent must infer usage from the tool name alone, which is insufficient for informed 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 but provides minimal information. It states the tool 'gets' events, implying a read operation, but doesn't describe what format the events come in, whether there's pagination, rate limits, authentication requirements, or what happens when parameters are omitted. For a tool with 12 parameters and no annotation coverage, this is a significant gap in behavioral context.
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 extremely concise - a single sentence that gets straight to the point. There's no wasted verbiage or unnecessary elaboration. However, the potential confusion around 'build ID' versus the actual 'builds' parameter slightly reduces the effectiveness of this conciseness.
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 complexity (12 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what 'deployment events' actually are, what format they return in, or how the various filtering parameters interact. The mention of 'build ID' that doesn't correspond to a schema parameter creates confusion. For a tool with this level of complexity and no structured output information, the description should provide more contextual guidance.
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%, so all parameters have descriptions in the schema itself. The tool description mentions 'deployment ID and build ID', but 'build ID' doesn't match the schema's 'builds' parameter (which is described as 'Builds parameter' with no further clarification). This creates confusion rather than adding value. The description doesn't provide additional context about parameter interactions or usage patterns beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'gets deployment events by deployment ID and build ID', which provides a clear verb ('gets') and resource ('deployment events'). However, it mentions 'build ID' which doesn't correspond to any parameter in the schema (the schema has 'builds' as a number parameter, not 'build ID'), creating potential confusion. It doesn't distinguish this tool from its sibling 'getDeployment' or explain what makes 'events' different from general deployment information.
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. There are multiple sibling tools related to deployments (getDeployment, getDeployments, listDeploymentFiles), but the description doesn't explain when an agent should choose this specific events-focused tool over those other options. No context about prerequisites or typical use cases is 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Lists deployments' implies a read-only operation, but it doesn't address critical behaviors like pagination (implied by 'limit' parameter), authentication requirements, rate limits, or what the return format looks like. For a tool with 12 parameters and no output schema, 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 extremely concise at two words ('Lists deployments'), front-loaded with the core action, and wastes no space. Every word earns its place by directly stating the tool's function without redundancy or fluff.
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 complexity (12 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain the return values, filtering behavior, or how parameters interact (e.g., 'from'/'since' and 'to'/'until' duplicates), leaving the agent with insufficient context for 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?
Schema description coverage is 100%, with all 12 parameters documented in the schema (e.g., 'app', 'from', 'limit'). The description adds no additional parameter semantics beyond implying a listing action, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists deployments' clearly states the verb ('Lists') and resource ('deployments'), making the basic purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'getDeployment' (singular) or 'listDeploymentFiles', leaving ambiguity about scope and specificity.
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. With siblings like 'getDeployment' (singular retrieval) and 'listDeploymentFiles' (file listing), the description offers no context about filtering capabilities, scope differences, or appropriate use cases, leaving the agent to infer usage.
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 'cancels' implying a mutation, but doesn't specify if this is reversible, requires specific permissions, affects ongoing processes, or has side effects like notifications. This leaves significant gaps for a tool that likely modifies state.
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 with a single sentence ('Cancels a deployment'), which is front-loaded and wastes no words. It efficiently conveys the core purpose 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 complexity of a cancellation operation (likely a mutation with no output schema and no annotations), the description is incomplete. It doesn't address behavioral aspects like effects, prerequisites, or return values, making it inadequate for safe and informed tool invocation.
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 clear parameter descriptions in the schema (e.g., 'The ID of the deployment to cancel'). The description adds no additional parameter details beyond what the schema provides, so it meets the baseline for high schema coverage without adding 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 ('cancels') and resource ('a deployment'), providing a specific action. However, it doesn't differentiate from the sibling 'deleteDeployment' tool, which suggests a similar destructive operation but with potentially different semantics.
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 like 'deleteDeployment' or other sibling tools. The description lacks context about prerequisites, conditions for cancellation, or any exclusions, leaving the agent without usage direction.
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, the description carries full burden but only states the basic operation. It lacks details on permissions needed, rate limits, error handling, or response format. While 'Gets' implies read-only, it doesn't confirm safety or describe behavioral traits beyond the minimal purpose.
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's front-loaded with the core purpose and appropriately sized for a simple retrieval tool, 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 no annotations and no output schema, the description is incomplete. It doesn't explain what a deployment contains, the return format, or error cases. For a tool with 4 parameters and siblings, more context on usage and behavior is needed to be fully 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?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no extra meaning beyond implying 'deploymentId' can be an ID or URL, which is already in the schema. With high coverage, baseline 3 is appropriate as the schema handles parameter documentation.
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 ('Gets') and resource ('a deployment'), specifying it retrieves by 'ID or URL'. It distinguishes from siblings like 'getDeployments' (plural) by focusing on a single deployment, but doesn't explicitly contrast with 'getDeploymentEvents' or 'getDeploymentFileContents'.
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 is provided. It doesn't mention prerequisites like authentication, differentiate from 'getDeployments' for bulk retrieval, or specify scenarios where this is preferred over sibling tools like 'getDeploymentEvents'.
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:

[![vercel-api-mcp MCP server](https://glama.ai/mcp/servers/zueai/vercel-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zueai/vercel-api-mcp)

Score Badge

Copy to your README.md:

[![vercel-api-mcp MCP server](https://glama.ai/mcp/servers/zueai/vercel-api-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zueai/vercel-api-mcp)

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

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/zueai/vercel-api-mcp'

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