Vercel MCP Server
Query deployments, read logs, manage projects and domains on the Vercel platform from an AI agent
The Vercel MCP server is Vercel's official Model Context Protocol integration, letting AI agents list and inspect deployments, read build and function logs, manage projects and domains, and query environment variable metadata. Released in 2025, it connects through the Vercel REST API using a personal access token and covers most of the operational surface you would normally handle through the Vercel dashboard.
When something breaks on a Vercel deployment, the diagnostic loop is usually: open the dashboard, find the deployment, check the build logs, dig through function logs, cross-reference with your database or upstream service. It is a lot of clicking, and the signal is often buried. The Vercel MCP server makes an AI agent a participant in that loop, with direct access to the information you would otherwise gather manually.
Beyond debugging, it covers enough of the project management surface that routine operational tasks (checking what deployed, managing domains, reviewing environment variable configuration) can happen in conversation rather than in the dashboard.
What the server exposes
The tool surface is organized around what you can see and do in the Vercel dashboard, minus the parts that require code changes:
Deployments. The agent can list all deployments for a project or team, sorted by date and status. Each deployment record includes the deployment URL, the git commit it was built from, the build status, and timestamps. You can dig into a specific deployment to get its file list, environment metadata, and deployment configuration.
Logs. Build logs and serverless function logs are both accessible. Build log access is particularly useful for diagnosing failed builds: you can describe the failure symptom and the agent can pull the relevant log lines instead of you scrolling through them manually. Function logs let the agent investigate runtime errors in serverless functions without you collecting and pasting log output into the conversation.
Projects and domains. The server can list all projects in a team, read project-level settings, and manage domains and aliases. Domain management includes checking DNS configuration status, updating aliases, and listing which deployments are aliased to which domains.
Environment variables. The agent can list all environment variables for a project, see which environments (production, preview, development) each variable applies to, and check for variables that exist in some environments but not others. Secret values are redacted, which is correct behavior. The metadata is often enough to answer "why is this variable missing in preview?" type questions.
Team management. For team accounts, the server can list team members and their roles, which is useful for access audits and for understanding who has made recent changes.
Redeployments. If you need to rerun a deployment (force redeploy without a code change, re-run after an environment variable update), the server can trigger that. Cancelling an in-progress build is also available.
Setup
You need a Vercel personal access token. Go to vercel.com/account/tokens, create a new token, give it a descriptive name, and copy it before closing the creation screen.
Add to Claude Desktop at ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"vercel": {
"command": "npx",
"args": ["-y", "@vercel/mcp-adapter"],
"env": {
"VERCEL_API_TOKEN": "your-token-here"
}
}
}
}If you work within a specific Vercel team, add the team ID to prevent the agent from accidentally operating on personal projects when you intend to work on team resources:
{
"mcpServers": {
"vercel": {
"command": "npx",
"args": ["-y", "@vercel/mcp-adapter"],
"env": {
"VERCEL_API_TOKEN": "your-token-here",
"VERCEL_TEAM_ID": "team_xxxxxxxxxxxx"
}
}
}
}Your team ID is visible in your team's Vercel dashboard URL or in the team settings page under "General".
For Claude Code, the config lives at ~/.claude/mcp.json with the same structure.
Keep your token out of any file tracked by git. Use environment variable references or keep the MCP config outside your project directory.
Real use cases
Deployment debugging. This is where the server earns its keep. "The last production deployment failed, why?" is a question the agent can actually answer: it pulls the build log, identifies the error, and either explains it or proposes a fix in the same turn. Without MCP, you would open the dashboard, find the failed deployment, scroll through logs, copy the relevant section, and paste it into the conversation. The MCP path skips every step after "why?".
Environment variable audits. Before a deployment goes wrong because of a missing variable, the agent can audit your environment configuration: list all variables, check which environments they apply to, and flag anything that exists in development but not in production. This takes 30 seconds with MCP access and is tedious to do manually.
Deployment history review. "What has deployed to production in the last week?" "Which deployments came from the main branch?" "When was the last successful build?" These are questions with straightforward answers if the agent can query the deployment list. Useful for incident reviews, release notes, or catching unauthorized deployments.
Domain configuration checks. "Is the staging alias pointing to the right deployment?" "Which domains are configured on this project?" "Why is the custom domain showing an error?" The server's domain and alias tools let the agent answer these without dashboard navigation.
Pre-deploy verification. Before triggering a redeployment, the agent can check the current environment variable configuration, confirm the most recent successful deployment, and flag any issues likely to cause a build failure. This is a lightweight gate that catches configuration drift before it becomes a failed build.
Post-incident review. After a production incident, the agent can correlate the incident timeline with deployment history, check what changed in environment variables around that time, and pull the function logs from the affected period. It is not a replacement for a proper APM tool, but it is a fast first pass.
What the server does not cover
It is worth being clear about the boundaries. The Vercel MCP server is an operations and observability tool, not a deployment pipeline.
It does not push code. Actual deployment still happens through git (Vercel's git integration triggers builds automatically) or the Vercel CLI (vercel deploy). The MCP server cannot initiate a build from source code in your conversation.
It does not give you deep observability into serverless function performance. For latency metrics, cold start analysis, or traffic patterns, you need Vercel Analytics or an external APM tool. The function logs available through MCP are the raw log output, not aggregated metrics.
It cannot modify Vercel integrations (the marketplace integrations like Datadog, Sentry, or Vercel's own Speed Insights). Those are managed entirely through the dashboard.
These are reasonable scope decisions. The server covers the operational and configuration surface well. For anything deeper, the Vercel CLI or dashboard is the right tool.
Security considerations
The access token pattern is straightforward, but a few things are worth thinking through:
Token scope. Vercel personal access tokens grant broad access to your account. There is no built-in way to restrict a token to read-only or to specific projects through the token creation UI. This means the agent could trigger redeployments or modify environment variable metadata on any project the token can reach. If you want to limit this, use the VERCEL_TEAM_ID variable to constrain to a specific team, and think carefully before giving the server access to a team that contains production projects.
Separate tokens for different purposes. If you use Vercel tokens in CI/CD pipelines, create separate tokens for MCP use. Token revocation is cleaner when each token has a single purpose.
The environment variable metadata risk. Even though secret values are redacted, the variable names themselves can be sensitive (they reveal your stack, your integrations, your third-party services). Be aware that the agent can see the full list of variable names, even if not the values.
Pairing with other servers
Vercel MCP pairs well with code-focused integrations. Combined with GitHub MCP, the agent can trace from a failing deployment back to the specific commit, review the code change, and suggest a fix without you switching context. This is one of the more natural pairings in the ecosystem.
Combined with Sentry MCP, the agent can correlate a Sentry error event with a Vercel deployment to determine whether the error appeared before or after a specific deployment. Debugging gets significantly faster when both the error context and the deployment history are available in the same session.
For full-stack workflows where the backend is on Supabase MCP, pairing the two servers lets the agent investigate both the frontend deployment layer and the database layer without context switching.
Bottom line
The Vercel MCP server is most valuable as a debugging and observability tool. The deployment log access alone, which lets an agent pull and interpret build failures without you acting as the log retrieval layer, is worth the five-minute setup.
The operational tools (domains, environment variables, deployment history) are also genuinely useful, particularly for teams that manage multiple projects and find the Vercel dashboard navigation slow for routine checks.
The limits are real: this is not a deployment system, it is a window into your existing deployments. Work within that scope and it is a reliable, well-maintained integration. If you are already using Claude Code for development, adding the Vercel server means you can close the loop from "write the code" to "check whether it deployed correctly" without leaving the agent.
Features
- List and inspect deployments with status, URL, and metadata
- Read build logs and serverless function logs
- Manage projects, domains, and aliases
- Query and manage environment variables (values are redacted for secrets)
- List team members and team-level settings
- Trigger redeployments and cancel in-progress builds
- Retrieve deployment file lists and source information
- Authenticates via Vercel personal access token
How to set up the Vercel MCP Server MCP server
- Create a personal access token at vercel.com/account/tokens
- Add the server block to your Claude Desktop or Claude Code MCP config
- Set VERCEL_API_TOKEN in the env block with your token
- Optionally set VERCEL_TEAM_ID to scope operations to a specific team
- Restart your MCP client and confirm Vercel tools appear in the tool list