MCP Events in Vercel Connect: What Changed and What to Do

Vercel Connect now supports MCP Events in public beta, allowing applications and autonomous agents to subscribe to webhook events from compatible MCP servers. With MCP Events, Connect creates the subscription on the MCP server, renews it as needed, verifies the server's webhooks and forwards events to your application with authenticated delivery.

What changed with MCP Events in Vercel Connect

According to the official Vercel changelog, the platform creates subscriptions directly on the MCP server and automatically renews them as needed. Connect verifies the server's incoming webhooks and forwards events to your application using authenticated delivery, so your receiver's job is to verify Connect's delivery and accept the event durably before acknowledging it. This lets teams build agents for tasks such as summarising new messages, reviewing newly created issues, or responding to document feedback.

The changelog example requests a subscription to issue events with a 24-hour TTL. You can also expose event discovery and subscription as agent tools in the AI SDK using Connect's MCP Events adapter. In eve, Vercel's agent framework, enabling events on an MCP connection gives agents tools to discover the server's events and use Connect to create, inspect, or stop subscriptions. In our view this is the same direction as the agentic commerce protocols: agents react to pushed events instead of polling.

Who the public beta affects

The public beta affects developers building event-driven agents on Vercel Connect in TypeScript or Python.

Vercel Connect is available on all plans and is subject to the Vercel Connect terms. There are no documented tier-based restrictions.

Runtime prerequisites are documented in the Vercel Connect quickstart. For TypeScript environments, projects must use Node.js 18 or later. For Python applications, teams need Python 3.10 or later alongside the uv package manager.

If your stack already runs on supported runtimes, adopting event subscriptions requires minimal tooling adjustments. However, teams maintaining older runtimes must upgrade their local and deployment environments before attempting SDK installation or connector attachment.

What teams should evaluate before enabling subscriptions

Teams should evaluate token authentication methods, environment link targets, and webhook endpoint verification before deploying subscriptions to production routes.

First, link your local directory to a project so the SDK can use OIDC tokens before you write subscription logic. Second, app-subject tokens skip the user-consent flow, which suits background automation. Some third-party providers still require a one-time installation or administrator grant, so permissions must be cleared early.

Environment linking also requires deliberate scoping. Creating the connector from the project page automatically links Production, Preview, and Development environments. It does not automatically include Custom Environments. To enable a Custom Environment, you must create the connector first, then open its Projects section, edit the project link, and select the Custom Environment. CLI users can pass -e production -e preview to restrict the link, or pass a Custom Environment slug such as -e qa. When designing custom MCP server implementations, map environments deliberately. The MCP Events docs add one constraint beyond the changelog: event subscriptions currently require Production or a Custom Environment as the receiver, and a Custom Environment needs a verified domain that serves the deployment without redirects.

How to configure event subscriptions

Configuring event subscriptions involves installing the SDK, authenticating local directories with OIDC, attaching target environments, and verifying deliveries inside a route handler.

1. Install runtime dependencies and SDK packages. Install the Vercel Connect SDK along with the dependencies you need to run a script locally, verifying that TypeScript projects use Node.js 18 or later and Python projects use Python 3.10 or later with uv.
2. Link the project directory for OIDC authentication. Link the directory to a project to handle secure OIDC token authentication, which creates a .env.local file containing VERCEL_OIDC_TOKEN that the SDK uses to authenticate calls to Vercel Connect.
3. Create the connector and configure environments. Create your first connector in Vercel Connect from the project page, which automatically links Production, Preview, and Development environments, or apply -e production -e preview to restrict the links.
4. Implement delivery verification in your route. Verify incoming deliveries in a route handler, as the changelog's Next.js example does with experimental_verifyMcpEvent, while Connect manages the server subscription renewals.

When you deploy to Vercel, token management happens automatically.

Managing these subscriptions programmatically fits the MCP scaling patterns we describe elsewhere: push over polling.

What the MCP Events docs add beyond the changelog

The changelog example uses a 24-hour TTL; the MCP Events documentation gives the full range. You set ttlMs when subscribing, as an integer from 120000 to 31536000000 milliseconds (two minutes to 365 days), or ttlMs: null to monitor until the subscription is explicitly stopped. Subscription responses include the resolved expiresAt deadline, or null for an indefinite watch, and Connect renews the upstream provider lease within that lifetime, so you do not schedule AI SDK refresh calls when using the Connect adapter.

Delivery is where the docs are most direct. Connect currently forwards deliveries inline: it does not retain a durable payload outbox, and it does not provide scheduled redelivery, delivery history or manual replay. The provider's own retry and replay window is what limits recovery when your receiver is unavailable, so the documentation's advice is to accept work into a durable inbox quickly and process it asynchronously. Each envelope carries a deliveryId, a subscriptionId and saved application context, and besides event payloads it can carry a gap control, meaning some events cannot be replayed and state should be reconciled with the source, or a terminated control with the provider's reason. Make worker side effects idempotent, because deliveries can repeat or arrive out of order.

Two more facts belong in the plan. The beta needs Connect SDK 2.5.2 or later and the AI SDK MCP client 2.0.76 or later. And MCP events are priced as triggers: each delivery that Connect forwards to your destination counts as one trigger, and billing stops when you stop the subscription.

Your next three moves

To adopt the public beta safely, engineers should audit local runtimes, link development projects with OIDC authentication, and validate incoming route verification.

First, inspect your local development environment to ensure your toolchain complies with the platform baselines. TypeScript repositories require Node.js 18 or later, while Python services require Python 3.10 or later alongside uv. Upgrading these dependencies early prevents runtime errors during SDK installation.

Second, link your local directory to your Vercel project before writing subscription logic. This step generates your local .env.local file populated with VERCEL_OIDC_TOKEN, which ensures your local testing mirrors the automatic token management provided in Vercel deployments.

Third, implement a test endpoint verifying incoming deliveries in a Next.js route before wiring production agents to external MCP servers. If your team is evaluating event-driven architectures across complex checkout or catalogue pipelines, our Shopify integrations team designs the webhook side of it.