10.1 Agent Communication Protocol Fundamentals

10.1.1 Why Communication Protocols Are Needed

Recall the ReAct agent we built in Chapter 7, which already possesses powerful reasoning and tool invocation capabilities. Let's look at a typical usage scenario:

from hello_agents import ReActAgent, HelloAgentsLLM
from hello_agents.tools import CalculatorTool, SearchTool

llm = HelloAgentsLLM()
agent = ReActAgent(name="AI Assistant", llm=llm)
agent.add_tool(CalculatorTool())
agent.add_tool(SearchTool())

# Agent can complete tasks independently
response = agent.run("Search for the latest AI news and calculate the total market value of related companies")

This agent works well, but it faces three fundamental limitations. First is the tool integration dilemma: Whenever we need to access a new external service (such as GitHub API, database, file system), we must write a specialized Tool class. This is not only labor-intensive, but tools written by different developers cannot be compatible with each other. Second is the capability expansion bottleneck: The agent's capabilities are limited to the predefined tool set and cannot dynamically discover and use new services. Finally is the lack of collaboration: When tasks are complex enough to require multiple specialized agents to collaborate (such as researcher + writer + editor), we can only coordinate their work through manual orchestration.

Let's understand these limitations through a more specific example. Suppose you want to build an intelligent research assistant that needs to:

# Traditional approach: Manually integrate each service
class GitHubTool(BaseTool):
    """Need to manually write GitHub API adapter"""
    def run(self, repo_url):
        # Lots of API calling code...
        pass

class DatabaseTool(BaseTool):
    """Need to manually write database adapter"""
    def run(self, query):
        # Database connection and query code...
        pass

class WeatherTool(BaseTool):
    """Need to manually write weather API adapter"""
    def run(self, location):
        # Weather API calling code...
        pass

# Each new service requires repeating this process
agent.add_tool(GitHubTool())
agent.add_tool(DatabaseTool())
agent.add_tool(WeatherTool())

This approach has obvious problems: code duplication (each tool must handle HTTP requests, error handling, authentication, etc.), difficult to maintain (API changes require modifying all related tools), cannot be reused (tools from other developers cannot be directly used), poor scalability (adding new services requires extensive coding work).

The core value of communication protocols is precisely to solve these problems. It provides a set of standardized interface specifications that allow agents to access various external services in a unified way without needing to write specialized adapters for each service. This is like the Internet's TCP/IP protocol, which allows different devices to communicate with each other without needing to write specialized communication code for each type of device.

With communication protocols, the above code can be simplified to:

from hello_agents.tools import MCPTool

# Connect to MCP server, automatically obtain all tools
mcp_tool = MCPTool()  # Built-in server provides basic tools

# Or connect to professional MCP servers
github_mcp = MCPTool(server_command=["npx", "-y", "@modelcontextprotocol/server-github"])
database_mcp = MCPTool(server_command=["python", "database_mcp_server.py"])

# Agent automatically obtains all capabilities without manually writing adapters
agent.add_tool(mcp_tool)
agent.add_tool(github_mcp)
agent.add_tool(database_mcp)

The changes brought by communication protocols are fundamental: Standardized interfaces allow different services to provide unified access methods, interoperability enables seamless integration of tools from different developers, dynamic discovery allows agents to discover new services and capabilities at runtime, and scalability enables systems to easily add new functional modules.

10.1.2 Comparison of Three Protocol Design Philosophies

Agent communication protocols are not a single solution, but a series of standards designed for different communication scenarios. This chapter uses the three currently mainstream protocols MCP, A2A, and ANP as examples for practice. Below is an overview comparison.

(1) MCP: Bridge Between Agents and Tools

MCP (Model Context Protocol) was proposed by the Anthropic team^[1], and its core design philosophy is to standardize the communication method between agents and external tools/resources. Imagine that your agent needs to access various services such as file systems, databases, GitHub, Slack, etc. The traditional approach is to write specialized adapters for each service, which is not only labor-intensive but also difficult to maintain. MCP defines a unified protocol specification that allows all services to be accessed in the same way.

MCP's design philosophy is "context sharing". It is not just an RPC (Remote Procedure Call) protocol, but more importantly, it allows agents and tools to share rich contextual information. As shown in Figure 10.1, when an agent accesses a code repository, the MCP server can not only provide file content but also provide contextual information such as code structure, dependency relationships, and commit history, enabling the agent to make more intelligent decisions.

Figure 10.1 MCP Design Philosophy

(2) A2A: Dialogue Between Agents

The A2A (Agent-to-Agent Protocol) protocol was proposed by the Google team², and its core design philosophy is to implement peer-to-peer communication between agents. Unlike MCP, which focuses on communication between agents and tools, A2A focuses on how agents collaborate with each other. This design allows agents to engage in dialogue, negotiation, and collaboration like human teams.

A2A's design philosophy is "peer-to-peer communication". As shown in Figure 10.2, in an A2A network, each agent is both a service provider and a service consumer. Agents can actively initiate requests and also respond to requests from other agents. This peer-to-peer design avoids the bottleneck of centralized coordinators, making the agent network more flexible and scalable.

Figure 10.2 A2A Design Philosophy

(3) ANP: Infrastructure for Agent Networks

ANP (Agent Network Protocol) is a conceptual protocol framework³, currently maintained by the open-source community and not yet having a mature ecosystem. Its core design philosophy is to build infrastructure for large-scale agent networks. If MCP solves "how to access tools" and A2A solves "how to dialogue with other agents", then ANP solves "how to discover and connect agents in large-scale networks".

ANP's design philosophy is "decentralized service discovery". In a network containing hundreds or thousands of agents, how can agents find the services they need? As shown in Figure 10.3, ANP provides service registration, discovery, and routing mechanisms, allowing agents to dynamically discover other services in the network without needing to pre-configure all connection relationships.

Figure 10.3 ANP Design Philosophy

Finally, in Table 10.1, let's use a comparison table to more clearly understand the differences between these three protocols:

Table 10.1 Comparison of Three Protocols

(4) How to Choose the Right Protocol?

Current protocols are still in early development stages. MCP's ecosystem is relatively mature, although the timeliness of various tools depends on maintainers. It is more recommended to choose MCP tools backed by large companies.

The key to choosing a protocol lies in understanding your needs:

• If your agent needs to access external services (files, databases, APIs), choose MCP
• If you need multiple agents to collaborate on tasks, choose A2A
• If you want to build a large-scale agent ecosystem, consider ANP

10.1.3 HelloAgents Communication Protocol Architecture Design

After understanding the design philosophies of the three protocols, let's see how to implement and use them in the HelloAgents framework. Our design goal is: Enable learners to use these protocols in the simplest way while maintaining sufficient flexibility to handle complex scenarios.

As shown in Figure 10.4, the HelloAgents communication protocol architecture adopts a three-layer design, from bottom to top: protocol implementation layer, tool encapsulation layer, and agent integration layer.

Figure 10.4 HelloAgents Communication Protocol Design

(1) Protocol Implementation Layer: This layer contains the specific implementations of the three protocols. MCP is implemented based on the FastMCP library, providing client and server functionality; A2A is implemented based on Google's official a2a-sdk; ANP is our self-developed lightweight implementation, providing service discovery and network management functions. Of course, there is currently also an official implementation, but considering future iterations, we only simulate the concept here.

(2) Tool Encapsulation Layer: This layer encapsulates protocol implementations into a unified Tool interface. MCPTool, A2ATool, and ANPTool all inherit from BaseTool, providing a consistent run() method. This design allows agents to use different protocols in the same way.

(3) Agent Integration Layer: This layer is the integration point between agents and protocols. All agents (ReActAgent, SimpleAgent, etc.) use protocol tools through the Tool System without needing to care about underlying protocol details.

10.1.4 Learning Objectives and Quick Experience for This Chapter

Let's first look at the learning content for Chapter 10:

hello_agents/
├── protocols/                          # Communication protocol module
│   ├── mcp/                            # MCP protocol implementation (Model Context Protocol)
│   │   ├── client.py                   # MCP client (supports 5 transport methods)
│   │   ├── server.py                   # MCP server (FastMCP wrapper)
│   │   └── utils.py                    # Utility functions (create_context/parse_context)
│   ├── a2a/                            # A2A protocol implementation (Agent-to-Agent Protocol)
│   │   └── implementation.py           # A2A server/client (based on a2a-sdk, optional dependency)
│   └── anp/                            # ANP protocol implementation (Agent Network Protocol)
│       └── implementation.py           # ANP service discovery/registration (conceptual implementation)
└── tools/builtin/                      # Built-in tools module
    └── protocol_tools.py               # Protocol tool wrappers (MCPTool/A2ATool/ANPTool)

For this chapter's content, the focus is mainly on application, and the learning objective is to have the ability to apply protocols in your own projects. Also, since protocols are currently in early development stages, there's no need to spend too much effort reinventing the wheel. Before starting practical work, let's prepare the development environment:

# Install HelloAgents framework (Chapter 10 version)
pip install "hello-agents[protocol]==0.2.2"

# Install NodeJS, refer to documentation in Additional-Chapter

Let's experience the basic functionality of the three protocols with the simplest code:

from hello_agents.tools import MCPTool, A2ATool, ANPTool

# 1. MCP: Access tools
mcp_tool = MCPTool()
result = mcp_tool.run({
    "action": "call_tool",
    "tool_name": "add",
    "arguments": {"a": 10, "b": 20}
})
print(f"MCP calculation result: {result}")  # Output: 30.0

# 2. ANP: Service discovery
anp_tool = ANPTool()
anp_tool.run({
    "action": "register_service",
    "service_id": "calculator",
    "service_type": "math",
    "endpoint": "http://localhost:8080"
})
services = anp_tool.run({"action": "discover_services"})
print(f"Discovered services: {services}")

# 3. A2A: Agent communication
a2a_tool = A2ATool("http://localhost:5000")
print("A2A tool created successfully")

This simple example demonstrates the core functionality of the three protocols. In the following sections, we will deeply learn the detailed usage and best practices of each protocol.