An AI Travel Agent in Action: A Detailed Look at How Two Agents Plan a Trip | by Neeraj Agrawal | Google Cloud – Community | Jun, 2025

The future of Artificial Intelligence is collaborative. Complex tasks are often best handled by a team of specialized AI Agents. But how do you get a “planner” agent to communicate effectively with a “booking” agent, especially if they were built by different teams?

The answer lies in interoperability protocols. Let’s take a detailed look at how two key standards, Google’s Agent-to-Agent (A2A) protocol and Anthropic’s Model Context Protocol (MCP), create a seamless partnership for a task we can all relate to: planning a vacation.

The Scenario: Planning a Trip to Paris

Our use case involves two specialized agents:

• Travel Planner Agent: The user-facing “manager.” A user tells it, “I want to fly to Paris from New York next Friday.” The Planner’s job is to coordinate the trip, but it doesn’t know how to search for flights itself.
• Flight Booker Agent: The “specialist.” It is an expert in finding the best flight options. To do its job, it needs access to a real-world tool: a live Airline Global Distribution System (GDS) API.

Here’s the detailed breakdown of how A2A and MCP facilitate their collaboration.

A2A is the formal language for agents to discover each other’s skills and delegate tasks. It’s how the Travel Planner finds and assigns the flight search job to the Flight Booker.

Agent Discovery via Agent Cards

Every A2A-compliant agent publishes an Agent Card, a machine-readable “digital business card.” The Flight Booker Agent’s card would provide a detailed public profile, specifying:

• Identity: Its name (Flight Booker Agent) and a description (“Specializes in finding and filtering flight options”).
• Contact Info: The specific digital address (endpoint) where it receives tasks.
• Capabilities: A structured list of its skills. This list would contain a capability named find_flights. This capability’s description would detail:
  – Input Schema: What it needs to do its job. For find_flights, this would be an object containing a departure_city, arrival_city, and a date.
  – Output Schema: What it produces as a result. This would be an object containing a list of flight_options, where each option has a flight_number, airline, price, and departure_time.

By reading this card, the Travel Planner Agent programmatically understands exactly what the Flight Booker can do and how to ask for it, with no guesswork.

Task Delegation and Management

Once the Travel Planner discovers the Flight Booker, it sends a formal task request using the A2A protocol. This is a structured work order.

1. The Planner sends a task: It constructs a standardized A2A message to the Flight Booker’s endpoint. This message contains:
   – A unique task_id to track this specific job.
   – The name of the capability to use: find_flights.
   – The input data, perfectly matching the required schema (e.g., departure_city: “New York”, arrival_city: “Paris”, date: “2025-06-27”).
   – A callback_url, which is the Planner’s own address where the results should be sent.
2. The Booker sends a response: After completing its work, the Flight Booker sends a standardized A2A message back to the provided callback URL. This response contains:
   – The original task_id, so the Planner knows which job is now finished.
   – A status of completed.
   – The output data, containing the list of flight_options in the exact format promised by its Agent Card.

This structured exchange ensures reliable, auditable communication between the two agents.

While A2A managed the delegation between agents, MCP governs how the specialist agent uses its own tools to get the job done.

The Flight Booker Agent, upon receiving the task, needs to consult the live Airline GDS API to find real-time flight availability and pricing.

The MCP Flow: Agent as Client, Tool as Server

1. Tool Description: The Airline GDS API, being MCP-compliant, provides its own “user manual.” This description details its functions. For instance, it would describe a function named search_one_way_flights and specify that it requires parameters like origin_airport_code, destination_airport_code, and departure_date.
2. Agent Executes Tool Function: The Flight Booker, acting as an MCP Client, constructs a standardized request to the tool. This message precisely instructs the GDS API, saying: “Execute your search_one_way_flights method with the parameters origin_airport_code: ‘JFK’, destination_airport_code: ‘CDG’, etc.”
3. Tool Responds: The GDS API (the MCP Server) processes this request, queries the airline systems, and returns a standardized response. This result contains the raw flight data the Flight Booker needs to do its job.

This clear, consistent interface means the Flight Booker can interact with any airline data provider that speaks MCP without needing custom, brittle code for each one.

Here is how the entire trip planning process unfolds in a single, continuous flow:

1. Task Initiation: The user tells the Travel Planner Agent, “I want to fly to Paris from New York next Friday.” The Planner translates this into structured data: {departure: "New York", destination: "Paris", date: "2025-06-27"}.
2. A2A Delegation: The Planner consults its directory of Agent Cards, finds the Flight Booker Agent, and sends it a formal A2A task request. This request includes a unique ID and the structured trip data.
3. Task Acceptance & Tool Use: The Flight Booker Agent receives the A2A task. To find flights, it acts as an MCP Client and sends an MCP request to the Airline GDS API, passing along the flight search parameters.
4. Tool Response: The GDS API returns an MCP response containing a raw list of available flights, including prices, times, and seat availability.
5. Analysis & Completion: The Flight Booker Agent takes this raw data, filters out any undesirable options (e.g., flights with too many layovers), and formats the best choices into a clean, user-friendly list.
6. A2A Response: The Flight Booker sends an A2A message back to the Travel Planner’s callback URL. This message contains the original task ID and the final, curated list of flight options.
7. Workflow Complete: The Travel Planner receives the structured response. It can now present the flight options to the user and proceed with the next step, like asking if they’d also like to find a hotel.