MCP Vs A2A - Do You Need to Learn Both?


Hello Reader,

The last couple of weeks have been action-packed for Gen AI! Two specific announcements were at the forefront - MCP (Model Context Protocol) and A2A (Agent To Agent). In today's edition, we will learn the similarities and differences between both, and answer which parts YOU need to know for the job and interviews.

MCP

MCP is released by Anthropic. Before we understand MCP, let's understand the existing challenges. Let's say you send a prompt to the app, "What's the weather in Tokyo?". The LLM in the app doesn't know about the current weather, hence it invokes an agent that runs some code. This code reaches out to an external weather tool, which sends weather data in JSON to the agent. Agent passes it to the LLM, and the LLM formats the data in nice natural language and sends it to the user.

Question is - how does the agent code interact with the weather tool? Via API. And to do that, as shown below, the agentic code, needs to know the API URL, required header information, and payload.

This works, but there are some challenges too:

  • If developers in the weather app changes the API schema, and adds/removes input/output fields, and agentic code doesn't know about it, the connection breaks
  • Imagine, in real-world, agents talk to numerous such tools. Each tool requires separate integration with custom code
  • It's a tedious talk for the app developers to instrument all these separate tools inside the app code

Hence, MCP was born!

MCP standardizes the communication between the agentic code and tools (and local datasources, but tool is the most widely used). What does this mean?

  • An MCP client (think of a piece of code running inside the agent), connects to the MCP server, instead of connecting to the tool directly with a predefined API URL
  • The developers of each tool expose this MCP server
  • MCP client asks the server, "What can you do?". In response, the MCP server responds with the tool capability, description, and input/output schemas
  • IMPORTANT - this discovery is dynamic, and happening at runtime. If input/output field changes, this discovery call will reveal all the fields at runtime
  • The MCP client registers all these, and then can invoke the tool via the MCP server
  • The MCP server handles the connection to the tool. As a result, the code does NOT need to hardcode the API URLs like before
  • The developers of the tools give you the code for the MCP server. You still need to pass authn/z parameters (for e.g. token and team ID for Slack Tool, Access Key and Secret Access Key for AWS Tool etc) to the MCP server. BUT you can run this MCP server locally, or on the cloud. It's up to you

Okay, so MCP standardizes the interaction between the Agent and the underlying tools. But what is this new A2A then? Let's find out.

A2A

MCP handles the communication between the agent and tools (and local datasources). But how about agent-to-agent? Let's look at the diagram below

Agent B has the logic to get the stuff done with tools/datasources using MCP, and this part we understood from above.

Now, Agent A needs to call Agent B. How does this happen BEFORE A2A was in the picture:

Similar to any other API call, Agent A will invoke the API URL of Agent B, and pass AuthN/Z parameters, and a payload. This brings similar challenges as above:

  • Each agent needs to know what the other agent does beforehand
  • Hardcode the connection URL and authn/z parameters
  • Have to know how to submit prompts/tasks to the other agent

A2A (or Agent2Agent) standardizes the communication between agents. What does this mean?

A2A + MCP Flow

  • Agent A, runs a A2A client, which connects to Agent B A2A Server
  • A2A server returns an Agent Card to Agent A
  • This Agent card includes capabilities of Agent B, endpoint URL, how to submit tasks/prompts, how to get notifications on task status, and authn/z mechanism
  • IMPORTANT - Note how dynamic this is (similar to MCP). Using this any agent can discover capabilities, and connection URL, and other info during runtime, and don't need to hardcode beforehand
  • A2A do NOT include payload schema at this time (MCP returns payload schema for the tools/datasources)

In summary, MCP standardizes the connection between LLM Agents and tools, and A2A standardizes the connection between two agents. They work hand in hand because they complement each other and do not compete with each other.

This is a pretty detailed subject, and if you want a more detailed explanation with code snippets, check out video below:

video preview

If you have found this newsletter helpful, and want to support me 🙏:

Checkout my bestselling courses on AWS, System Design, Kubernetes, DevOps, and more: Max discounted links

AWS SA Bootcamp with Live Classes, Mock Interviews, Hands-On, Resume Improvement and more: https://www.sabootcamp.com/

Keep learning and keep rocking 🚀,

Raj

Fast Track To Cloud

Free Cloud Interview Guide to crush your next interview. Plus, real-world answers for cloud interviews, and system design from a top Solutions Architect at AWS.

Read more from Fast Track To Cloud

Hello Reader, Not all questions are equal in interviews and real-world projects. There are some questions that you simply can't mess up, because these concepts are so fundamental, they are used in almost ALL projects. One such concept is high availability. Surprisingly, I hear wrong answers on this all the time. In this edition, let's go over the common bad answers, a good answer, and then some! Question: What is High Availability? Bad Answers Even if a component fails, application should...

Hello Reader, EDA (Event Driven Architecture) has become increasingly popular in recent times. In this newsletter edition, we will explore what EDA is, what the benefits of EDA are, and then some advanced patterns of EDA, including with Kubernetes! Let's get started: An event-driven architecture decouples the producer and processor. In this example producer (human) invokes an API, and send information in JSON payload. API Gateway puts it into an event store (SQS), and the processor (Lambda)...

Hello Reader, In today’s post, let’s look at another correct but average answer and a great answer that gets you hired to common cloud interview questions. Question - What is RTO and RPO? Common mistakes candidate make - they say RPO (Recovery Point Objective) is measured in unit of data, e.g. gigabyte, petabyte etc. Here is the right answer - Both RPO and RTO are measured in time. RTO stands for Recovery Time Objective and is a measure of how quickly after an outage an application must be...