The N×M integration problem
For as long as language models have been able to call tools, teams building agents have run into the same wall: every tool needs its own integration, and every agent framework wants that integration described in its own way. Give an agent access to a file system, a database, a ticketing system, and a search API, and you have written four bespoke adapters, each translating between the model's tool-calling format and that particular service's API. Multiply that by every agent you build, and by every framework your organization uses, and you get what is sometimes called the N×M problem: N agents each needing custom code for M tools, with the amount of integration work growing as the product of the two rather than the sum.
This is not a new problem in software; it is the same wall that networking hit before TCP/IP, that web services hit before REST and JSON became the default, and that language servers hit before the Language Server Protocol let one implementation serve many editors. The pattern is familiar: when point-to-point integration work grows faster than the ecosystem around it, the fix is a shared protocol that turns N×M work into N+M work. Each tool implements the protocol once, each agent framework implements the protocol once, and the two sides interoperate without ever having been written with each other in mind.
Agentic AI arrived at this same juncture. As agents moved from single-purpose demos wired directly to two or three APIs toward general-purpose systems expected to reach dozens of tools and data sources, the bespoke-adapter model stopped scaling, and a wave of protocol work emerged to fix it. The most consequential of these, at least so far, is the Model Context Protocol.
The bespoke-adapter model does not scale past a handful of tools. A protocol turns N times M integration work into N plus M.
Enter the Model Context Protocol
The Model Context Protocol, MCP, is an open specification for how an AI application connects to external tools, data, and context. Anthropic released it in late 2024, and it has since been adopted broadly enough that a large share of new agent tooling ships an MCP integration as a default rather than an afterthought. The core idea is unglamorous and exactly right: define a standard way for a host application, the thing running the model, to talk to a server that exposes capabilities, and let any host talk to any server without custom glue.
MCP borrows a client-server shape that will look familiar to anyone who has worked with the Language Server Protocol, which solved a strikingly similar problem for code editors. Before LSP, every editor needed its own integration with every language's tooling; after LSP, a language only needed one server, and an editor only needed one client, for the two to work together regardless of which specific editor or which specific language was on the other end. MCP does the same trick for agents and tools: an MCP server exposes what it can do in a standard shape, and an MCP client, embedded in the host application, knows how to talk to any server that speaks the protocol.
Under the hood, MCP communicates over JSON-RPC 2.0, a lightweight remote procedure call format that has been stable and well understood for a long time. Messages flow over one of a small number of transports: standard input and output for a server running as a local subprocess, or HTTP with server-sent events for a server running remotely. That choice of transport matters less than it might seem; the important thing is that the message shapes above the transport are identical either way, so a client does not need special-case logic for local versus remote servers beyond the connection itself.
Anatomy of an MCP server
An MCP server declares its capabilities to a connecting client during an initialization handshake, and those capabilities fall into three categories that are worth keeping distinct, because conflating them is a common source of confusion when people first design a server.
Tools are actions the model can invoke: functions with a name, a description, and a schema for their arguments, exactly like the function-calling interfaces most model APIs already support. A tool might search a knowledge base, create a ticket, or run a calculation. The model decides when to call a tool and with what arguments, the same way it would with any function-calling setup; MCP's contribution is standardizing how that tool gets described and invoked so the same tool definition works across host applications without being rewritten for each one.
Resources are data the host can read and hand to the model as context: a file, a database record, a page of documentation. Resources are not actions; they are addressable content, identified by a URI, that a client can fetch and inject into the conversation. The distinction matters because resources are typically under the application's control rather than the model's: a host might list available resources and let a user pick one, or fetch a resource automatically based on the task, without the model ever needing to call a tool to get it.
Prompts are reusable templates a server exposes, parameterized snippets that produce a well-formed instruction or a whole conversation starter. They exist because a server often knows the right way to phrase a request to accomplish something specific with its data, and it is more reliable to ship that phrasing with the server than to hope every client reinvents it correctly.
Keeping tools, resources, and prompts conceptually separate pays off in server design. A server that shoves everything into tools, including things that are really just data to read, ends up with a model making unnecessary decisions about when to fetch something that should simply have been provided. A server that gets the split right lets the host application handle context assembly deterministically where it can, and reserves the model's judgment for the things that actually require it.
Why a protocol beats another SDK
It is fair to ask why this needed a protocol at all rather than just a good SDK. Plenty of tool-calling libraries already exist, and most model providers offer their own function-calling conventions. The answer is that an SDK solves the problem for one side of the relationship, while a protocol solves it for both sides at once, and that difference compounds as the ecosystem grows.
An SDK for connecting to tools still requires the tool provider to write an integration for whatever calling convention that SDK expects, and a different integration for the next SDK, and the next. A protocol flips the incentive: a tool provider implements the server side once, publishes it, and every compliant client can use it without either party having coordinated in advance. This is precisely the property that let the web scale past what any single company could build: nobody at a search engine had to negotiate with every website for their crawler to work, because HTTP and HTML were shared enough that the crawler just worked against sites it had never seen before.
The practical effect for someone building agents today is a growing directory of ready-made MCP servers for common systems, source control, databases, documentation platforms, ticketing systems, search, that can be connected with configuration rather than code. The practical effect for someone building a product with data or capabilities to expose is that shipping one MCP server makes that product usable by every MCP-compatible agent, present and future, rather than by the one integration they had the resources to build themselves.
An SDK solves the problem for one side of an integration. A protocol solves it for both sides at once, which is why it scales differently.
What changes on the model side
From the model's point of view, very little changes: it still sees a list of available tools with names, descriptions, and schemas, and it still emits a structured call when it wants to use one. The protocol operates beneath that layer, in how the host application discovers, connects to, and proxies calls through to servers, which is deliberately invisible to the model itself. This is a feature, not a limitation: MCP is infrastructure for the host, not a new capability the model needs to be specifically trained to use beyond ordinary tool calling, and it means a model can benefit from the protocol's reach without needing any special awareness that MCP exists at all.
Where things do change meaningfully is in the host application's responsibilities. A host that supports MCP needs to manage a set of active server connections, aggregate the tools and resources those servers expose into whatever the model's context expects, route a model's tool call to the correct server, and handle the results, including partial failures where one server is unavailable while others work fine. This is real engineering, session lifecycle, error handling, capability negotiation, but it is engineering the host application does once, rather than once per integrated service, and that is the whole point.
Agent-to-agent is a different problem
MCP solves how an agent reaches tools and data, but there is an adjacent problem it was never designed to solve: how one agent talks to another agent, especially when the two are built by different teams, run different models, and were never designed with each other's internals in mind. Calling another agent is not quite the same as calling a tool, because the other side is not a fixed function with a predictable output; it is itself a reasoning system that might ask clarifying questions, work asynchronously over an extended task, or need to negotiate what it is actually capable of before committing to work.
Treating another agent as just another tool call gets you partway, and for a lot of practical purposes it is entirely sufficient: wrap the other agent behind a single function that takes a task description and returns a result, and the calling agent never needs to know it is talking to something more complex than an API. But that framing breaks down once you need the interaction to be genuinely bidirectional, long-running, or exploratory, where the calling agent needs to see intermediate progress, redirect a task partway through, or hand off additional information the other agent asks for mid-task. Those needs are what motivated a separate protocol aimed specifically at agent-to-agent communication.
The Agent2Agent protocol and agent cards
The Agent2Agent protocol, generally shortened to A2A, approaches this from a different angle than MCP. Rather than describing tools and resources, it describes agents as first-class entities that publish an agent card, a machine-readable document describing what the agent can do, what input it expects, what it returns, and how to reach it. A client agent can fetch another agent's card, decide whether it is a fit for the task at hand, and then start a task with it over a standard message exchange that supports back-and-forth turns rather than a single request and response.
That task-oriented design matters because a lot of genuinely useful agent-to-agent work does not fit a single call. A research agent asked to gather competitive intelligence might need to check in partway through, report what it has found so far, and ask whether to keep going in a particular direction or pivot. A2A models this directly, with tasks that have a lifecycle, states beyond just done or not done, and support for streaming updates as work progresses, rather than forcing every interaction into the shape of a synchronous function call.
The other property worth noting is that A2A treats the called agent as an opaque, capability-described endpoint rather than something the caller reaches into. The calling agent never sees the other agent's internal reasoning, model choice, or tools; it sees only the published card and the task protocol. That opacity is deliberate and mirrors how organizations actually want to expose agents to each other: a vendor can offer an agent as a service, describe what it does, and keep everything about how it does it private, the same way a REST API hides its implementation behind a contract.
Where the two protocols meet
MCP and A2A are frequently discussed together, and it is worth being precise about how they relate, because they are solving neighboring problems rather than competing for the same one. MCP is the protocol for an agent reaching down into tools, data, and context it needs to do its own work. A2A is the protocol for an agent reaching sideways to another agent that will do a chunk of work on its own terms and report back. A single system can use both at once without any tension: an orchestrating agent might use A2A to delegate a research task to a specialist agent, which in turn uses MCP to search a document store and query a database while doing that work.
This layering is a healthy sign, because it means neither protocol is trying to be everything. A protocol that tried to describe both stateless tool calls and long-running, stateful, bidirectional agent collaboration in a single unified shape would likely do both worse than two protocols each shaped around the problem they actually address. The lesson generalizes past this specific pair: standards tend to survive when they stay narrow enough to be genuinely good at one thing, and tend to accumulate cruft or get replaced when they try to cover every case at once.
A worked example: three systems, one protocol
It helps to walk through what this looks like concretely rather than staying at the level of architecture diagrams. Imagine a support agent tasked with resolving a customer complaint: it needs to look up the customer's account in a CRM, check recent orders in a commerce platform, and, if a refund is warranted, create a record in a finance system. Built the old way, this is three separate SDKs, three separate authentication flows, three separate sets of error handling, and three separate places where a change to any underlying API can silently break the agent until someone notices.
Built against MCP, the same agent connects to three MCP servers, one per system, each maintained by whoever owns that system or by the vendor of it, each exposing its own tools with its own schemas. The agent's host application aggregates all three tool lists into what the model sees, and the model reasons about which tool to call without needing to know or care that the three servers are implemented differently, hosted differently, or maintained by different teams. When the commerce platform ships a new API version, the fix happens once, in that one MCP server, and every agent connected to it benefits without any of them needing a code change on their side. That is the entire value proposition condensed into one scenario: the integration work moves from being repeated by every consumer to being done once by the producer.
Server-initiated requests: sampling and elicitation
Most descriptions of MCP focus on the client calling the server, but the protocol also supports requests running the other direction, and this part is less well known despite being one of its more interesting design choices. A server can ask the connected client to run a model completion on its behalf, a capability called sampling, which lets a server use the host's model access to do its own reasoning without needing its own API key or its own model integration. A server can also ask the client to collect additional input from the user mid-task, called elicitation, when it discovers partway through a tool call that it needs a piece of information nobody provided up front.
Both of these invert the usual request direction in a way that is genuinely useful. A documentation search server, for instance, might use sampling to have the connected model summarize or re-rank a large set of results before returning just the useful ones, borrowing the host's model rather than shipping its own. An MCP server for a booking system might use elicitation to ask the user directly which of several ambiguous matches they meant, rather than guessing or pushing that ambiguity back up as an error for the calling agent to somehow resolve. Both features exist because the protocol's designers recognized early that a purely one-directional client-to-server model would not cover everything a real integration needs, and building the reverse direction into the spec early avoided a much messier retrofit later.
Discovery: how an agent finds out what exists
Protocols solve the shape of communication, but a system still needs to know what is out there to communicate with, and discovery is the part of this story that is least settled. In the simplest setups, discovery is just configuration: a developer lists the MCP servers or A2A agent cards their application should connect to, the same way a developer today lists API keys and base URLs for the services they integrate with by hand. That works fine at small scale and is, in practice, how most MCP deployments work today.
The more ambitious version of discovery, an agent finding and vetting new tools or other agents at runtime without a human pre-approving each one, is genuinely useful for some use cases and genuinely dangerous for others, and the tension between those two facts is unresolved. An agent that can discover and start using a new capability on its own is more adaptable, but it is also an agent that can be pointed at something malicious by whatever mechanism it used to discover that capability in the first place, whether that is a poisoned registry entry, a spoofed agent card, or a search result crafted to look like a legitimate tool. Registries and marketplaces for both MCP servers and A2A agents are emerging to address the cataloguing half of this problem, but the trust half, verifying that a discovered capability is what it claims to be and safe to use, is still mostly solved by curation and reputation rather than anything cryptographically enforced, and that is a real gap in the current state of the art.
The security surface a protocol opens up
Standardizing how agents connect to tools and to each other does not remove risk; it relocates and often concentrates it. When every integration was bespoke, an attacker who wanted to compromise an agent's tool access had to understand that specific, custom integration. When integrations run over a common protocol, an attacker who finds a weakness in how a host implements that protocol, or in how a widely used server implements it, potentially has a foothold against every agent that connects to it. Popularity and standardization are a security asset in that they concentrate scrutiny, and a security liability in that they concentrate blast radius, and both of those things are true at once.
The most discussed version of this risk is prompt injection carried through content that was never meant to be an instruction. An MCP resource that returns a document, or a tool that returns a search result, can contain text crafted to look like an instruction to the model reading it, and a model that cannot reliably distinguish data from instructions may act on injected text as though the user had said it. This risk existed before MCP, wherever a model reads untrusted content, but a protocol that makes it trivially easy to wire a model up to dozens of external data sources also makes it trivially easy to widen the model's exposure to content nobody has vetted, and the convenience that makes the protocol valuable is the same convenience that makes this risk easier to walk into by default.
A related and less discussed risk sits at the server level rather than the content level: a malicious or compromised MCP server can describe its tools honestly during the handshake and then behave differently once trusted, or can use a tool description crafted to manipulate the model's behavior rather than merely to inform it, sometimes called a tool poisoning attack. Because the client typically trusts a connected server's self-reported capabilities, a server is in a strong position to influence the model simply through how it describes what it offers, without ever needing to exploit a bug.
Standardizing how agents connect does not remove risk; it relocates it, concentrating both the scrutiny and the blast radius in the same place.
Permissions, consent, and the confused deputy problem
Protocols also surface, in a sharper form than before, a classic security puzzle called the confused deputy problem: a system with more privilege than the party it is acting on behalf of can be tricked into misusing that privilege.
Permissions, consent, and the confused deputy problem
Protocols also surface, in a sharper form than before, a classic security puzzle called the confused deputy problem: a system with more privilege than the party it is acting on behalf of can be tricked into misusing that privilege. An agent connected to an MCP server for, say, a company's ticketing system typically authenticates with real credentials, its own or a delegated token, and then acts on instructions that ultimately trace back to whatever content the model has read, including content from sources nobody explicitly trusted. If injected instructions can steer the agent into calling a tool with elevated privilege, the agent has been turned into a deputy confused about whose instructions it is actually following.
The mitigations are the same ones that apply to any agent with consequential tool access, but a standardized protocol makes it easier to apply them consistently rather than reinventing them per integration. Scope credentials as narrowly as the task allows, so a compromised or confused call has limited room to do damage. Require explicit confirmation for actions that are costly or hard to reverse, regardless of which server or protocol the call is routed through. Treat content coming back from any resource or tool as untrusted input to be reasoned about carefully rather than as instructions to be obeyed, and prefer clients and hosts that make this distinction explicit rather than leaving it to the model's judgment alone. None of this is unique to MCP or A2A, but a common protocol is exactly the kind of chokepoint where these protections can be built once, into the client and host layer, rather than left to whichever integration happened to remember to add them.
Versioning and the cost of a shared contract
A protocol used by many independent parties creates a coordination cost that a bespoke integration never had to pay: nobody can change the contract unilaterally without breaking someone else. MCP and A2A both version their specifications and both have had to make backward-incompatible changes as real usage revealed gaps in the original design, which is normal for a young protocol but worth planning around rather than being surprised by.
The practical implication for anyone building against these protocols is to treat the protocol version the same way you would treat a public API version: pin to a known version, watch the changelog, and budget time for migrations when a breaking version ships, rather than assuming a shared standard means you can ignore compatibility the way you might with an internal-only integration. The upside that makes this worth it is that the coordination cost is paid once, centrally, by the protocol maintainers and the community tracking the spec, rather than separately by every pair of systems that would otherwise have needed their own negotiated contract and their own migration whenever either side changed.
Testing and observability across a protocol boundary
Debugging an agent that spans several MCP servers or delegates to other agents over A2A introduces a wrinkle that a monolithic, hand-rolled integration did not have: the trace of what happened is now split across process and often organizational boundaries. When a task fails, you need to know whether it failed because the model chose the wrong tool, because a server returned bad data, because a network call timed out, or because a downstream agent misinterpreted a delegated task, and each of those points to a different place to look and often a different team to talk to.
The practical fix is the same discipline that distributed systems have needed for years, applied to this new context: propagate a request identifier across every hop, log the full exchange at each protocol boundary rather than only at the edges of your own system, and build tooling that can reconstruct the whole chain of calls for a single task rather than only the piece that happened inside your own process. Several MCP client implementations now ship an inspector or proxy mode specifically for this, letting a developer watch the raw protocol traffic between host and server while debugging, and treating that visibility as a first-class requirement rather than an afterthought is the difference between a debuggable multi-server agent and one where a failure sends you guessing across three codebases you do not own.
Debugging a multi-server agent means treating protocol traffic like any other distributed system: trace every hop, log at every boundary.
Local versus remote servers: a practical trade-off
MCP's support for both a local, subprocess-based transport and a remote, HTTP-based one is not just a technical detail; it reflects a real trade-off worth thinking through when you decide how to expose or consume a capability. A local server, launched as a subprocess and communicating over standard input and output, runs with the same permissions and on the same machine as the host application, which makes it fast, avoids network dependencies, and is a natural fit for tools that need direct file system or local resource access, at the cost of needing to be installed and run wherever the host runs.
A remote server, reached over HTTP, centralizes maintenance, since the operator can update it without every client needing to reinstall anything, and it is the natural fit for anything backed by a hosted service or shared data store. It introduces network latency and availability as real concerns, and it introduces a genuine question of trust: a remote server operated by a third party sees every request you send it, which is a different risk profile than a local process you control end to end. Neither shape is strictly better; a team exposing internal developer tools will usually reach for local servers first, while a team offering a product to external agents will usually need a remote one, and a mature deployment often ends up with a mix of both depending on what each specific server needs to do and who needs to reach it.
How this fits with existing agent frameworks
It is worth placing MCP against the agent frameworks and orchestration libraries that were already popular before it arrived, because the relationship between them is complementary rather than competitive, and that distinction is easy to muddle. A framework for building agents typically handles the loop: how the model is prompted, how a plan is formed, how state is tracked across steps, how retries and fallbacks are handled when something goes wrong. MCP does not touch any of that. It only standardizes the connection between the agent, wherever its loop is implemented and whatever framework runs it, and the tools and data sources sitting outside that loop.
In practice, this means a team using an existing orchestration framework does not have to choose between that framework and MCP; the natural pattern is to keep the framework for the parts it is good at, planning, state management, retries, and use an MCP client inside it to reach external capabilities instead of hand-rolling a tool integration layer. Most of the popular frameworks added MCP client support fairly quickly after the protocol's release precisely because it slotted into a gap they already had, a standard way to reach tools, rather than displacing anything the framework itself was responsible for. The comparison that sometimes comes up, MCP versus a given framework's own tool-calling abstraction, is really a comparison between a connection protocol and a control-flow library, and the two are not answering the same question.
Where friction does show up is in frameworks that had already built their own plugin ecosystems before MCP existed, with their own conventions for describing and registering tools. Those ecosystems now typically maintain both their native plugin format and an MCP bridge, so existing plugins keep working while new integrations can be written once, as MCP servers, and used across frameworks rather than being locked into one framework's plugin format. That transition period, maintaining two integration surfaces at once, is a real cost, but it is the same cost every ecosystem pays when a shared standard arrives after proprietary conventions are already established, and it is usually worth paying once rather than indefinitely maintaining fragmented, framework-specific integrations for the same underlying capability.
What adoption looks like away from the demo
It is worth being honest about where this stands today rather than where the pitch decks say it is heading. MCP adoption has moved fast for tool connectivity: a real and growing set of servers exist for common developer tools, data platforms, and productivity systems, and a real and growing set of host applications, coding assistants, general-purpose agent frameworks, desktop AI applications, speak the protocol natively. For the specific job of connecting an agent to tools and data without writing a custom adapter for each one, MCP has become close to a default choice in new work.
A2A and agent-to-agent interoperability more broadly are earlier in that curve. The protocol solves a real problem, and there is genuine momentum behind it, but the ecosystem of independently built agents that actually discover and collaborate with each other across organizational boundaries, the scenario the protocol is ultimately aimed at, is still mostly a promise rather than a widespread practice. Most production systems today that use multiple agents built them all in-house, under one team's control, which sidesteps most of the reasons a cross-organization protocol like A2A exists in the first place. That will likely change as more organizations expose agents as products rather than internal tools, but it has not changed yet at scale, and it is worth treating agent-to-agent interoperability as a promising but still-maturing piece of infrastructure rather than a solved problem.
The case against standardizing too early
None of this is an argument that every agent should rush to adopt every emerging protocol. Standardizing on a young specification carries its own cost: you inherit its bugs, its breaking changes, and its gaps, and you inherit them earlier than someone who waits for the ecosystem to settle. For a project connecting to two or three well-known tools it fully controls, a bespoke integration is still simpler to build, easier to reason about, and has fewer moving parts than pulling in a protocol implementation, its transport layer, and its evolving spec.
The judgment call is the same one that applies to most infrastructure decisions: standardize when the number of things you need to connect to, or the number of parties who need to connect to you, is large enough or growing fast enough that bespoke integration work would dominate your engineering time. An internal tool with one caller and one callee does not need a protocol. A capability you want any agent, including ones you have never met and will never coordinate with directly, to be able to use, is exactly the case a protocol is built for. Reach for MCP or A2A because the shape of your problem is the N-times-M problem they were built to solve, not because the protocol is the thing everyone is currently talking about.
Standardize when the number of parties you need to connect to is genuinely large. Otherwise a bespoke integration is still the simpler engineering.
Getting started without over-engineering it
For a team deciding whether to adopt any of this, the pragmatic path is narrower than the surrounding discourse suggests. Start by wrapping the two or three external systems your agent already struggles to reach cleanly, the ones where you have felt the pain of a brittle, hand-rolled integration breaking on a silent upstream change. Stand up or install an MCP server for each, connect your host application's client, and see whether the aggregated tool list actually improves what your agent can do, rather than adopting the protocol on faith because it is the thing being discussed everywhere.
Resist the urge to build your own MCP server for something an existing one already covers well; the value of a shared protocol evaporates if everyone still writes their own version of the same integration rather than converging on a common one. Check the growing catalogues of published servers before writing a new one, the same way you would check for an existing library before writing your own HTTP client. And when you do need a custom server, because your data or your system is genuinely proprietary, keep its tool surface small and specific rather than trying to expose everything the underlying system can do; a server with five well-described tools that map to real tasks is more useful to a model, and safer to operate, than one with fifty that mirror an internal API one-for-one.
Hold off on A2A until you have a concrete reason a single agent, or a set of agents you fully control, cannot do the job. The protocol earns its keep at organizational boundaries, when you are exposing an agent to callers you do not manage or calling into one you do not own, and most teams are not yet at that boundary even when their internal architecture already has multiple agents talking to each other. Building against A2A before you have that boundary mostly buys you the protocol's overhead without its benefit, since a single team can coordinate an interface far more cheaply through ordinary internal APIs than through a protocol designed for parties who have never met.
Adopt a protocol because your integration problem has grown into the shape it solves, not because it is the infrastructure everyone happens to be discussing this quarter.
Where this goes next
The trajectory here rhymes with earlier waves of infrastructure standardization, and it is reasonable to expect the same broad arc: rapid, somewhat messy proliferation of competing approaches, gradual convergence around the ones that solve real problems well, and eventually infrastructure so assumed that nobody discusses it directly anymore, the way nobody today writes a blog post celebrating that TCP/IP exists. MCP and A2A are not guaranteed to be the protocols that win that convergence in their current form, but the underlying problems they address, letting agents reach tools without bespoke glue and letting agents collaborate across organizational boundaries without shared internals, are not going away, and something will end up filling that role.
What is worth watching in the near term is less the protocols' internal design, which will keep evolving, and more the trust and security layer around them, which is genuinely unsolved. Verified server and agent identity, standardized permission scoping that a client can enforce rather than merely request, and mechanisms to establish provenance for the content flowing through these connections are the pieces still missing, and they matter more than any feature addition to the core message formats. A protocol that makes integration effortless without making trust legible is a protocol that will eventually produce a security incident dramatic enough to slow its own adoption, and the teams building the next layer of this infrastructure know that, which is where a large share of current protocol development energy is actually going, even if it gets less attention than the connectivity story that made these protocols famous in the first place.
For a team building agents today, the practical takeaway is simple even if the underlying landscape is still moving. Prefer a standard protocol over a bespoke integration once you are connecting to more than a couple of tools or once you want your own capability reachable by agents you do not control. Treat any content that arrives through that protocol, from a resource, a tool result, or another agent's response, as untrusted input rather than as instruction, no matter how convenient the connection was to set up. And keep the actual judgment about what to standardize on grounded in the shape of your integration problem rather than in which protocol has the most attention this quarter, because the protocols that last are the ones solving a real N-times-M problem, and the ones that fade are the ones solving a problem that was never actually that big to begin with.