Best MCP Tools for Building AI Agents (2026): SDKs, Servers, Clients and Gateways

What the 2026-07-28 revision changed

This is the largest revision MCP has had. The protocol is now stateless: the initialize and notifications/initialized handshake is removed, and every request carries its own protocol version and client capabilities in _meta. Servers must implement a new server/discover RPC that returns supported versions, capabilities and identity in one call. Streamable HTTP lost protocol-level sessions and the Mcp-Session-Id header, and lost SSE stream resumability, so a broken stream means re-issuing the request. Server-initiated requests such as roots/list, sampling/createMessage and elicitation/create are replaced by Multi Round-Trip Requests, where a server returns a result with resultType input_required and the client retries with the answers. Tasks moved out of the core protocol into an official extension.

Why it went stateless

The stated reason is deployment reality. Without sessions and handshakes, an MCP server sits behind an ordinary load balancer and scales horizontally like any HTTP service. Method and tool names now travel in the Mcp-Method and Mcp-Name headers, so a gateway can route and authorise without parsing the JSON body. List results carry ttlMs and cacheScope hints so clients and shared intermediaries can cache them. Read together, those three changes are the protocol conceding that most real MCP traffic goes through infrastructure that was never going to hold a stateful socket open.

Authorisation, which is where most teams get hurt

The authorisation section hardened in the same revision. Authorization servers should include the iss parameter per RFC 9207 and clients must validate it before redeeming an authorization code. Client credentials are now explicitly bound to the issuer that minted them, so they must be keyed by issuer and must not be reused against a different authorization server. Most significantly, OAuth 2.0 Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, remaining available only for backwards compatibility. If you are building an MCP server behind a login, read that section before writing any code.

Why it beats the raw SDK for a first server

Most internal MCP servers are a thin wrapper over an existing API or database. FastMCP reduces that to declaring functions and letting the framework derive the tool schema, handle the transport and manage the protocol layer. The difference is measured in hours for a first server, and the output is still a spec-compliant server any client can call. That is the whole reason it dominates the Python side of this ecosystem.

The commercial path

FastMCP is maintained by Prefect, which also sells Horizon, an enterprise MCP platform that deploys FastMCP projects from GitHub to a production URL. That relationship is worth knowing when reading FastMCP's own adoption claims, and it is also genuinely useful. The open framework and the managed deployment target are built by the same people, so the path from prototype to governed deployment is short.

Client and server in one framework

MCPClient handles multiple servers with different authentication methods, loads tools either as static configuration or as runtime toolsets, and supports approval gates before sensitive tool calls run. MCPServer goes the other direction, exposing Mastra agents, tools, workflows, prompts and resources over stdio for local packages run through npx, or over HTTP with optional OAuth middleware. Very few frameworks do both well, and the ones that do not force you to run two stacks.

MCP Apps, and why it matters

MCP Apps became an official extension in the 2026 revision, alongside Tasks and Enterprise Managed Authorization. It lets a server ship an interactive interface that renders inside the AI client rather than returning text for the model to describe. Mastra's MCPServer supports it. For anything where the right answer is a form, a chart or a confirmation dialog rather than a paragraph, that is a materially better interaction than tool output the model has to narrate.

LangGraph is the production target

The original AgentExecutor is not what you should ship. LangGraph's graph model supports durable execution with checkpointing so a run resumes after a crash, human-in-the-loop interruption, structured multi-agent orchestration and explicit state. For any agent that might pause and continue later, that durability is a selection criterion rather than a nicety, and it is the thing LangChain has that most of the newer frameworks do not.

Where the MCP adapter fits

langchain-mcp-adapters bridges LangChain tools to any MCP server, so a tool published once is reachable from a LangChain agent without per-tool integration code. That is exactly the problem MCP exists to solve. The caveat is layering: your agent depends on LangChain, which depends on the adapter, which depends on the SDK, which implements the protocol. Every one of those has its own release cadence.

Five ways to connect, and when to use each

HostedMCPTool hands the whole connection to OpenAI. MCPServerStreamableHttp is the right default when you control the network and want low latency. MCPServerSse exists for older servers and should not be chosen for new work. MCPServerStdio spawns a local subprocess and closes the pipes when the context manager exits, which is ideal for prototypes and command-line servers. MCPServerManager connects several servers up front, exposes the ones that connected and records the ones that failed, which is the behaviour you want in production.

Caching and approval

The SDK supports caching list_tools results, which matters more now that the protocol added ttlMs and cacheScope hints to list responses for exactly this purpose. It also supports tool filtering and approval policies so a sensitive tool requires an explicit decision before it runs. Turn both on: caching for cost and latency, approval for the tools whose blast radius you would have to explain afterwards.

Type safety as an MCP strategy

MCP tools are remote functions defined by someone else, often another team. Validating their arguments and their responses at the boundary is exactly the right instinct, because the failure mode of an agent calling a changed tool is a plausible wrong answer rather than an exception. Pydantic AI makes that validation the default rather than something you remember to add.

Multi-provider without lock-in

Support spans OpenAI, Anthropic, Google, Groq, Mistral and local models through one interface, so switching providers is configuration rather than a rewrite. Combined with MCP handling the tool layer, that leaves very little of an agent tied to any single vendor, which is the strongest architectural argument for this combination.

Streaming chat, done properly

The SDK's hooks and streaming primitives handle partial responses, tool call rendering, and error states that are tedious to build by hand. For a consumer-facing or internal chat product on Next.js, that is most of the interface work. Pair it with a proper agent runtime as soon as the logic behind the chat stops being a single turn with tools.

Local to remote is the real migration

Almost every MCP project starts with a stdio server on a developer laptop, and almost every one of them eventually has to become a remote server other people and other clients can reach. That transition brings transport, authentication, authorisation, deployment and scaling all at once. Hosting on Workers collapses most of it, which is why this belongs on a list of MCP tools even though it is not an MCP framework.

Why statelessness makes this easier

The 2026-07-28 revision removed protocol-level sessions and the Mcp-Session-Id header specifically so servers could sit behind ordinary load balancers and scale horizontally. An edge platform that spreads requests across many isolates is exactly the deployment shape that used to fight the protocol and now matches it.

The problem it exists to solve

MCP made it cheap to expose tools, which means organisations end up with many servers faster than they expect. The questions that follow are governance questions: which servers exist, who owns each one, which tools can which agent call, and where is the record of what was called. A registry plus tool-level RBAC plus audit logging answers all four in one place, and doing it per-client does not scale past a handful of teams.

Gateway as a protocol beneficiary

The 2026 revision was partly designed for this layer. Requiring Mcp-Method and Mcp-Name headers on Streamable HTTP POSTs lets a gateway route and authorise a call without parsing the JSON body. cacheScope on list results tells a shared intermediary whether it may cache a response at all. Gateways were previously working against the protocol; they are now working with it.

Why sandboxing third-party servers is not paranoid

An MCP server is arbitrary code that an AI client will call with arguments a model chose. Running an unfamiliar one directly on a development machine gives it your filesystem, your network and your credentials. Containerising it with restricted privileges, network access and resource limits turns a broad trust decision into a bounded one, and costs a few seconds of setup. This is the lowest-effort security improvement available anywhere on this page.