MCP vs ANP: What Kind of Communication Protocol Do Agents Need
作者:常高伟
Core points:
- Building consumer-facing personal assistants faces rapidly diminishing reasoning capability bottlenecks, but two challenges remain: cost and information acquisition. Agent communication protocols are needed to solve how AI can access all necessary information.
- Currently, the most comprehensive open-source communication protocols for agents or AI are Anthropic’s MCP and our ANP.
- MCP and ANP differ significantly in three aspects: protocol architecture, identity authentication, and information organization.
Core Differences Between MCP and ANP
- MCP uses a typical Client-Server (CS) architecture, while ANP uses a typical Peer-to-Peer (P2P) architecture.
- MCP’s identity authentication is based on the OAuth standard, making it easy for clients to access current internet resources; ANP’s identity authentication is based on the W3C DID standard, focusing on cross-platform interoperability between agents to ensure all agents can connect.
- MCP’s information organization is based on JSON-RPC technology, essentially API calls; ANP’s information organization is based on the Semantic Web’s Linked-Data technology, aiming to build a data network that’s easy for AI to access and understand.
Worldview Differences
The biggest difference between MCP and ANP lies in their worldview:
- MCP is Model-Centric, with the entire internet serving as its context and tools.
- ANP is Agent-Centric, where each agent has equal status, forming a decentralized agent collaboration network.
What kind of communication protocol agents need depends on the characteristics of the future Agentic web. On this point, our view differs from MCP’s, and we will continue to invest firmly in ANP’s development.
Why Agent Communication Protocols Matter
With the launch of Deepseek R1, OpenAI O3 Mini, and Deep Research, we can observe a clear trend: the core bottleneck limiting agent construction—complex task reasoning ability—is rapidly disappearing.
Deep Research can essentially be considered a personal assistant for knowledge workers.
Building consumer-facing agents still faces two bottlenecks. One is cost, which is expected to decrease by one or two orders of magnitude in 2025. The other is information: how can consumer-facing personal assistants obtain sufficient information?
Information for knowledge workers is often stored in open databases or websites, making it very accessible to AI. Consumer-facing information is much more complex and, limited by the current internet’s data silo phenomenon, is highly fragmented with poor openness.
How to enable consumer-facing personal assistants to conveniently and efficiently obtain the information consumers need (tool capabilities can also be understood as a type of information) is the problem that agent communication protocols aim to solve.
Introduction to MCP and ANP
MCP (Model Context Protocol)
The Model Context Protocol (MCP) is an open protocol that enables LLM applications to seamlessly integrate with external data sources and tools. Whether building AI-driven IDEs, enhancing chat interfaces, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.
AgentNetworkProtocol (ANP)
AgentNetworkProtocol (ANP) is an open protocol framework designed for the Agentic Web. ANP implements decentralized identity authentication, allowing any two agents to connect. It also defines an agent description specification that enables more efficient data exchange and collaboration between agents.
In the current field of agent communication protocols, besides MCP, our ANP is perhaps the most comprehensive open-source project. ANP may be the earliest open-source communication protocol for agents released online. We first published the code with the protocol in Feishu documents, and later migrated the protocol to GitHub.
If you know of other good open-source projects, please feel free to introduce them to me.
Differences Between MCP and ANP
Below, I will elaborate on the differences between MCP and ANP from three aspects: protocol architecture, identity authentication, and information organization, followed by a discussion of differences in design philosophy and why these differences exist.
Protocol Architecture: CS vs P2P
MCP Protocol Architecture
MCP is a typical Client-Server architecture, where clients connect to the MCP Server using the MCP protocol and then use the protocol to access various information and tool capabilities of the Server.
MCP’s Client-Server Architecture
Clients and Servers establish bidirectional communication links through stdio or http. When using http, the Client sends messages using http post and receives server event notifications using http SSE.
MCP’s Communication Flow
ANP Protocol Architecture
ANP is a typical P2P (peer-to-peer) architecture, meaning any agent can use ANP to connect to another agent.
ANP’s Peer-to-Peer Architecture
ANP currently uses HTTP at the underlying layer. An agent can both use HTTP to connect to other agents and receive messages from other agents via HTTP. Of course, websocket and private transport layer protocols are theoretically also supported.
The main reason ANP chose to use P2P architecture is to allow agents to both actively initiate requests to other agents and receive requests from other agents at any time.
When MCP uses CS architecture, if the client is not connected to the server, the server cannot send messages to the client. Of course, if a client can also act as a server, then MCP could be viewed as a P2P architecture, though it might seem somewhat awkward.
True P2P architecture requires not just P2P physical connections, but also P2P roles and positioning—this is the core of P2P.
Identity Authentication: OAuth vs DID
Identity authentication is a key part of agent communication protocols and also the most challenging part. It needs to solve a difficult problem: how agents can authenticate across platforms. Only this way can agents collaborate with all other agents.
MCP Identity Authentication
When MCP was first released, it did not support identity authentication, making it inconvenient to connect to remote servers. The latest draft version now supports authentication between clients and servers.
MCP’s identity authentication scheme is technically centered on the OAuth2 standard.
OAuth is an open standard authorization framework designed to provide a secure, convenient, and flexible way for accessing user resources, enabling third-party applications to access user resources stored with another service provider with user authorization, without needing to obtain sensitive information like usernames and passwords. Our common practice of logging into third-party applications using Google or WeChat accounts is based on OAuth technology, which is widely applied on the internet.
The protocol draft released by MCP is the community’s second version, with the following improvements over the first version:
- Uses OAuth 2.1 (still in draft status), simplifying the protocol and enhancing security
- Supports authorization server discovery using the OAuth 2.0 Authorization Server Metadata Protocol, allowing clients to automatically discover and obtain relevant configuration information from the authorization server, such as authorization endpoints, token endpoints, supported authorization types, encryption algorithms, etc.
- Supports OAuth 2.0 Dynamic Client Registration Protocol (DCR), allowing clients to automatically register with the server without requiring manual login to the server first. This simplifies the cost of client integration with servers.
MCP’s OAuth Authentication Flow
ANP Identity Authentication
ANP’s identity authentication scheme is technically centered on the W3C DID specification.
The W3C DIDs standard was published as a W3C Recommendation in 2022 and is a new type of identifier that supports verifiable, decentralized digital identity. Based on DIDs, users can truly control their own identity, and it can also improve interoperability between different applications.
Many applications are already using the W3C DID specification, with a notable example being the recently popular Bluesky, whose underlying AT Protocol uses W3C DID as its identity authentication scheme.
ANP’s DID Authentication Flow
The biggest benefit of using DID as an identity authentication technology is identity interoperability. Agents on different platforms can authenticate each other using DID without requiring them to all use an account from one platform or to register with each other.
This is because DID is inherently designed for decentralized identity.
Articles related to ANP DID identity authentication:
Comparing MCP and ANP authentication, we can find several differences:
- MCP’s authentication scheme is a good choice for AI to connect to the existing internet, as many major applications currently support OAuth.
- ANP’s DID technology is a relatively new specification, not as widely adopted as OAuth. Applications need to modify their code to support it.
- OAuth solves how models can access user resources on existing internet applications. DID solves how agents on different platforms can authenticate each other.
From an interoperability perspective alone, DID-based schemes are simpler and require fewer interactions than OAuth-based schemes:
- OAuth requires clients to register an ID with the server, while DID allows direct interaction using one’s own ID, eliminating the registration process and the management cost of different server-generated IDs.
- During the authentication process, DID has fewer interactions and can achieve 0-RTT (zero round-trip time, carrying identity verification information in the first business request). OAuth requires multiple interactions.
The fundamental reason is that OAuth was not specifically designed for identity interoperability. DID, on the other hand, is inherently a decentralized identity technology, making it more friendly to interoperability.
Regarding agent identity, there are still many challenging issues that need continuous solutions:
- How to ensure both user privacy protection and necessary identity information acquisition during cross-platform authentication?
- How to achieve more fine-grained permission control for users, rather than using a single ID to communicate with all agents?
- How to determine whether an agent’s request has been manually authorized by the user? Agents should not have the authority to initiate certain sensitive operations on their own.
- How to let users fully control their identity ownership, rather than using permissions granted by platforms?
These new issues might be easier to solve based on W3C DID. We already have preliminary solutions for many problems and will gradually refine and release them.
Information Organization: RPC vs Linked-Data
MCP and ANP use different technologies for organizing information output from agents.
MCP Information Organization
MCP uses JSON-RPC to read/manipulate server resources and tool capabilities. JSON-RPC (JavaScript Object Notation - Remote Procedure Call) is a remote procedure call protocol based on JSON format. It allows clients to call methods on remote servers and receive JSON results.
Using MCP, servers can list all resources or tools, then read specific resources or call specific tools. Clients can also subscribe to resources, with the server actively notifying the client when resource states change.
The format of resources or tools is server-defined, with models deciding which resources and tools to read and operate.
The way MCP servers provide information output can essentially be understood as a special type of API.
ANP Information Organization
ANP uses the Semantic Web’s Linked-Data technology as the core for organizing information output from agents.
Linked Data is a technology for structured data sharing and interconnection, based on Web standards (such as RDF, SPARQL, URI), aimed at connecting data from different sources through unique identifiers (URIs), making it machine-readable and semantically understandable.
In implementation, we defined an agent description specification for describing agent identity, capabilities, entity information, API interfaces, etc.
ANP’s Linked Data Network
Agent description documents use the JSON-LD format, which is a Linked Data format based on JSON that can link different data into a data network while being machine-understandable.
For example, a coffee shop’s agent description document describes the coffee shop’s name, owner, location, working hours, etc., and also contains URLs for multiple products for sale. Through these URLs, AI can continue to access the JSON-LD documents of products to get detailed product information. Similarly, the detailed product information may also contain new JSON-LD URLs.
This way, as long as there is an agent description document, all public information exposed by the agent can be obtained. This can build a new data network linked together with JSON-LD, easy for AI to access. Corresponding to our existing internet linked together by web pages designed for human access, there will eventually be two networks: one designed for human access and another designed for AI access.
Besides data connection, Linked Data technology has another core feature: semantic understanding. Our designed JSON-LD documents use schema.org as the semantic foundation. Schema.org defines a set of semantic models for describing the modern Web, allowing two agents to have the same understanding of the same field, enhancing the accuracy of information understanding between agents, while also facilitating program processing.
Using Linked Data technology, agents’ public information can be easily crawled by search engines. Users can quickly find agents that provide services through search engines, and then interact and collaborate with agents based on agent description documents.
Compared to MCP’s information organization, ANP’s semantic web-based approach inherits the openness of Web architecture. Search engines can index agents’ public information, and agents can efficiently retrieve information using search engines, then directly connect to other agents.
Differences in Design Philosophy
Above are the differences between MCP and ANP in design details.
To summarize more abstractly, the biggest difference between MCP and ANP lies in their worldview:
- MCP is Model-Centric, with the entire internet serving as its context and tools.
- ANP is Agent-Centric, where each agent has equal status, forming a decentralized agent collaboration network.
Worldview Differences Between MCP and ANP
Why this difference?
Mainly because MCP and ANP have different purposes.
Strictly speaking, MCP is not a communication protocol for agents. As its name suggests, it’s a model context protocol, designed to provide context capabilities for models, making it easier for models to access the current internet and enrich Chatbot product capabilities.
When designing ANP, we didn’t have our own product; we directly based it on the future, designing ANP based on our understanding of the future Agentic web. Our goal is to build a new agent network that can fully unleash AI capabilities.
What Kind of Communication Protocol Do Agents Need
We believe MCP is an excellent protocol and the optimal solution for models to access the internet currently, more viable than the Computer Use approach. Anthropic has used their influence to show the industry the advantages of this approach.
However, we believe MCP might be a transitional form, the optimal solution for AI to access the internet right now. If the internet changes significantly due to agents, MCP may not remain the optimal solution.
So, what kind of communication protocol agents need depends on the characteristics of the future Agentic web. We’ve summarized several points (for details, see this article: What’s Different About the Agentic Web):
- Agents will permeate every corner of the internet, with individuals or organizations potentially having multiple agents serving them
- All agents should be able to interconnect, which is necessary for unleashing AI capabilities
- Personal assistants will become the new entry point to the internet, with connections between agents far exceeding connections between humans and agents
- The network will become flatter, with agents able to connect directly without third-party platforms
These points form the core foundation of our ANP design.
Of course, MCP may also evolve and iterate, which we welcome. No organization or individual can independently complete such an important industry standard, including us. We are willing to cooperate with everyone in the industry.
Common Questions
Regarding the relationship with MCP, people often ask several questions:
- Why create ANP when MCP already exists: When we created ANP, MCP had not yet been released. Strictly speaking, we should be the first open-source communication protocol for agents, and our release was earlier.
- Why continue with ANP after MCP’s release: Because we have different views about the future.