MCP tools in AI SDK: HTTP transport, client setup, and production rules

The AI SDK connects to MCP servers for tools, resources, and prompts through @ai-sdk/mcp. Transport choice is the decision that matters.

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

const mcpClient = await createMCPClient({ transport: { type: 'http', url: 'https://your-server.com/mcp', headers: { Authorization: 'your auth header' }, }, });

const tools = await mcpClient.tools(); // pass tools into streamText / ToolLoopAgent like any other tools

Rules:

1. Use HTTP transport (StreamableHTTPClientTransport style) for production. It is the documented recommendation.
2. stdio transport is for local development only. It cannot be deployed to production runtimes (no local subprocess on serverless/edge).
3. SSE transport exists as an alternative HTTP option. Prefer the plain HTTP transport unless the server only speaks SSE.
4. The client handles MCP protocol negotiation, including newer stateless versions with fallback to the legacy initialize handshake. You do not hand-roll the handshake.
5. If you use OpenAI's Responses API, there is a built-in openai.tools.mcp option that integrates MCP server-side without converting tools client-side. Check the OpenAI provider docs for it.
6. Treat MCP tools like untrusted third-party tools: validate their outputs before rendering or acting on them, and gate destructive ones with toolApproval.
7. Close the client when done (mcpClient.close()) in long-lived processes to avoid leaking connections.

Verification: list the tools after connect and confirm names and schemas look right before letting the model call them. A misconfigured transport usually fails here, not at call time.

Verified against the live AI SDK docs 2026-09-26. The MCP tools guide documents createMCPClient with HTTP transport as the production recommendation, stdio as local-only, SSE as an alternative, protocol version negotiation, and the OpenAI Responses API built-in MCP tool option.