TanStack AI adds MCP support with pooled servers and typegen CLI

• TanStack AI shipped MCP support that can talk to one server or many, with either standalone clients or pooled servers, according to tan_stack's launch post and the linked TanStack blog post.
• The integration is deliberately host-side: TanStack's blog post says MCP servers get turned into ordinary ServerTool[], so the rest of the chat stack stays unchanged, while tan_stack's feature list pitches that as managed lifecycle or full manual control.
• TanStack split typing into three modes, from runtime discovery to explicit tool definitions to generated per-server interfaces, as the launch blog, the codegen docs, and tan_stack's post all outline.
• The release also hides some practical plumbing that matters more than the tweet implies: the managed MCP docs handle discovery and lifecycle for you, while the manual MCP docs note that tool calls execute lazily during streaming, so closing a client too early breaks runs.

You can jump straight to the launch blog, skim the managed MCP path, and read the separate docs for manual typed tools and type generation. tan_stack's launch video also makes the positioning clear fast: this is MCP as another tool source inside TanStack AI, not a parallel agent runtime.

The core design choice is in TanStack's blog post: @tanstack/ai-mcp is a host-side MCP client that turns any MCP server into ordinary ServerTool[] for chat(). That means adapters, agent loops, and framework integrations above it do not need MCP-specific branches.

The same post says createMCPClient belongs in a server route or serverless function, never in browser code. Transport support is split between streamable HTTP for edge-safe deployments and Node stdio behind a subpath, which keeps the package deployable in edge-style environments.

The launch blog and the codegen docs break the API into three typing modes:

1. Auto-discovery: client.tools() discovers everything from the server, with runtime validation from the server's JSON Schema but no compile-time tool-name checking.
2. Explicit definitions: client.tools([toolDefinition(...)]) adds Zod-validated, TypeScript-typed arguments for the tools you define.
3. Generated interfaces: the generate CLI introspects a live MCP server and emits per-server TypeScript interfaces, which narrow discovered tool names to literals and also compile-check pool config keys.

The docs are precise about one caveat: the codegen page says Mode 3 tightens tool names, but discovered tool arguments still stay untyped unless you combine it with explicit tool definitions.

The biggest implementation detail is lifecycle. The managed MCP docs let chat() own discovery and cleanup through an mcp option, which is the lower-friction path when runtime typing is enough.

The manual MCP docs expose the sharper path: you call client.tools(), client.resources(), or client.getPrompt() yourself, and you also own close(). Because tool execution happens lazily while the response stream is still running, the docs warn against closing the client in a finally block before the stream is consumed.

The pooling piece is similarly concrete. TanStack's blog post says createMCPClients can connect to multiple servers in parallel, flatten their tools into one list, and report failures by the config key you assigned to each server.

Tools are only part of the surface. TanStack's blog post says MCP resources and prompts can also be converted into shapes that chat() understands, which gives the package a wider MCP bridge than simple tool invocation.

That makes the release feel more like MCP wiring for app builders than a one-off tool adapter. AlemTuzlak's post frames it as a major internal drop, but the useful part is in the docs: TanStack is packaging server discovery, typed tool paths, pooling, and prompt/resource conversion into one MCP layer.