Auto-Deploy from Claude Code / Cursor to Vercel — Three Workflows with MCP, Plugin, and GitHub Actions

"Claude Code made the fix — now I push by hand, open the Vercel dashboard in a browser..." Vercel officially ships three tools to cut that back-and-forth: Vercel MCP (a server that lets AI tools work with your Vercel projects, deployments, and logs), the Vercel Plugin (an extension that adds Vercel knowledge and slash commands to Claude Code, Cursor, and others), and Agent Skills (bundles of instructions installed with npx skills add). The names are similar and the roles seem to overlap, so muddled explanations like "connect Agent Skills over MCP" circulate widely.

The bottom line: it helps to think of AI-agent-to-Vercel deploys as three approaches. ① Git integration (git push → auto-deploy) is enough for most solo work. ② Straight from the editor (Vercel MCP, Vercel Plugin) suits people who want the AI to handle what surrounds a deploy too — reading logs, touching environment variables. ③ GitHub Actions + Claude Code Action is for teams that want @claude to fix things from PR comments and ship only after tests or approvals pass. There is no "best" — it comes down to how much you hand to the AI and where a human stops it.

This article was written after re-reading the original Vercel and Anthropic documentation on September 30, 2026. Config examples, commands, and plan conditions are as of that date (both change fast, so check the linked pages before you rely on them). AI Recommends Vercel, What Is Cursor, and Can AI Handle Infrastructure? make useful companions.

1. "Agent Skills," "MCP," and "Plugin" Are Different Things

Even with AI writing the code, checking the deploy lives on another screen: back to the terminal for git add . && git commit -m "fix" && git push, open the Vercel dashboard in a browser, copy the preview URL, paste it into Slack. Vercel has added AI-facing entry points step by step to cut down on that switching.

Laying them out in order untangles the confusion. On August 4, 2025, Vercel MCP entered public beta (Vercel's announcement) — a remote MCP server with OAuth authentication at https://mcp.vercel.com. In the same month, August 2025, Anthropic's Claude Code GitHub Action reached v1.0 (the v1.0.0 tag is dated 2025-08-25). On March 17, 2026, the Vercel Plugin arrived (announcement), and on July 23, 2026, Vercel MCP gained the ability to deploy code directly (announcement).

And Agent Skills are not MCP. Vercel's Agent Skills page describes them as packaged capabilities you install with npx skills add <owner/repo> to teach an agent a specific way of working, usable in 18+ agents including Claude Code, GitHub Copilot, and Cursor. If MCP is the means of acting on your account, Skills are the know-how. See also What Is MCP and Claude Agent SDK.

2. Vercel's Five Entry Points — What Each Does and How It Authenticates

Here are the entry points an AI agent can use to reach Vercel, as described in the official documentation (as of September 30, 2026). The authentication column — what you hand to the AI — decides how bad an accident can get.

Sources: Vercel MCP, MCP tools reference, Vercel Plugin, Agent Skills, Why aren't commits triggering deployments (Vercel KB).

How to read it: if all you need is "it deploys," Git integration is enough. MCP and the Plugin pay off when you want the conversation to cover what happens around a deploy — having the AI read logs to find why a build failed, showing env var differences, rolling production back one step.

3. The Three Approaches at a Glance

Here are the three approaches along what you hand the AI × depth of automation × where a human stops it.

Rules of thumb: if you often open the dashboard after a deploy just to read logs, go with ②. If PR review is routine and you only want tested changes to ship, go with ③. For a personal blog or small app, ① is enough — over-engineering costs more in maintenance than it saves. The three aren't mutually exclusive; the usual shape is ① as the base, with ② or ③ added on top.

4. Approach 1: Git Integration (Auto-Deploy on git push)

The most basic setup. Connect Vercel and GitHub, and Vercel builds on every git push and publishes when the build finishes. The AI's job is just writing code, writing the commit message, and pushing. Vercel's own GitHub Actions guide says that because the Git integration already handles preview URLs, immutable deploys, and instant rollback, most teams need no pipeline at all.

# Setup (once)
1. Vercel dashboard → Add New → Project
2. Pick your GitHub repository → Import
3. Framework Preset: auto-detected (Next.js, etc.)
4. Environment Variables: add as needed
5. Deploy

# Daily flow (inside Cursor / Claude Code)
> Make this button red. When you're done, push it to a feature/red-button branch.

# Commands the AI runs
git switch -c feature/red-button
git add app/components/Button.tsx
git commit -m "feat: change primary button to red"
git push -u origin feature/red-button

# Vercel builds a preview → the PR gets a preview URL

The real value here is that every branch gets a preview URL automatically. Vercel preview URLs come in two kinds: a branch-specific URL that always points to the latest on that branch, and a commit-specific URL that points to that exact deployment (Environments). If only merges into main go to production, the AI can push as often as it likes and it stops at preview.

Caution: the Hobby plan is restricted to non-commercial, personal use (Hobby plan). You can create 100 deployments a day on Hobby and 6,000 on Pro, and Hobby runs one build at a time (Limits). Let the AI push in tiny increments and you hit these limits first. For pricing traps, see §5 of AI Recommends Vercel.

5. Approach 2: Straight from the Editor (Vercel MCP and Vercel Plugin)

To let the AI handle what surrounds a deploy, use Vercel MCP or the Vercel Plugin. Neither requires writing a token into a file.

Setting up Vercel MCP (Cursor): in the official instructions, you just put one URL in .cursor/mcp.json (project-level or global).

{
  "mcpServers": {
    "vercel": {
      "url": "https://mcp.vercel.com"
    }
  }
}

Once added, Cursor tries to connect and shows a Needs login prompt. Click it to sign in to Vercel in the browser and choose which teams Cursor may use. In Claude Code, it's two lines:

claude mcp add --transport http vercel https://mcp.vercel.com
# then start claude and authenticate with /mcp

The docs also list npx add-mcp https://mcp.vercel.com, which registers the server in several clients at once. Note that adding the server does not complete authorization: until you sign in and grant access to a team, the AI can't see that team's deployments or logs (tools reference).

MCP provides tools, not slash commands. You ask something like "check the errors on my latest deployment," and the AI picks and calls tools such as these (excerpt from the list as of September 30, 2026):

The Vercel Plugin (npx plugins add vercel/vercel-plugin) adds Vercel knowledge plus five slash commands. They are namespaced: /vercel-plugin:deploy (add prod for production), /vercel-plugin:env (list, pull, add, remove, diff), /vercel-plugin:status, /vercel-plugin:bootstrap, and /vercel-plugin:marketplace (Vercel Plugin). Reading the deploy command's definition shows it drives your local Vercel CLI (vercel, vercel --prod), defaults to a preview, and waits for an explicit "yes" before production. There are no /logs or /rollback commands; handle logs and rollback through MCP tools or the CLI (vercel rollback).

The real payoff is that everything stays inside the conversation. Ask "add this API, deploy it to preview, and if there's an error, read the logs and fix it," and the AI works through code change → deploy → check the build log → fix → redeploy. In the terms of Can AI Handle Infrastructure?, this sits in the "capable but dangerous" zone. Vercel states plainly that an MCP connection gives the AI the same access as your Vercel user account, and recommends that you always enable human confirmation. Don't set tool calls to auto-approve.

6. Approach 3: GitHub Actions (@claude Plus Check Gates)

The team setup. With Claude Code GitHub Actions, you mention @claude in an issue or PR comment and Claude commits a fix and replies in the same thread. The preview deploy is handled by the Git integration from Approach 1 — when Claude pushes to the PR branch, Vercel rebuilds the preview.

# Setup
1. Run /install-github-app inside Claude Code (github.com repositories only)
2. Install the Claude GitHub App; store ANTHROPIC_API_KEY (or CLAUDE_CODE_OAUTH_TOKEN) in Secrets
3. .github/workflows/claude.yml arrives as a pull request

# .github/workflows/claude.yml (example from the official docs)
name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 30          # stop runaway jobs (recommended by the docs)
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write            # required for the default GitHub App auth
      actions: read              # read CI results on PRs
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: "--max-turns 10"   # cap the turns per run

timeout-minutes and --max-turns are additions for illustration — the two measures the docs' "Manage costs" section recommends (tune the values to your project). No turn limit applies by default, so set one yourself.

If you also want GitHub Actions to deploy — only when you need tests, security scans, performance budgets, or human approval before a deploy — follow Vercel's official guide. You need three secrets: VERCEL_TOKEN, VERCEL_ORG_ID, and VERCEL_PROJECT_ID (the last two are in the .vercel/project.json that vercel link creates).

# .github/workflows/vercel-preview.yml (shape from the Vercel KB)
name: Vercel Preview Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches-ignore:
      - main
jobs:
  Deploy-Preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install --global vercel@latest
      - run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
      # put tests and scans here
      - run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

# vercel.json — turn off Git-triggered deploys so the two don't both deploy
{ "git": { "deploymentEnabled": false } }

The same guide lists the traps: leave the Git integration on while Actions also deploys, and both fire on the same commit; skip --prebuilt, and Vercel builds the same thing a second time. Conversely, if you only want to run tests, it's lighter to keep the Git integration, run tests against the preview on the deployment_status event, and use Deployment Checks to hold back promotion to production.

# What it looks like in practice
# A developer opens a PR → the Git integration builds a preview
[Bot] Vercel Preview: https://<preview-url>

# A reviewer comments on the PR
@claude make this button change color on hover too

# Claude adds a commit and replies → Vercel rebuilds the preview
# Reviewer checks → approve → merge → production deploy

Caution: for private repositories, the commit author must be a member of the Vercel team (or, on Hobby, the owner) or nothing deploys (Vercel KB). If commits made inside Actions don't produce a preview, check the Vercel Bot comment and the commit author first.

This setup makes the "no human touches code until the PR is done" scenario realistic. As covered in Veteran vs. Junior and Will AI Eliminate White-Collar Jobs?, the team focuses on review while the AI does the implementation.

7. Using Preview Environments — Branch → URL → Sharing

What pays off across all three approaches is making full use of preview environments. Vercel automatically creates preview deployments for non-production branches and PRs, so you can put several versions of the same change side by side with no extra setup.

Sources: Environments (staging options and plans), Password Protection (pricing), Sharable Links (one on Hobby), all as of September 30, 2026. The default protection without a password is Vercel Authentication (only team members can view), which Vercel calls the recommended approach.

8. Four Pitfalls — Env Leaks, Limits and Cost, Conflicts, Rollback

Hand deploys to an AI agent and you tend to run into these four. Each can be contained with setup done in advance.

Sources: MCP environment variable tools (get_project_env returns the decrypted value), Spend Management (no extra cost on Pro and some Enterprise plans; usage is checked every few minutes, so pausing lags a little), Instant Rollback, Git configuration.

The commonly repeated advice to "put a Cloudflare proxy in front of Vercel" is not a guard we recommend. In an official KB article, Vercel says it does not recommend placing an external proxy in front, because the Vercel Firewall loses full visibility into traffic and performance drops.

One more caution: we don't recommend fully automating production deploys by AI. Even with Approaches ② and ③, keep a human's final approval for production. As noted in What Not to Give an AI, AI can break production through entirely innocent mistakes. Automate through preview and staging, and require human approval for production — a two-stage gate.

Summary

When you think about deploying to Vercel from Claude Code or Cursor, first tell apart the Git integration, the CLI, Vercel MCP, the Vercel Plugin, and Agent Skills. MCP is the means of acting, connected via OAuth; the Plugin brings /vercel-plugin:* commands and knowledge; Skills are instructions. The deploy itself is, in most cases, handled well enough by the Git integration.

The choice comes down to how much you hand to the AI and where a human stops it: ① solo work → Git integration; ② you want the AI to dig into logs and manage env too → Vercel MCP / Plugin (no token in a file — sign in with OAuth); ③ teams with routine PR review → GitHub Actions (@claude fixes; the deploy comes from the Git integration, or from Actions + CLI when you need check gates). Use previews for A/B comparison, staging, and client review, and meet the four pitfalls with tool-call confirmation, limit and spend settings, a rollback procedure, and human approval for production.

For related reading, see AI Recommends Vercel, Vercel AI SDK, v0 vs Bolt vs Lovable, What Is Cursor, and Can AI Handle Infrastructure?.

FAQ

Q. Can I do the same with other hosts (Cloudflare, Netlify)?
A. Yes. Both publish official MCP servers. Cloudflare runs a catalog of remote MCP servers you connect to with OAuth, including one for Workers builds (Cloudflare's MCP servers). Netlify has the Netlify MCP Server. Choose on framework fit and pricing rather than on whether agent integration exists. See also the selection criteria in AI Recommends Vercel.

Q. Which is better for deploying to Vercel, Claude Code or Cursor?
A. Both are supported by Vercel MCP and the Vercel Plugin, so what you can do on the Vercel side is nearly the same. The difference is workflow: Claude Code is terminal-centric, with an official GitHub Actions integration; Cursor is editor-centric, with one-click MCP setup. If you live in VS Code, Cursor feels natural; if you live in the terminal, Claude Code does.

Q. Can I let AI fully automate production deploys?
A. Not recommended. Automate through preview and staging, but always keep a human's final approval for production. The reasons: AI can break production without any bad intent, and accountability gets murky when something goes wrong. Use GitHub Branch Protection to block direct pushes to main and require approved PRs.

Q. Can I commit .cursor/mcp.json to git?
A. With the official Vercel MCP setup, it contains no secrets. It holds only the URL https://mcp.vercel.com; authentication is done with OAuth and stays on the browser side, so committing it to share with your team is fine. It's different if you hard-code another MCP server's API key in a header — keep that file out of git. Put the VERCEL_TOKEN used in CI in GitHub Secrets, never in the workflow file.

Q. I'm worried about the cost of GitHub Actions.
A. According to the official docs, cost comes from two things: GitHub Actions minutes and Claude API tokens (authenticate with a subscription OAuth token and runs use your Claude subscription instead of API billing). The per-run amount depends on prompt length, task complexity, and codebase size. The docs' ways to keep it down: cap turns with --max-turns in claude_args, set workflow timeouts, write specific @claude requests, and keep CLAUDE.md concise. No turn cap applies by default, so set one yourself.