What changed
On September 24, Vercel announced Vercel Connect support for TanStack AI. The new @vercel/connect/tanstack-ai subpath exports connectMCPTransport, which wraps a TanStack transport with a Connect-backed authentication provider. The provider requests a current token before each MCP call, so a TanStack AI route can reach an OAuth-protected server without keeping provider credentials in the application.
The integration also makes consent a route-level concern. If the signed-in user has not authorized the connector, getConsentChallenge exposes a URL that the app can return as a redirect or surface to its chat UI before the model stream starts.
Why it matters
MCP makes tools portable, but authentication is still the integration tax. An app that connects an agent to Linear, Slack, GitHub, or another OAuth-backed service usually has to manage provider registration, refresh tokens, user-to-account mapping, and consent recovery alongside its chat logic. Connect moves that plumbing into an integration layer while leaving the app responsible for the identity of the current user and the tools it wants to expose.
That changes the product boundary. The model can stay focused on deciding which tool to call, the MCP server can stay a standard tool endpoint, and the application can ask for a short-lived, scoped credential at the moment it needs one. Vercel's authentication documentation explains that refresh tokens for OAuth connectors stay on Vercel's infrastructure and that application code receives short-lived access tokens through Connect.
The builder pattern
The TanStack AI integration guide shows a practical route shape:
- Create an MCP client with
connectMCPTransport, passing the connector UID, the authenticated user's stable subject ID, and the narrowest useful scopes. - Keep the MCP client and Connect token requests on the server. Do not accept an arbitrary user ID from the request body.
- Catch a consent challenge before streaming and return a
303redirect, or return a consent URL to the chat UI with a retry path. - Treat OAuth consent and tool approval as separate controls. Access to a Linear account does not automatically approve every tool that can create, update, delete, send, or spend.
The same pattern can support multiple MCP servers, but the docs warn that per-user clients should be created inside each request. Reusing a client pool with the wrong subject can make requests act through another user's account.
The product takeaway
The notable shift is not just another framework adapter. It is authentication becoming part of the agent transport boundary. For teams building AI products, that means less custom credential code and a clearer architecture: identity and consent belong to the application, provider token issuance belongs to the connector, and tool-level approval remains an explicit product decision.
That is a useful direction for portfolio apps and production agents alike. The best MCP experience is not merely a model that can call more tools; it is a tool connection that can earn user consent, use the right account, receive the smallest practical scope, and recover cleanly when authorization is missing.