MCP and ACP: Decoding the language of models and agents

Anthropic's Model Content Protocol (MCP) is making waves in the AI development community thanks to a massive boost in attention and adoption recently that is starting to cement its status as an open standard. With our recent launch of AGNTCY, an open source collective focused on inter-agent collaboration, and the subsequent code drop of our Agent Connect Protocol (ACP), we've been getting questions about how ACP relates to MCP.

We're happy to break it all down for you and show you not only how they interact, but also how they can work together to enrich agents and scale your systems.

If you’re trying to decide between enriching a model or orchestrating agents—MCP and ACP are great protocols. They sound similar, but they’re built for totally different jobs. One’s for giving context to a model; the other is for letting agents collaborate at scale.  

TL;DR: MCP is about providing context to a model, while ACP is about communication between agents. If you are in control of your model and context when building agents—just use a framework. If you are not in control of your model or context and want to scale agents with more context and tools use MCP. If you have built agents with defined purposes and want them to interoperate at scale use ACP.  

The Model Context Protocol (MCP) and Agent Connect Protocol (ACP) serve distinct purposes within AI and multi-agent systems: 

• MCP is tailored for enriching individual AI models with external context (data or agents) to enhance their decision-making and response generation. It focuses on adding context easily and is primarily useful when an AI model needs access to external data sources not under your control. If used with agents as context the call path is a tool call which limits the relationship between agents. 
• ACP, on the other hand, enables autonomous agents to collaborate and share resources in a distributed system. It focuses on agent communication and collaboration, ensuring that agents can interact and solve problems cooperatively. The relationship between agents is not limited to tool calling.  

Both protocols are valuable in different contexts, and while MCP enhances the capabilities of AI models by providing access to external context, ACP focuses on collaboration among agents. 

The choice between MCP and ACP ultimately depends on whether the system you are building requires an enhanced model or scaling collaboration among multiple autonomous agents. 

A simple way to look at it is—if you are building an agent (or a very contained multi-agent process/system) and you are in control of the model and tools, you can use a framework alone (Langgraph, llamaindex). If you are building an agent and you don’t control the model or the tools, you need a protocol to connect them and MCP is good for that. If you are building a system of agents and you don't control them, you need a protocol, and ACP is good for that. 

Containment versus messaging 

With MCP, a model can be augmented with external context, which could include data or capabilities from another system (or potentially another agent). The external content is obtained by a direct client server interface to allow for a common interface to the context. 

With ACP agents exchange messages via restful APIs to produce a result. 

The analogy can be compared to programming, where objects can contain attributes (containment) that enhance or define their behavior—similar to how an agent in MCP "contains" (albeit remotely) the context or capabilities of another agent. However, this differs from how programming uses message calls, where objects communicate by invoking methods on each other. 

In MCP, the external context could be an attribute of the agent that enhances the model. In ACP, agents exchange messages to collaborate and perform. The key distinction is that MCP focuses on adding context to a model (containment) to ultimately build an agent, whereas ACP is about collaboration between agents (message passing). 

When to use MCP, ACP 

MCP at its core gives large language models (LLMs) and agents access to prompts, resources, and tools in a standardized way. It's a technique that builds upon the concept of tool calling as a way to provide context to LLMs. These services are listed within an MCP server. MCP clients (LLM, agents) can then search for and consume these resources as needed via the MCP protocol, connecting the clients to the servers.  

ACP defines an interface, in the form of REST endpoints, that define how to interact with agents in a standardized way. It defines endpoints for retrieving agentic workflows which can be run on this agent, it defines endpoints for creating and getting context threads, and it defines endpoints for running the agent. It is primarily focused on standardized multi-agent interactions which preserve state context via threads. Each agent which implements ACP could also be an MCP client/host to connect to data. 

Given an AgentA and an AgentB, if AgentB is purely a source of information for AgentA to use, then MCP could replace the ACP communication channel completely. But, if AgentA and AgentB, collaborate and reason together, then ACP should be used. 

Integration benefits 

Enhanced data access: MCP can provide AI models with context from various data sources, while ACP can facilitate communication between agents, allowing them to share and utilize this context effectively 

Improved collaboration: ACP enables agents to collaborate and negotiate tasks, and MCP can supply the necessary data and context to make these interactions more informed and efficient 

Unified framework: Using MCP for data integration and ACP for agent communication creates loosely coupled where AI models and agents can operate seamlessly, leveraging both protocols' strengths   

Deployment at scale: Agents as microservices 

As AI agent ecosystems grow, we’ll need strategies for deploying, reusing, and scaling agents effectively. The focus will shift from the individual agent to how agents can be composed and reused at the task level—the “Job to Be Done” (JTBD) reuse level. 

When agents are used (and reused) at this higher level of abstraction, they align more closely with microservices and microservice architecture principles 

A key principle of microservices is encapsulation: each service manages its own state and data independently. No two services should share data directly; instead, they interact through well-defined APIs. This loose coupling ensures scalability, maintainability, and resilience. 

When designing agent-based systems, agents should be: 

1. Loosely coupled: Agents interact via well-defined protocols, minimizing dependencies and maximizing flexibility. 

2. Highly cohesive: Each agent is self-contained and focused on a single function, making it easier to deploy, scale, and reuse. 

Loose coupling: Enabling scalable agent interactions 

Loose coupling ensures that each agent functions independently, minimizing the impact of changes in one agent on others. This is critical in microservices and equally crucial for agent-based architectures. 

• ACP naturally supports loose coupling by enabling message passing between agents. 
• Each agent maintains its own state, reducing dependencies between agents and promoting scalability. 
• A set of agents communicating to perform a JTBD can be encapsulated as a single agent in a directory, making reuse easier.   

High cohesion: Ensuring reusable agents 

High cohesion means that an agent should be self-contained, with all necessary functionalities and grouped together for a specific purpose. 

• ACP promotes high cohesion by allowing multiple agents to communicate as a logical unit to achieve a JTBD. 
• MCP, on the other hand, tightly couples remote information with an agent’s internal model, requiring persistent state maintenance. 

If the reuse of agents is done with MCP the state of the remote data would be exposed. 

How MCP and ACP impact scaling and reuse 

MCP and ACP in practical deployment 

The difference between “this works” and “this scales like a beast” comes down to choosing the right protocol for the job. 

MCP is ideal for building individual agents that require tight integration with (and repeated access to) external data sources. These components serve as the foundation of an agent and will be limited for scaling.  
 
ACP is better suited for orchestrating and scaling interaction between agents built with MCP. It allows agents to encapsulate their state, be used and composed efficiently at the JTBD level—just like microservices are deployed in scalable architectures. 

By applying microservice best practices to agents, we can ensure that they remain scalable, modular, and reusable. 

• Use MCP for creating deeply integrated stateful agents. 
• Use ACP to enable these agents to scale, communicate, and be reused effectively. 

Ultimately, ACP allows for agent-based architectures at scale, following the same principles that make microservices successful in cloud computing.

Explore the future of MCP and ACP for advanced AI development

When used together, these protocols create powerful, modular AI architectures capable of scaling. 

If you’re exploring AI development or multi-agent systems, there’s no better time to dig deeper into MCP and ACP. As part of AGNTCY's Internet of Agents, we’re building components across the entire multi-agent software development lifecycle: learn more here.