@sergical is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​types/​node@​25.3.2 ⏵ 25.3.3
	@​biomejs/​biome@​2.4.4 ⏵ 2.4.5
	@​modelcontextprotocol/​sdk@​1.27.1

View full report

This is amazing. Thinking more about how we could tie MCP into Chat SDK overall — there seem to be two paths here and I'd love your extended thoughts on the tradeoffs.

Option 1: MCP-native (this PR)

Chat SDK owns the MCP client lifecycle, connection management, multi-server aggregation, per-call auth, etc. Users interact with MCP through bot.mcp.listTools() / bot.mcp.callTool().

Option 2: MCP-via-AI-SDK

AI SDK already has MCP support via @ai-sdk/mcp. Users would manage MCP clients themselves and pass discovered tools into generateText/streamText:

import { createMCPClient } from '@ai-sdk/mcp';
import { generateText } from 'ai';

const mcpClient = await createMCPClient({
  transport: { type: 'sse', url: 'https://jira-mcp.example.com/mcp' },
});

bot.onNewMention(async (thread, message) => {
  const result = await generateText({
    model: anthropic('claude-sonnet-4-5'),
    tools: await mcpClient.tools(),
    prompt: message.text,
  });
  await thread.post(result.text);
});

Thinking out loud

The MCP-native approach has clear benefits around lifecycle management, graceful failure, and per-call auth headers — but I'm curious what deeper integrations you envision that would make Chat SDK the right layer to own this vs. letting AI SDK handle it. For example, could Chat SDK auto-expose MCP tools as slash commands, or route tool calls differently per platform?

Would love to hear your thoughts on where this could go — it could be very valuable to have MCP deeply integrated at the Chat SDK level if there are platform-aware features that AI SDK alone can't provide.

Great questions @haydenbleasel! You're right that there are two paths — and they're complementary, not competing.

When to use which

bot.mcp (MCP-native, this PR):

• ✅ Your code decides which tools to call (deterministic workflows)
• ✅ Chat SDK manages connection lifecycle, graceful degradation, multi-server aggregation
• ✅ Per-call auth headers (tenant/user-scoped tokens)
• ✅ No AI/LLM dependency — works for slash commands, keyword triggers, etc.
• Good for: "when user says /sentry <query>, call search_issues"

@ai-sdk/mcp (MCP-via-AI-SDK):

• ✅ The LLM decides which tools to call based on the message
• ✅ Works with any AI SDK provider (Anthropic, OpenAI, AI Gateway, etc.)
• ✅ Natural multi-tool orchestration — model chains tools as needed
• ⚠️ Users manage MCP client lifecycle themselves
• Good for: "let the model figure out if it should search issues, create a ticket, or look up a user"

They compose well together

A bot can use both in the same app — bot.mcp for deterministic handlers and @ai-sdk/mcp for AI-powered ones. Chat SDK doesn't need to own the AI SDK MCP client because thread.post(result.textStream) already handles streaming from any AI SDK response.

Deeper integrations (future)

Your instinct about platform-aware features is spot on. Some things that could be interesting down the line:

• Auto-exposing MCP tools as slash commands (register tool names as /tool-name)
• Platform-specific tool rendering (e.g. Sentry issues as rich Slack cards vs plain text in Teams)
• Tool result caching per-thread via the state adapter

For now I've added a "Using with AI SDK" section to the MCP docs showing the @ai-sdk/mcp pattern with tabbed provider examples, plus a callout comparing when to use each approach.