MCP and A2A: Two bright modular futures for AI

To say that AI is a field undergoing rapid innovation and expansion would be an extreme understatement. In recent years it's been hard to keep up with the deluge of new models, capabilities, and tools. At the moment there are perhaps fewer brighter rising stars than a pair of new open standards for AI development.

In this article we'll introduce and explore the concepts of model context protocol (MCP) servers and the Agent2Agent (A2A) protocol, compare and contrast the two approaches, and help you determine what's right for you and your team.

Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open protocol that seeks to standardize the tools and capabilities that AI systems can rely on. Prior to MCP you could build custom tools into an AI application using tooling like Microsoft Semantic Kernel or LangChain through custom code and connectors. This would allow you to marry together large language models and your own data or custom toolsets.

This approach was effective and helped us build custom retrieval augmentation generation (RAG) solutions like a web chat agent or full-blown AI orchestration solutions like a hobby project I carried out to build an AI-powered dungeon master. However, while these agents were capable, their capabilities were contained within the AI application on its own.

This meant that when new capabilities like developer AI chat plugins or web chat portals began offering new places and new ways for your team to interact with AI, your systems couldn't easily integrate with them.

Model Context Protocol solves this problem by separating the custom capabilities from the chat plugin and LLM. Instead of building a pipeline for processing messages that adds in tooling, MCP focuses on exposing tooling in a modular way that can be referenced by any number of other AI systems.

This means that developers can build a MCP server and connect their IDE chat plugins, web chat portal, and even future systems like OS or browser-level AI agents to the same MCP server.

What this ultimately gets you is efficiency and modularity as developers can focus their efforts on the specific capbilities they're trying to author versus the end-to-end experience (though this is still an important facet to consider in overall systems design). As a result, your AI systems and resources are more flexible to changes in tooling and changes in the LLMs they're connected to.

What's on an MCP Server?

MCP systems consist of a MCP client and an MCP server. The MCP client is typically integrated into the conversational AI interface a user is using to start the conversation, so it doesn't contain much logic of its own.

The MCP server, on the other hand, is what contains all of the custom logic to provide additional capabilities. MCP servers can contain the following types of resources:

• Tools - functions that an AI system can invoke to accomplish a specific task.
• Resources - Catalogued resources such as files, documents, or database records
• Prompts - pre-defined interaction templates governing common interaction scenarios

When you author a MCP server, you provide a way of advertising what capabilities your MCP server has, ways of retrieving prompts and resources, and ways of executing the specified tools. This is done in a flexible manner, which allows your server to dynamically discover and advertise resources, so resources can change based on new files, database entries, or external API results.

While I currently strongly encourage teams to consider MCP when authoring AI applications, that doesn't mean there's no longer a place for AI orchestration libraries like Semantic Kernel. These frameworks offer a great place to offer highly controlled AI experiences with a pre-defined set of capabilites. In fact, Semantic Kernel recently added direct integration with MCP servers, so you can migrate existing SK apps to use MCP servers or you can expose many of these systems capabilities through an MCP server while keeping the existing application in place.

Deploying MCP Servers

The final note about MCP servers I want to cover is that they are typically installed locally at the moment. Although there are protocols for remote MCP servers that can be addressed via URLs, a more common approach at the moment is for MCP servers to be installed and configured locally for people using MCP servers and then these local MCP servers call out to external resources as needed.

This is done to keep authentication logic out of the MCP client layer since your specific chat agent should not need to know how to authenticate with Azure's MCP server, GitHub's MCP server, and your team's MCP server. Instead, we deploy MCP servers locally and provide configuration to that specific server for how it should authenticate to get its remote resources.

Remote MCP servers will likely increase in popularity as the protocol matures to standardize the authentication process, but for now the recommendation is to use small custom MCP servers that run locally and connect to an API that your team controls using whatever authentication mechanism your team prefers.

With MCP covered, let's turn our attention now to Agent-to-agent (A2A).

Agent2Agent (A2A)

Agent2Agent (A2A) is an open protocol that's emerged recently from Google that allows AI agents to communicate with each other in a standardized process.

While MCP focuses on exposing modular capabilities, A2A focuses on providing a standard protocol for interacting with the entire AI agent, including its prompts, resources, tools, and model selection.

In this way, you can think of MCP as a toolbox - exposing tools and capabilities in a standardized way - while A2A is more of a standardized way of finding a mechanic who might be able to solve your problems using the tools at their disposal.

This standardization of inter-agent communications allows for more complex scenarios where agents can be authored to solve specific tasks and other agents can coordinate between these agents to handle complex requests.

Think of A2A as a way for other AI agents to "phone a friend" if they find they don't have a sufficient amount of information or capabilities to fulfill a request.

Using A2A you can author a series of AI agents and connect them to each other, or author a single agent that is able to call out to specialized third-party agents from trusted vendors you've selected.

Like MCP with its MCP client and MCP servers, A2A also uses an A2A client and A2A server architecture. However, A2A represents its work as tasks and its interactions as messages comprised of multiple parts that are designed to produce one or more artifacts representing deliverables to be returned to the calling agent.

Overall, A2A allows for a more modular and open AI ecosystem while providing support for new interaction scenarios.

Should you choose MCP or A2A?

While both A2A and MCP exist to provide more modular AI systems, these are not conflicting technologies.

It is entirely feasible to create an AI agent that connects to a series of capabilities using MCP to accomplish its tasks and uses A2A to request help for tasks its not capable of handling on its own.

At the moment my general advice to organizations is to embrace MCP if they want to provide custom capabilities for AI agents that could integrate into different user interfaces such as developer IDE chatbots and web chat portals. Designing with MCP in mind opens up new options for organizations as AI tooling evolves and becomes available in more places.

While A2A is a newer protocol, I encourage organizations to consider A2A as a consumer when there are complex interaction scenarios they want to support but don't want to provide a custom solution to handle.

Alternatively, organizations may find themselves in a position where they have specialized capabilities they want to offer to other organizations. In these cases it may make sense to use A2A to share your own agents with external callers so they can integrate them into their own AI solutions.

Conclusion

Both MCP and A2A are open protocols that are gaining broad popularity and support, most recently in the form of Microsoft pledging support of both MCP and A2A protocols in their offerings going forward.

In a rapidly evolving AI ecosystem it makes sense for standards to emerge for defining the ways in which AI systems can connect to capabilities and the ways in which AI systems can interact with each other.

I, for one, welcome our new more modular and interchangeable AI assistants.