MCP Protocol Support Across Major Agent Frameworks

Running autonomous agents on a schedule, at scale, without losing state between steps starts with a connection problem most teams underestimate: before the Model Context Protocol, every pairing of agent framework and external tool needed its own connector, its own login method, its own way of handling errors.

That math is the real cost. Teams weren't just building agents. They were running small integration departments on the side, duplicating work on authentication, discovery, error handling, and transport for every new pairing. That duplicated labor is what the Model Context Protocol was built to remove.

What MCP standardizes: the three primitives and the client-server model

MCP replaces the N-times-M problem with addition instead of multiplication: each agent framework implements the protocol once, each tool implements it once, and from there, any compliant client can reach any compliant server.

The protocol runs on a client-server model, and it's built around three primitives. Tools handle actions: sending a message, running a query, triggering a deployment. Resources handle data: files, database rows, API responses. Prompts are reusable templates that standardize how an agent approaches a given task or domain.

Two transport modes carry this traffic today: stdio for local subprocess servers, and Streamable HTTP for remote servers, which pairs HTTP with Server-Sent Events for real-time streaming and works with existing load balancers and CDNs. MCP doesn't replace the APIs underneath any of this. The APIs still do the actual work; MCP gives an agent a standard way to find them and call them. The protocol keeps moving, too, and the next shift in its specification changes what "supporting MCP" even requires.

How the 2026-07-28 specification changes the deployment calculus

The MCP specification dated 2026-07-28 marks a real break from what came before: a shift to a stateless transport core. The new spec drops that requirement. An MCP server can now run on the same kind of standard, horizontally scalable infrastructure that any HTTP microservice runs on. The distance between "MCP server" and "ordinary backend service" just got much shorter.

Two cloud platforms moved quickly on this. Amazon Bedrock AgentCore Gateway supports the new spec and lets developers route and manage MCP servers through Bedrock's infrastructure, and AWS contributed the Tasks extension that ships alongside it, built to support reliable long-running agent operations with defined states: working, input_required, completed, failed, cancelled. Cloudflare's Agents SDK (version 0.20.0) added client and server support for the 2026-07-28 spec from day one, so an MCP server can run directly inside a Worker and call tools without the overhead of a transport session. So a team can deploy a web-facing agent endpoint as something ordinary, not as an advanced configuration reserved for specialists.

None of this happened in a vacuum. That donation gave enterprises a reason to commit, and the pace of the July 2026 revision reflects that broader buy-in. For anyone choosing a framework, the practical risk is specific: a framework that hasn't updated its MCP adapter to the 2026-07-28 spec will carry session-management overhead that no longer needs to exist, and it will miss the Tasks extension. That single fact is reason enough to ask, framework by framework, who built natively for the current spec and who is still catching up.

How five major frameworks implement MCP

Support for MCP is not the same thing across agent frameworks. Some treat the protocol as a core part of the runtime, managing connection lifecycle and transport negotiation on the builder's behalf. Others expose MCP through an adapter layer that the builder has to wire up and keep current by hand. Here's how five major players line up.

CrewAI (version 1.14.6) handles both layers of the modern agent stack natively: MCP for tool connections, and A2A for agent-to-agent delegation, the latter introduced in the earlier 1.8.x release line. What CrewAI still leaves to the builder: memory, context persistence across sessions, and the human-in-the-loop checkpoints needed before a destructive tool call fires.

LangGraph connects to MCP servers through an adapter layer. LangGraph also documents interoperability with A2A, worth factoring in for teams planning multi-agent handoffs.

AutoGen, now continuing as Microsoft Agent Framework 1.0, ships MCP and A2A support natively in both.NET and Python.

The Anthropic MCP SDK is the reference implementation for both an MCP server and an MCP client, available in TypeScript, Python, C#, Go, and additional languages, with TypeScript and Python treated as Tier 1. Building directly against the SDK guarantees current spec compliance, but orchestration, memory, and scheduling are all left to the team building on it. This fits best for a team building a custom MCP server or client integration, or one that wants direct control over the protocol layer without a framework's opinions layered on top.

Mastra, a production TypeScript framework, treats MCP as a native, first-class feature sitting alongside its workflow and agent orchestration, not bolted on as an adapter. That makes it a strong fit for TypeScript-native teams who want MCP connectivity and orchestration in a single dependency rather than stitching a framework together with a separate adapter package.

UFO operates at a different layer than the five frameworks above. As a purpose-built agent operating system, UFO provides the runtime environment in which MCP-connected agents get deployed, managed, and operated, handling the substrate concerns that frameworks generally assume exist but don't actually provide themselves: scheduling, persistence, and process lifecycle. When a session dies mid-task, when a tool call times out, or when an agent needs to resume a long-running Task from one of the defined states the Tasks extension introduced, that's the layer UFO is built to handle. It complements a framework choice.

Across all five, transport coverage is the detail to check directly. The current spec defines three modes: Stdio for local, lowest-friction connections, SSE, and Streamable HTTPS for remote, scalable deployments. A framework that negotiates all three natively reduces integration surprises caused by transport mismatches. The official MCP registry already lists a large and growing number of registered servers, and framework choice determines how directly a team can plug into that ecosystem without writing custom adapter code first.

Where MCP fits in the two-protocol stack with A2A

Choosing a framework for its MCP depth only solves half the problem of connecting agents to tools once multiple agents enter the picture. MCP connects agents to tools. A2A connects agents to other agents. They're complementary layers in the same stack, not competing standards, and if a framework handles both natively, it removes the largest remaining category of custom glue code in a multi-agent system.

A2A defines how agents find each other through Agent Cards, JSON manifests describing what an agent can do, how they open a communication channel, and how they hand off tasks across agent boundaries, regardless of which framework built each side. A LangGraph agent can pass a task to a CrewAI agent through A2A without custom bridging code: the same addition-not-multiplication logic MCP applied to tools now applies to agent-to-agent delegation.

A2A has moved well past the proposal stage. It reached version 1.0 with signed Agent Cards and SDKs across six languages, and AWS, Microsoft, and Google have already integrated it into their cloud platforms. Governance mirrors MCP's own path: A2A was originally launched by Google and is now stewarded by the Linux Foundation, giving it the same vendor-neutral footing MCP gained when Anthropic handed it to the Agentic AI Foundation. Anyone building a multi-agent system should treat A2A support as a selection factor sitting right next to MCP depth, not an afterthought.

A runtime like UFO sits beneath both protocols, managing the infrastructure concerns, including process lifecycle, scheduling, and persistence, that neither MCP nor A2A addresses on their own.

The security risks that vary with how a framework implements MCP

How deeply a framework implements MCP changes its exposure to the protocol's most serious known attack: tool description poisoning, where an attacker hides instructions inside a server's natural-language metadata and uses them to redirect a connected agent into actions it was never meant to take.

Microsoft Incident Response has published a warning naming the specific danger here: tool description poisoning can redirect a connected AI agent into quietly exfiltrating company data without tripping any visible alert, and in most enterprise setups, tool descriptions can update live with no re-approval step required. OWASP's MCP Top 10, led by Vandana Verma Sehgal and in beta as of 2026, now gives security teams a named taxonomy to work from, with Tool Poisoning catalogued as MCP03:2025.

Framework architecture changes how exposed a team is here. Frameworks that manage tool discovery and connection lifecycle automatically can, if they're built with this in mind, enforce tool allowlists and flag schema changes before they reach a running agent. Frameworks relying on an adapter leave those controls entirely to the builder to implement. So if a team pulls servers from the public registry, it inherits that risk surface along with the convenience.

Enterprise teams are converging on four controls that address most of this at once: an enforced tool allowlist scoped per agent, OAuth 2.1-based identity binding so an agent inherits scoped user permissions instead of carrying standing credentials, a centralized MCP gateway for inventory and visibility, and mandatory human-in-the-loop approval before any destructive or irreversible tool call executes. The protocol itself handles none of this. MCP connectivity alone was never the ceiling on adoption. Security and governance readiness is.

MCP as Transport, Not Memory

MCP moves requests and responses between an agent and a tool. It doesn't hold onto anything after the session ends unless something on the other side of that server was built to store and retrieve it. If a team asks how to run agents that remember past context across days or weeks rather than within a single task, this is the detail that decides whether an architecture works.

"The agent remembers your context" and "the agent remembers your context until it restarts" sound similar but promise different things, and MCP's stateful sessions deliver the second one, not the first. No major framework hands this out automatically.

Long-running tasks complicate the picture further. The 2026-07-28 Tasks extension lets an agent survive a gap in execution, picking a task back up after a delay using one of its defined states. That's task-level continuity, not session-level memory, so a team needs to design the two together rather than treat them as the same problem solved twice.

A natural question follows: can a team just use a database and hook it up through an MCP server? The complication occurs at scale, when running multiple agent instances against that database requires managing its own lifecycle, its own access control, and its own failure handling, on top of everything else already being managed. That operational layer, meaning persistence, scheduling, and process lifecycle handled as substrate concerns rather than re-solved per deployment, is what a purpose-built agent operating system like UFO is designed to take on, so framework-level MCP connectivity and memory management don't have to be solved from scratch every time a new agent goes into production.

Choosing a framework based on MCP implementation depth: a practical decision framework

The right framework is the one whose MCP implementation depth matches the integration and operational demands of the agents a team is building. A few axes make that judgment concrete.

Native support versus adapter support is the first axis. Teams planning to connect to many MCP servers, or that need automatic transport negotiation across Stdio, SSE, and Streamable HTTPS, should lean toward frameworks with native MCP runtime support, meaning CrewAI 1.14.6, AutoGen, and Mastra, over adapter-based integrations like LangGraph, simply to keep long-term maintenance smaller.

Multi-agent versus single-agent architecture is the second. Any team planning agent-to-agent task delegation should weigh native A2A support right alongside MCP depth. CrewAI 1.14.6 and AutoGen ship both natively today.

Language ecosystem is the third. Python teams are well served by CrewAI and AutoGen..NET teams should weigh AutoGen's cross-language coverage specifically.

Spec currency is the fourth, and arguably the most urgent given how recently the ground shifted. Teams deploying MCP servers at any real scale need to confirm their chosen framework has actually moved to the 2026-07-28 stateless transport model. A framework still running the earlier stateful-session model carries exactly the operational overhead the new spec was built to remove.

Security posture is the fifth. Any framework going into enterprise deployment needs to support, or be compatible with, tool allowlisting, OAuth 2.1 identity binding, and a centralized MCP gateway. Where a framework's MCP adapter doesn't surface those controls on its own, the builder has to supply them at the infrastructure layer instead.

Framework choice and infrastructure choice are two separate decisions, and one sits on top of the other. The framework determines how MCP connectivity, orchestration, and A2A delegation get handled day to day. The infrastructure underneath determines persistence, scheduling, failure recovery, and operational visibility, the layer where a purpose-built agent operating system like UFO operates, complementing whichever framework sits above it.

Before committing to a framework, four questions cut through most of the uncertainty: which of the three MCP transport modes does it support natively, has it updated to the July 2026 spec, how does it handle tool allowlisting, and does it ship A2A support if multi-agent delegation is anywhere in the roadmap. Those four questions catch the integration surprises worth finding before a framework, not after.