AI SDK Adds Push Events to MCP

AI SDK now implements the webhook portion of the draft Model Context Protocol Events specification through its experimental Events APIs. Compatible MCP servers can push signed notifications to an application after the original session ends, replacing repeated polling with server-initiated delivery.

Most MCP integrations currently follow a request-and-response flow: an agent calls a tool, the server responds, and the connection closes. Changes that occur later remain invisible until the application polls again. Event subscriptions allow the server to send updates when its underlying data changes.

Vercel also launched corresponding Connect public beta support. The managed service maintains subscriptions, verifies server webhooks, and forwards authenticated events to an application endpoint.

Push that outlives the session

An event subscription remains active after the MCP client session closes, allowing agents to respond to new messages, created issues, document comments, CRM updates, and similar external changes. The server emits each event without waiting for another tool call.

Before subscribing, an application reads the server’s event catalog to learn the available names, schemas, and delivery modes. The AI SDK maps the webhook lifecycle to three experimental APIs:

• experimental_events.list() returns the event catalog, including argument schemas, payload schemas, and supported delivery modes.
• experimental_events.subscribe() registers a webhook for an event such as comment.created, with arguments that can limit delivery to a specific resource.
• experimental_createMCPEventWebhook() creates a direct receiver that handles callback challenges, verifies event signatures, validates payloads, and dispatches verified events to onEvent.

Connect renews the lease

A self-hosted webhook deployment must store subscriptions, renew expiring leases, verify signatures, track replay cursors, and clean up terminated records. Vercel Connect creates and renews subscriptions on the MCP server, verifies incoming webhooks, and forwards authenticated deliveries to the configured application route.

The experimental_connectEventsAdapter connects that managed flow to an existing MCP client. Using connectAuthProvider and the adapter with the same connector and resolved token parameters authorizes catalog discovery and subscription creation under the same account.

Authentication and event delivery share the connector and token parameters, while destination.path identifies the route that receives forwarded events. A minimal Connect-backed subscription looks like this:

const client = await createMCPClient({
  transport: {
    type: 'http',
    url: 'https://documents.example/mcp',
    authProvider: connectAuthProvider(connector, tokenParams),
  },
  experimental_events: {
    adapter: experimental_connectEventsAdapter({
      connector,
      tokenParams,
      destination: { path: '/hooks' },
    }),
  },
});

await client.experimental_events.subscribe({
  name: 'comment.created',
  arguments: { document_id: documentId },
  idempotencyKey: requestId,
  ttlMs: null,
});

Setting ttlMs: null delegates lease renewal to Connect until the subscription ends. A stable idempotencyKey protects subscription creation when the initiating request is retried.

The destination route should call experimental_verifyMcpEvent from @vercel/connect/mcp before acknowledging a forwarded request. This check confirms that Connect sent the delivery.

Self-hosting exposes the full lifecycle

Developers who need direct control can use the reference project, which includes a local MCP server, webhook receiver, and file-based subscription store. It runs without a model API key.

A custom deployment implements the Experimental_MCPEventStore interface for subscription records, signing secrets, and replay cursors. The receiver then exposes callbacks for normal delivery, replay gaps, and termination:

• onEvent receives business events after signature verification. Return 204 after successful handling and 503 after a storage or callback failure so the provider can retry.
• onGap runs when the server cannot replay every missing event. The application reconciles against the authoritative system, after which the SDK stores the new cursor and resumes delivery.
• onTerminated runs when the server ends a subscription. The SDK then deletes the corresponding subscription record.

The receiver must stay online

Closing an MCP client releases its connection while active webhook subscriptions continue delivering events. The receiver therefore needs to remain deployed and reachable for the subscription’s full lifetime.

Signature verification establishes the sender and integrity of a request. The validatePayload callback separately enforces the application’s schema before event data reaches business logic.

The demo server allows five seconds for a callback response, which leaves little room for model inference or slow downstream APIs. A production handler should durably enqueue the verified event inside onEvent, acknowledge it, and run generateText or other expensive work in a worker. Use the subscription ID with event.eventId as a deduplication key, and make worker side effects idempotent.

Where push delivery fits

Event delivery suits workflows triggered by changes outside the agent process, including summarizing new document comments, triaging filed issues, drafting replies to inbound messages, and monitoring CRM status changes. Eligible workflows can replace cron jobs and repeated MCP tool calls with a persistent subscription.

Server-initiated delivery also shortens the interval between a source change and agent processing, which otherwise depends on the polling schedule.

Beta boundaries

• The APIs remain experimental and follow a draft MCP Events specification that may change.
• Each MCP server must implement the Events extension. Existing tool endpoints require a separate event implementation.
• Vercel Connect currently supports production and stable custom environments for managed events. Preview and development environments are excluded from the public beta.

The local reference project provides a contained way to test event catalogs, subscriptions, verification, replay handling, and termination before adopting the managed or self-hosted path.