Provides tools for managing Vercel projects, deployments, environment variables, domains, runtime logs, build logs, webhooks, teams, analytics, access control, audit logs, tokens, and deployment advanced features like promotion, rollback, and aliases.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vercel-mcp-server list my Vercel projects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个用于集成Vercel API的MCP (Model Context Protocol) 服务器，提供项目管理、部署管理、环境变量管理和域名管理等功能。
项目管理: 获取项目列表和详细信息
部署管理: 获取部署列表、详情、取消部署、获取日志
环境变量管理: 获取、创建、更新、删除环境变量
域名管理: 获取域名列表、添加、删除域名
运行时日志: 获取和流式传输应用运行时日志
构建日志: 获取和流式传输构建过程日志
Webhook管理: 创建、更新、删除、查询Webhook配置
团队管理: 管理团队成员、权限和团队信息
分析监控: 获取性能指标、使用统计和分析数据
访问控制: 管理访问组和权限控制
审计日志: 获取和流式传输审计日志
Token管理: 创建、删除、查询API Token
部署高级功能: 部署推广、回滚、别名管理
完整的错误处理和日志记录
TypeScript支持
流式数据传输
统一的API响应格式
Related MCP server: Vercel MCP
git clone <repository-url>
cd vercel-mcp-server
npm installnpm run build进入 Settings > Tokens
创建新的API Token
复制生成的token
在Trae的MCP配置中添加以下JSON配置：
{
"mcpServers": {
"vercel": {
"command": "npx",
"args": [
"--yes",
"--package=file:E:\\GIT_CODE\\mcp\\vercel-mcp-server",
"vercel-mcp-server"
],
"env": {
"VERCEL_TOKEN": "your_vercel_api_token_here",
"LOG_LEVEL": "info"
}
}
}
}{
"mcpServers": {
"vercel": {
"command": "node",
"args": [
"E:\\GIT_CODE\\mcp\\vercel-mcp-server\\dist\\index.js"
],
"env": {
"VERCEL_TOKEN": "your_vercel_api_token_here",
"LOG_LEVEL": "info"
}
}
}
}重要提示：
将 E:\\GIT_CODE\\mcp\\vercel-mcp-server 替换为你的实际项目路径
将 your_vercel_api_token_here 替换为你的实际Vercel API Token
确保项目已经构建（运行过 npm run build）
VERCEL_TOKEN: Vercel API访问令牌（必需）
VERCEL_TEAM_ID: Vercel团队ID（可选，用于团队项目）
LOG_LEVEL: 日志级别（可选，默认为info）
API_TIMEOUT: API请求超时时间，单位毫秒（可选，默认为30000）
vercel_list_projects: 获取项目列表
vercel_get_project: 获取项目详细信息
vercel_list_deployments: 获取部署列表
vercel_get_deployment: 获取部署详细信息
vercel_cancel_deployment: 取消部署
vercel_get_deployment_logs: 获取部署日志
vercel_list_env_vars: 获取环境变量列表
vercel_create_env_var: 创建环境变量
vercel_update_env_var: 更新环境变量
vercel_delete_env_var: 删除环境变量
vercel_list_domains: 获取域名列表
vercel_add_domain: 添加域名
vercel_delete_domain: 删除域名
vercel_get_runtime_logs: 获取运行时日志
vercel_stream_runtime_logs: 流式传输运行时日志
vercel_get_build_logs: 获取构建日志
vercel_stream_build_logs: 流式传输构建日志
vercel_list_webhooks: 获取Webhook列表
vercel_create_webhook: 创建Webhook
vercel_update_webhook: 更新Webhook
vercel_delete_webhook: 删除Webhook
vercel_get_webhook: 获取Webhook详情
vercel_list_teams: 获取团队列表
vercel_get_team: 获取团队详情
vercel_list_team_members: 获取团队成员列表
vercel_add_team_member: 添加团队成员
vercel_remove_team_member: 移除团队成员
vercel_update_team_member: 更新团队成员
vercel_get_analytics: 获取分析数据
vercel_get_performance_metrics: 获取性能指标
vercel_get_usage_stats: 获取使用统计
vercel_list_access_groups: 获取访问组列表
vercel_create_access_group: 创建访问组
vercel_update_access_group: 更新访问组
vercel_delete_access_group: 删除访问组
vercel_get_audit_logs: 获取审计日志
vercel_stream_audit_logs: 流式传输审计日志
vercel_list_tokens: 获取Token列表
vercel_create_token: 创建Token
vercel_delete_token: 删除Token
vercel_get_token_info: 获取Token信息
vercel_promote_deployment: 推广部署
vercel_rollback_deployment: 回滚部署
vercel_create_alias: 创建别名
vercel_delete_alias: 删除别名
MCP error -32000: Connection closed
这是正常现象！MCP服务器通过stdio与客户端通信
直接运行 node dist/index.js 会立即退出，因为没有MCP客户端连接
只有在Trae等MCP客户端中配置后才能正常工作
如果在Trae中仍然出现此错误，请检查：
VERCEL_TOKEN环境变量是否正确设置
项目是否已正确构建 (npm run build)
配置路径是否正确
'vercel-mcp-server' 不是内部或外部命令
确保项目已构建：npm run build
检查package.json中是否有bin字段
尝试使用方法二（node命令）
ENOENT错误
检查配置中的路径是否正确
确保使用绝对路径
确保dist/index.js文件存在
API认证错误
检查VERCEL_TOKEN是否正确
确保token有足够的权限
检查token是否已过期
# 开发模式
npm run dev
# 运行测试
npm test
# 代码检查
npm run lint
# 代码格式化
npm run formatMIT License
Add a new domain
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain name to add | |
| projectId | No | The ID of the project to associate with this domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. 'Add a new domain' discloses only the action, not side effects (e.g., does it overwrite an existing domain?), authorization needs, or idempotency. This is insufficient for a mutation tool.
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 extremely short, which risks being under-specified. While it is concise, it lacks necessary context for effective tool use. A single sentence is not enough to earn a higher score.
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 output schema, no annotations, and two parameters (one required), the description is incomplete. It does not explain the return value, success/failure indications, or any additional behavior, leaving the agent with insufficient context.
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 input schema covers both parameters with clear descriptions, achieving 100% coverage. The description adds no further semantic value beyond the schema, so a baseline score of 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 'Add a new domain' clearly uses a verb ('Add') and a resource ('domain'), distinguishing it from sibling tools like 'list' and 'delete'. However, it omits context about associating the domain with a project, which the 'projectId' parameter implies could be important.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., when to use list or delete), nor does it mention prerequisites or constraints such as domain ownership verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a deployment that is currently building
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentId | Yes | The ID of the deployment to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only mentions the 'currently building' state, but doesn't specify error handling (e.g., if deployment is already completed or non-existent), side effects, or permissions needed.
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?
A single, concise sentence that conveys the essential information without any redundant or superfluous content.
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 simplicity (1 param, no output schema), the description is borderline adequate but lacks details about return value (e.g., success indicator or updated deployment) and error conditions. It meets the minimum but has gaps.
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 single parameter 'deploymentId' is fully described in the schema (100% coverage). The description adds no additional meaning beyond what the schema provides, thus baseline 3.
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 action (cancel), the resource (deployment), and the condition (currently building). It distinguishes this tool from sibling tools like get_deployment or list_deployments.
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 explicit guidance on when to use versus alternatives, nor mention of preconditions like deployment state. The condition 'currently building' is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new environment variable for a project
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The name of the environment variable | |
| type | No | The type of the environment variable (default: encrypted) | |
| value | Yes | The value of the environment variable | |
| target | Yes | The environments where this variable should be available | |
| projectId | Yes | The ID of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like idempotency, overwrite behavior, or rate limits. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient and to the point, but could benefit from additional context without being verbose.
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?
No output schema and no description of return value, success criteria, or error handling. For a creation tool with 5 parameters, this is incomplete.
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 baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, such as default value for 'type' or constraints on 'target'.
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 'Create a new environment variable for a project' clearly states the action (create) and resource (environment variable), distinguishing it from sibling tools like vercel_list_env_vars or vercel_update_env_var.
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 this tool versus alternatives such as vercel_update_env_var for existing variables. Missing context about prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a domain
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain name to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'Delete a domain'. It fails to disclose key behavioral traits such as whether the operation is irreversible, whether it requires authentication, or what happens to projects using that domain. This leaves the agent with significant uncertainty.
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 extremely concise—only three words—and front-loads the core action. However, it is almost too minimal, lacking essential context that could be added without sacrificing conciseness.
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 nature of the tool (one parameter, no output schema), the description is insufficient. It omits important context about the operation's effects, such as whether the deletion is permanent and what happens to associated resources like deployments or environment variables.
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 input schema has 100% coverage with a clear description for the 'name' parameter. The tool description adds no additional semantic value beyond what the schema already provides, so a baseline score of 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 'Delete' and the resource 'a domain', making the tool's purpose unambiguous. It effectively distinguishes itself from sibling tools like vercel_list_domains and vercel_add_domain, which perform different actions on domains.
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 alternatives, nor are there any prerequisites or conditions for use. For example, it does not mention that the domain must exist or that it should be detached from projects before deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an environment variable
| Name | Required | Description | Default |
|---|---|---|---|
| envVarId | Yes | The ID of the environment variable to delete | |
| projectId | Yes | The ID of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description solely states the action without disclosing effects like irreversibility, safety checks, or required permissions. Minimal behavioral insight.
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?
Single sentence, front-loaded with verb and resource, no wasted words. Efficient for a simple operation.
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?
Tool is simple with 2 required params and no output schema, but description lacks behavioral context (e.g., effects, prerequisites) which would help with completeness given no annotations.
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%; the tool description adds no additional meaning beyond the schema definitions for 'envVarId' and 'projectId'.
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?
Description uses specific verb 'delete' with exact resource 'environment variable', clearly distinguishing it from sibling tools like create, update, and list.
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 this tool vs alternatives, no exclusions, prerequisites, or context provided. The agent must infer usage solely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific deployment
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentId | Yes | The ID of the deployment to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only says 'Get details' without specifying what details are included (e.g., status, environment, creation time), nor any side effects or permissions needed.
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 sentence of 6 words—extremely concise with no waste. Every word is relevant to the tool's purpose.
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 only one parameter, no output schema, and no annotations, the description is *adequate* but lacks details about return value structure or additional context (e.g., whether it returns full deployment data vs. summary).
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%, and the schema already documents 'deploymentId' meaningfully. The description adds no additional context beyond the schema, meeting the baseline of 3.
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 'Get' and the resource 'details of a specific deployment', which directly distinguishes it from sibling tools like vercel_list_deployments (list all) and vercel_get_project (different resource).
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 use when you need details of one deployment, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it compare with siblings like vercel_get_deployment_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs for a specific deployment
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of log entries to return | |
| since | No | Get logs after this timestamp | |
| until | No | Get logs before this timestamp | |
| follow | No | Whether to follow the logs in real-time | |
| deploymentId | Yes | The ID of the deployment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'Get logs', implying a read operation, but does not mention pagination, real-time following (though a 'follow' parameter exists), rate limits, or the format of log entries. This is insufficient for a tool with 5 parameters.
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 short sentence with no filler. However, it is so concise that it omits potentially useful context. It earns a 4 for efficiency but loses a point for under-specification.
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?
With no output schema, no annotations, and 5 parameters, the description is quite sparse. It does not explain the nature of logs, how to interpret them, or any constraints like maximum limit. This is inadequate for an agent to reliably use the tool.
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?
All 5 parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain the order or format of logs returned.
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 'Get logs for a specific deployment' clearly states the verb 'Get' and the resource 'logs for a specific deployment', which is distinct from sibling tools like 'get_deployment' (which returns deployment metadata) and 'list_deployments' (which lists deployments).
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 alternatives, or any prerequisites or when not to use it. The description is a single sentence without any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Vercel project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The ID of the project to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It communicates a read operation ('Get details') with no side effects implied, which is adequate. However, it fails to mention permissions, rate limits, or what exactly is returned, leaving some transparency gaps.
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 sentence with zero waste. It is front-loaded with the key action and resource, making it easy to parse. Every word earns its place.
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 tool has no output schema, so the description should hint at return values. 'Details' is vague and does not specify what fields are included. For a simple get, this might be acceptable, but completeness is lacking compared to richer descriptions.
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% (only one parameter, projectId, already described in schema). The description adds no extra meaning beyond the schema. Baseline 3 is appropriate since the schema already handles the documentation.
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 uses a clear verb ('Get') and resource ('details of a specific Vercel project'), distinguishing it from sibling tools like vercel_list_projects which lists multiple projects. It is specific enough for a single-purpose tool, though could be more descriptive about what 'details' entails.
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 provides no guidance on when to use this tool vs alternatives such as vercel_list_projects or vercel_get_deployment. It does not mention prerequisites, context, or exclusion criteria, 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.
List deployments for a project or all projects
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of deployments to return (default: 20) | |
| since | No | Get deployments created after this timestamp | |
| state | No | Filter by deployment state (BUILDING, ERROR, INITIALIZING, QUEUED, READY, CANCELED) | |
| until | No | Get deployments created before this timestamp | |
| projectId | No | Filter deployments by project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It only states the basic operation but omits behavioral traits like whether the operation is read-only, default pagination, rate limits, or that it filters by state and timestamps. The description is insufficient for an agent to understand side effects or constraints.
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 concise sentence with no extraneous words. It front-loads the key action and resource. While it could be slightly more informative without adding length, it remains appropriately sized for a simple list operation.
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 5 parameters, no output schema, and no annotations, the description is too minimal. It does not explain return format, ordering, default limit, or behavior when no projectId is provided. For a tool with moderate complexity, the description is incomplete.
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?
All 5 parameters have descriptions in the input schema, achieving 100% coverage. The tool description adds minimal value beyond the schema (e.g., hinting that projectId is optional). According to the rubric, with high schema coverage the baseline is 3, and no significant additional meaning is provided.
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 action 'List' and the resource 'deployments', with added context of 'for a project or all projects'. It effectively distinguishes from sibling tools like vercel_get_deployment (single deployment) and vercel_list_projects (lists projects). However, it could be more precise by specifying that it returns a list of deployments with optional filters.
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 provides no guidance on when to use this tool versus alternatives such as vercel_get_deployment for a single deployment or vercel_list_projects for project listings. The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all domains
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of domains to return (default: 20) | |
| since | No | Get domains created after this timestamp | |
| until | No | Get domains created before this timestamp | |
| projectId | Yes | The ID of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention pagination, ordering, rate limits, or the fact that results are scoped to a project. Only the schema implies pagination via limit/since/until.
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 extremely short (3 words) but lacks necessary details. It is under-specified rather than concise, providing minimal value to the agent.
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?
No output schema exists, so the description should clarify what is returned. It does not mention return format, structure, or pagination behavior. The tool's purpose is overly simplified.
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 the input schema already explains all parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline.
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?
Description says 'List all domains' but the schema requires a projectId, meaning it lists domains for a specific project, not all domains globally. This creates ambiguity and is slightly misleading.
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 this tool versus alternatives like vercel_add_domain or vercel_delete_domain. The description does not mention any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List environment variables for a project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The ID of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as read-only nature, pagination, or whether sensitive values are masked. The agent has no information beyond the action being a listing.
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?
Single concise sentence with no unnecessary words, front-loading the action and resource.
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?
For a simple list tool with 1 param and no output schema, the description is minimal but lacks usage guidelines and behavioral context, making it less complete than it could be.
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 adds no additional meaning beyond the schema's 'The ID of the project'.
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 'List' and resource 'environment variables for a project', making it specific and distinguishable from sibling tools like vercel_list_projects or vercel_create_env_var.
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 this tool versus alternatives (e.g., get_env_var for a single variable). The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Vercel projects
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of projects to return (default: 20) | |
| since | No | Get projects created after this timestamp | |
| until | No | Get projects created before this timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'List all Vercel projects'. It omits behavioral details such as pagination, whether it returns all or just the first page, or read-only nature.
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, clear sentence with no unnecessary words, front-loading the core purpose efficiently.
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 tool's simplicity, the description is too minimal. It fails to mention the output format or any additional behavior beyond filtering, leaving the agent underinformed.
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 adds no extra meaning beyond the schema, but the schema itself documents limit, since, and until adequately.
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 'List all Vercel projects' clearly states a specific verb and resource, and distinguishes it from sibling tools like 'vercel_get_project' which handles single project retrieval.
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 alternatives (e.g., vercel_get_project). There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing environment variable
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | The new name of the environment variable | |
| type | No | The type of the environment variable | |
| value | No | The new value of the environment variable | |
| target | No | The environments where this variable should be available | |
| envVarId | Yes | The ID of the environment variable to update | |
| projectId | Yes | The ID of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Update an existing environment variable' without disclosing side effects, permissions, idempotency, rate limits, or error conditions. This is insufficient for safe invocation.
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?
Extremely concise single sentence that front-loads the verb. However, it may be too sparse, missing context that could be added without significant length.
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?
No output schema and no description of return value. For an update operation, the agent would benefit from knowing whether the updated variable is returned or just a confirmation. The description lacks completeness for a mutation tool.
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% with descriptions for all parameters. The tool description does not add any additional parameter context or constraints, meeting the baseline for high schema coverage.
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 uses the verb 'Update' and specifies the resource 'existing environment variable', clearly distinguishing it from create and delete sibling tools. However, it does not enumerate the updatable fields, relying on the schema.
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 usage context or when-to-use guidelines are provided. The description does not contrast with create/delete env var tools or specify prerequisites like having projectId and envVarId. The agent must infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action: projects, deployments (with logs and cancel), environment variables (full CRUD), and domains (list, add, delete). No overlapping purposes.
All tools follow the consistent pattern 'vercel_verb_noun' (e.g., vercel_list_projects, vercel_get_deployment). Verbs are uniform (list, get, create, update, delete, cancel, add) and snake_case is used throughout.
13 tools is a reasonable size for a Vercel management server, covering the main areas of projects, deployments, environment variables, and domains without being excessive or sparse.
The tool set covers core CRUD for environment variables and domains, plus deployments and project details. However, missing create/delete for projects and create deployment are notable gaps, though some may be by design (deployments triggered via git).
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/XiaYeAI/vercel-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
