Dora NodaVercel's official MCP server launched in August 2025 completely read-only. It took eleven and a half months to gain its first tool that changes anything — and when deploy_to_vercel finally shipped on July 23, 2026, it deployed new code to a new project, not the thing most agent-ops write-ups assumed was coming: control over an existing one's environment variables, domains, or a rollback button.
That gap is the actual story. Vercel is the reference implementation every other git-push platform's MCP server gets measured against, so what it chose to expose — and, more tellingly, what it still refuses to — sets the bar for what "an agent can operate this platform" is allowed to mean in 2026. Here's the full tool list, categorized by what an agent can actually do with it, and what that means for any self-hosted platform building its own deploy/rollback MCP server against the same bar.
What's Actually in the Box
The official server lives at mcp.vercel.com, a hosted OAuth-gated endpoint — no local install, no token pasted into an env var. As of its current tool list, here's every category it exposes:
| Category | Tools | Read or write |
|---|---|---|
| Docs | search_vercel_documentation | Read |
| Teams / Projects | list_teams, list_projects, get_project | Read |
| Deployments | list_deployments, get_deployment, get_deployment_build_logs, get_runtime_logs, get_runtime_errors | Read |
| Deployments | deploy_to_vercel — ships files to a new or existing project, no Git repo needed | Write |
| Web Analytics | get_web_analytics | Read |
| Agent Runs | list_agent_run_projects, list_agent_runs, get_agent_run, get_agent_run_trace (eve-framework agent traces) | Read |
| Domains | check_domain_availability_and_price | Read |
| Purchases | get_purchase_quote, buy_pro, buy_credits, buy_addon, buy_domain, get_domain_order — real, non-refundable charges | Write (gated) |
| Toolbar comments | list_toolbar_threads, get_toolbar_thread, reply_to_toolbar_thread, change_toolbar_thread_resolve_status, edit_toolbar_message, add_toolbar_reaction | Read + write |
| CLI | use_vercel_cli — points the agent at --help output | N/A |
That's a wide surface: an agent can read every deployment's build and runtime logs, pull grouped runtime error clusters, query Web Analytics, inspect another agent framework's execution traces, and now — as of one month ago — deploy a working file tree straight to a URL with framework auto-detection and no Git repo in sight. deploy_to_vercel takes a target (preview or production), a project name, and a files array; Vercel installs dependencies and builds it. That's a real, no-human-in-the-loop production deploy path, exactly as billed.
The Agent Runs category is worth a second look too, because it's not about Vercel's own platform at all — it's observability for eve, Vercel's separate agent framework, meaning list_agent_runs and get_agent_run_trace let one agent inspect another agent's tool calls, token usage, and reasoning trace after the fact. That's a tell about who Vercel expects to be pulling this lever: not just a human debugging a broken build, but an agent auditing a different agent's production run. The read surface as a whole is built for exactly that audience — wide enough that an agent never needs to leave MCP just to understand what happened to a deployment.
But scan the table again for what's not there, because that's the part every "Vercel ships an official MCP server" headline skipped.
The Four Tools That Aren't There
No environment-variable tools at all. Not list_env_vars, not get_env_var, nothing. This isn't an oversight nobody's noticed — there's an open thread in Vercel's own community forum titled "How to manage environment variables with Vercel MCP," asking for exactly list_env_vars / get_env_var / set_env_var / delete_env_var, still unresolved. Any agent workflow that needs to rotate a secret, wire up a new integration, or check that preview and production env vars are actually in sync has to drop out of MCP entirely and fall back to the CLI or the REST API. For a server that can now deploy a brand-new project from a raw file tree, being unable to read or write a single environment variable on an existing one is a strange line to draw — until you read it as a deliberate one.
Domain tools stop at "can I buy this." check_domain_availability_and_price tells you if a name is free and what it costs. There is no tool to attach a domain to a project, verify DNS, or touch nameserver configuration on a domain you already own — the entire domain surface is availability-check-then-purchase, not configure-what-you-have.
No rollback tool, despite vercel rollback <deployment-id> existing in the CLI today. An agent that reads list_deployments, discovers the current production deployment is broken via get_runtime_errors, and wants to revert to the last good one has every read tool it needs to diagnose the problem and zero tools to fix it without leaving MCP.
No multi-project batch operations. Every deployment/log/analytics tool takes a single projectId. Vercel's personal access tokens don't carry per-tool scopes either — a token is scoped to a project or it isn't, full stop — so there's no "roll back these five services" in one call, by design as much as by omission.
Put together, the shape is consistent, not accidental: read everything, deploy net-new code, and — behind an explicit quote-then-confirm flow with a signed, 5-minute idempotencyKey — spend real money on a domain, a Pro upgrade, or prepaid credits. What an agent still cannot do through Vercel's own official server is mutate the configuration of something that already exists: no env-var writes, no domain reconfiguration, no rollback, no batch changes. That quote-then-confirm purchase mechanism is worth remembering as a pattern if a platform ever needs an agent to spend real money — but it's a separate concern from the deploy/rollback/config gap this piece is actually about, and conflating the two is how "market leader ships an MCP server" write-ups miss what the market leader actually decided not to ship.
What This Means for a Platform Whose Own MCP Server Already Mutates Config
Here's where the gap gets concrete instead of abstract. Bex's own MCP server — shipped, not roadmapped — already exposes list_env_vars, get_env_var, update_env_vars, set_env_var, and delete_env_var, and a write rolls the affected pods immediately, because bex has no separate "deploy after env change" step the way Render's dashboard does. It also ships restart_service, suspend_service, resume_service, scale_service, and update_service_plan — full lifecycle mutation, not just reads. On the exact axis where Vercel's official server draws its firmest line — touching an existing service's configuration — bex's MCP surface is already on the other side of it.
What bex doesn't have yet is deploy_to_vercel's actual party trick: take a raw file tree with no Git repo and no existing project, and get back a live URL. That's tracked explicitly as pillar 4 in bex's own roadmap — "deploy-from-chat," still marked planned, not shipped — and Vercel's July 2026 ship date is a useful data point for how that tool should be scoped when it lands: target (preview/production), a name that creates the project if missing, a files array, and let the platform's own build detection take it from there. There's no reason to reinvent that shape when the reference implementation already validated it.
The rollback gap is the more interesting one to get right, because bex doesn't have a shipped rollback tool either — it's tracked in the same breath as scale and redeploy as "the way we build them sets the precedent for every future verb." Given that restart_service / suspend_service / resume_service are already keyed on the same Render-shaped serviceId every other tool uses, the natural shape for a rollback_service tool is the same: {serviceId, revision?}, defaulting to the previous known-good revision when revision is omitted, returning the updated service object exactly like restart/suspend/resume do. That's the one tool in Vercel's own official server that doesn't exist at all — building it, scoped to a single service and keyed the same way every other lifecycle verb already is, is a place bex can simply exceed the baseline rather than match it.
The purchase/spend-money question is worth a deliberate no for now. Bex has no buy_* tools and shouldn't invent one just because Vercel did — a platform whose core promise is "on machines you own" has a much smaller need for an agent that spends money on the platform's own behalf. If that ever changes — a paid tier, a marketplace add-on — the quote-then-confirm-with-idempotency-key pattern Vercel already shipped and battle-tested is the one worth copying wholesale rather than redesigning from scratch.
The Actual Bar
"Vercel shipped an official MCP server" is true and, on its own, tells you almost nothing about what an agent can do with it. The useful version of that sentence is the tool list: read everything, deploy net-new code as of one month ago, spend real money behind a confirmation gate — and leave every existing service's configuration exactly as it was. That's not a platform holding back out of laziness; it's a specific, defensible line about what "agent-operated" is allowed to mean for the largest git-push platform in the market. Any team building a competing MCP server — including one for a self-hosted platform — now has a concrete, tool-by-tool baseline to either match, quietly exceed, or deliberately cross, instead of guessing at what "agent-ops parity with Vercel" is supposed to mean.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server that already lets an agent read and mutate a service's environment variables, not just deploy new code. Star the repo on GitHub or deploy your first app today.
