MCP vs A2A vs Agentic Resource Discovery: Understanding the Protocols Behind the Agentic Web

AI agents need a common infrastructure to work together

An AI agent can analyze information, call external tools, and execute complex tasks. But what happens when the tool it needs belongs to another organization? What if the task requires delegating work to a specialized agent built with a completely different framework? And how does the agent discover that capability in the first place?

These questions expose an important limitation in the current agent ecosystem: building capable agents is not enough. They also need standardized ways to connect, communicate, and discover one another.

Three emerging standards address different parts of this problem:

• Model Context Protocol (MCP): Standardizes how AI applications connect to tools, resources, and other contextual capabilities.
• Agent2Agent (A2A): Standardizes communication and collaboration between independent AI agents.
• Agentic Resource Discovery (ARD): Provides a way to publish, discover, and verify AI capabilities across organizational and platform boundaries.

They are not three competing protocols trying to solve the same problem.

Think of them as different layers of an interoperable agent ecosystem:

• MCP helps an agent use a capability.
• A2A helps an agent collaborate with another agent.
• ARD helps an agent find capabilities and establish confidence in their publishers before connecting.

Understanding these distinctions is becoming important for developers building multi-agent applications, enterprise automation systems, and the infrastructure behind the emerging agentic web.

1. What is MCP? Connecting AI agents to tools and data

The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications interact with external systems.

Before MCP, developers frequently had to implement custom integrations for individual applications, databases, APIs, and services.

An AI assistant connected to a CRM might use one integration. The same assistant connected to a database might need another. A different AI application could require another implementation for those same systems.

MCP introduces a common interface between AI applications and external capabilities.

Instead of building a separate integration for every AI application, developers can expose capabilities through MCP servers that compatible clients can connect to.

How MCP works

MCP follows a client-server architecture.

Its main components are:

• MCP Host: The AI application that manages the overall interaction.
• MCP Client: The component inside the host that communicates with an MCP server.
• MCP Server: The service exposing tools, resources, or prompts.

For example, consider an AI assistant that needs access to company information.

The application could connect to:

• A CRM MCP server.
• A database MCP server.
• A document management MCP server.
• An internal analytics MCP server.

Each server exposes its available capabilities through the protocol.

The AI application can discover those capabilities and use them according to the task and the permissions granted.

MCP's three important primitives

MCP is not limited to tool calling. It provides several types of capabilities.

1. Tools

Tools are executable functions that an AI application can invoke.

Examples:

• Search customer records.
• Create a support ticket.
• Query a database.
• Send a notification.
• Execute a calculation.

Tools are particularly important because they allow an AI application to interact with external systems rather than only generate text.

2. Resources

Resources expose contextual information that applications can retrieve.

Examples:

• Documentation.
• Files.
• Database records.
• Application data.
• Reference material.

A resource provides information that can help an agent understand the environment in which it is operating.

3. Prompts

Prompts allow MCP servers to expose reusable prompt templates or interaction patterns.

For example, an internal research server might provide a predefined template for analyzing a document or preparing a technical report.

A practical example

Imagine a sales agent working inside a CRM application.

A sales representative asks:

"Find the last five interactions with this customer, summarize the purchasing history, and prepare a follow-up email."

The agent could use MCP to:

1. Retrieve the customer record.
2. Read the interaction history.
3. Query the purchasing database.
4. Retrieve relevant product information.
5. Prepare a draft email.

The agent remains responsible for deciding what to do. MCP standardizes how the application communicates with the systems providing those capabilities.

What MCP does not do

MCP does not automatically make an application an autonomous agent.

It does not define the complete reasoning process, business workflow, or collaboration model between independent agents.

It provides a standardized communication layer for accessing capabilities.

It also does not automatically make a connected tool trustworthy. Authentication, authorization, permissions, and operational security remain essential.

Why MCP matters

MCP reduces the integration burden between AI applications and external systems.

A compatible client can connect to different MCP servers without requiring a completely new communication implementation for each one.

This creates the foundation for more portable tool integrations.

Official documentation: Model Context Protocol.

2. What is A2A? Enabling communication between independent AI agents

MCP addresses how an AI application connects to tools and data. But what happens when the capability required is not a simple tool?

Sometimes the application needs another autonomous system.

For example, a financial analysis agent may need to delegate market research to a specialized research agent. That research agent may be built using a different framework, use a different model, and operate on infrastructure managed by another organization.

Sharing internal tools or implementation details is not necessarily desirable.

This is the problem addressed by the Agent2Agent (A2A) Protocol.

Originally developed by Google and subsequently donated to the Linux Foundation, A2A is an open standard for communication and collaboration between independent AI agents.

Its purpose is to let agents interact through a common protocol without requiring them to share their internal architecture, memory, or tools.

How A2A works

A2A defines a communication model between a client agent and a remote agent.

The client sends a request to the remote agent, which processes the task and returns messages, status updates, or artifacts.

The remote agent remains responsible for its own internal execution.

This distinction is important: the client does not need to know how the remote agent reasons or which tools it uses internally.

The Agent Card

A central component of A2A is the Agent Card.

An Agent Card is a machine-readable description of an agent's identity, capabilities, skills, endpoint, and authentication requirements.

It helps a client understand what a remote agent offers before interacting with it.

A simplified example:

{
  "name": "Market Research Agent",
  "description": "Analyzes market trends and competitors",
  "url": "https://research.example.com/a2a",
  "version": "1.0.0",
  "skills": [
    {
      "id": "competitor-analysis",
      "name": "Competitor Analysis",
      "description": "Researches competitors and market positioning"
    },
    {
      "id": "market-trends",
      "name": "Market Trend Analysis",
      "description": "Identifies market trends and opportunities"
    }
  ]
}

This is an illustrative, simplified representation, not a complete production Agent Card.

The client can inspect the card to understand the remote agent's advertised capabilities and how to connect.

Tasks, messages, and artifacts

A2A introduces several concepts for managing agent collaboration.

Messages

Messages represent communication between the client and remote agent. They can contain text, structured data, or file-related content.

Tasks

A task represents a unit of work managed by the remote agent.

Unlike a simple request-response interaction, a task can have a lifecycle. It may be submitted, processed, completed, failed, or paused while additional input is required.

Artifacts

Artifacts represent outputs produced during task execution.

Examples include:

• A research report.
• A generated document.
• Structured JSON data.
• An image or other file.

Streaming and asynchronous updates

A2A supports streaming updates and asynchronous patterns for tasks that take longer to complete.

This matters because complex agent work may require several minutes or longer, and clients need to know whether the remote agent is still processing, waiting for input, or finished.

A practical example

Imagine a business intelligence agent that needs to analyze a competitor.

The main agent does not have access to every research system. Instead, it delegates work to a specialized external research agent.

The interaction could look like this:

1. The main agent identifies the need for competitor research.
2. It discovers or already knows the remote research agent's Agent Card.
3. It sends a task through A2A.
4. The remote agent performs its own research using its internal tools.
5. It sends progress updates.
6. It returns a structured report as an artifact.
7. The main agent incorporates the findings into the final analysis.

The main agent does not need direct access to the research agent's private tools or internal reasoning.

What A2A does not do

A2A is not a replacement for MCP.

It does not primarily define how an agent connects to a database or invokes a local tool. Its focus is communication between independent agent systems.

It also does not automatically solve agent discovery across the entire internet. Agent Cards and registries provide discovery mechanisms, but finding and verifying capabilities across a large, decentralized ecosystem introduces additional requirements.

That is where ARD becomes relevant.

Official documentation: A2A Protocol.

3. What is Agentic Resource Discovery (ARD)?

As the number of agents, tools, and specialized services grows, developers face another problem:

How does an agent find the right capability when it does not already know where that capability exists?

An organization may expose dozens of MCP servers, several A2A agents, APIs, and specialized skills.

Another organization may expose hundreds.

Without a shared discovery layer, developers often depend on manually configured integrations, internal registries, or platform-specific directories.

This creates fragmented ecosystems.

Agentic Resource Discovery (ARD) addresses this problem by providing an open specification for publishing, discovering, and verifying AI capabilities across the web.

Google announced the specification on June 17, 2026, with industry partners including Microsoft and other participants in the agent ecosystem.

ARD is designed to work independently of the underlying framework, protocol, or provider.

The architecture: catalogs and registries

ARD relies on two important primitives.

1. Catalogs

A catalog is a machine-readable description of the capabilities an organization makes available.

It is published under the organization's own domain.

For example, a software company might publish a catalog describing:

• Its customer support agent.
• Its documentation search MCP server.
• Its billing API.
• Its internal deployment agent.
• Its available skills.

The catalog can describe resources using different underlying technologies.

A key detail is that catalogs can reference MCP servers, A2A agents, OpenAPI tools, and other catalogs.

2. Registries

A registry works like a search engine for agentic capabilities.

It discovers published catalogs, indexes their contents, and allows agents or applications to search for relevant resources.

Instead of manually maintaining a list of every available agent and tool, a client can query a registry to discover capabilities matching a particular requirement.

How ARD discovery works

A simplified discovery process looks like this:

1. An organization publishes its catalog on its own domain.
2. A registry discovers and indexes that catalog.
3. An agent needs a capability, such as a specialized document analysis service.
4. The agent searches a registry or retrieves a known catalog directly.
5. The discovery layer returns matching resources and their metadata.
6. The agent or client verifies the publisher's identity and trust information.
7. The client connects directly to the resource using its native protocol.

This last point is important.

ARD is not designed to replace the protocol used to execute the actual interaction.

It helps discover the resource and provides information that supports verification. The connection then uses the resource's native protocol, such as MCP, A2A, or an API.

Why domain ownership matters

ARD's architecture uses catalogs published under an organization's own domain as part of its identity and trust model.

This creates a relationship between the publisher and the resources it advertises.

The specification also describes verifiable trust metadata that can be used to validate publisher identity before connecting.

This is particularly important when agents dynamically discover capabilities outside their own organization.

A capability should not be trusted simply because a registry returned it as a search result.

Discovery and trust are related, but they are not the same thing.

A practical example

Consider an operations agent investigating a production incident.

It needs several capabilities:

• Query infrastructure monitoring.
• Search engineering documentation.
• Retrieve deployment history.
• Open support tickets.
• Consult a specialized troubleshooting agent.

The agent does not necessarily know which organization provides each service.

With an ARD-based discovery layer, it can search for the capabilities it needs.

A registry can return resources from different publishers, including MCP servers and A2A agents.

The agent can then verify the relevant trust information and connect using the appropriate native protocol.

This is the difference between a manually connected agent and an agent operating in a broader, discoverable ecosystem.

Official reference: Google Developers — Announcing the Agentic Resource Discovery Specification.

4. MCP vs A2A vs ARD: the key differences

The protocols solve different problems, so comparing them as direct alternatives can be misleading.

The simplest interpretation:

• MCP answers: How can my agent use this tool?
• A2A answers: How can my agent collaborate with another agent?
• ARD answers: Where can I find the right capability, and how can I verify its publisher?

5. How the three protocols work together

The real value becomes clearer when the protocols are combined.

Imagine a company building an autonomous business research system.

The system receives this request:

"Analyze the European electric vehicle market, identify the five largest competitors, compare their product portfolios, and prepare a market report."

The main research agent needs several capabilities.

It may need:

• A web research service.
• A financial data extraction service.
• A competitor analysis agent.
• A document generation tool.

Here is how the three standards can contribute.

Step 1: Discover capabilities through ARD

The research agent does not have every resource hardcoded.

It searches an ARD registry for capabilities relevant to market research, financial data, and report generation.

The registry returns suitable resources and associated publisher metadata.

Step 2: Verify the publishers

Before connecting to an external capability, the application evaluates the available trust metadata and verifies the publisher according to its security policy.

It also checks whether the capability is permitted for the current task.

Step 3: Connect to tools through MCP

The research agent connects to a discovered financial data service through MCP.

It can discover the server's available tools and invoke the appropriate functions.

Step 4: Delegate research through A2A

The main research agent discovers a specialized competitor analysis agent.

It submits a task using A2A, receives progress updates, and eventually retrieves the agent's report.

Step 5: Produce the final result

The main agent combines its own findings with the specialist's output and uses a document generation tool to prepare the final report.

The three protocols have different responsibilities throughout the process.

Conceptual architecture

                   USER REQUEST
                        |
                        v
                MAIN RESEARCH AGENT
                        |
                        v
             ARD: DISCOVER CAPABILITIES
                        |
                        v
              VERIFY PUBLISHER / TRUST
                        |
              +---------+---------+
              |                   |
              v                   v
         MCP CONNECTION       A2A CONNECTION
              |                   |
              v                   v
        FINANCIAL DATA       SPECIALIST AGENT
        WEB SEARCH           COMPETITOR ANALYSIS
        DOCUMENT TOOLS       RESEARCH TASK
              |                   |
              +---------+---------+
                        |
                        v
                 RESULT SYNTHESIS
                        |
                        v
                  FINAL REPORT

This is a conceptual architecture, not a mandatory protocol sequence. An application can use MCP and A2A without ARD, and it can discover resources through a direct catalog or an existing registry rather than a public federated search service.

The important principle is separation of responsibilities.

Discovery should not be confused with execution, and tool access should not be confused with agent collaboration.

6. A2A already has discovery. Why do we need ARD?

This is one of the most important questions in the comparison.

A2A already defines the Agent Card, which describes an agent's identity, capabilities, skills, endpoint, and authentication requirements.

It also supports several ways of finding Agent Cards, including:

• Well-known URLs.
• Registries and catalogs.
• Direct configuration.

So why introduce another discovery specification?

The distinction is the scope of discovery.

A2A's Agent Card describes an individual A2A-compatible agent and how to interact with it.

ARD addresses a broader ecosystem-level problem: publishing and discovering different kinds of capabilities across organizational boundaries.

An ARD catalog can include:

• A2A agents.
• MCP servers.
• OpenAPI tools.
• Skills.
• Other catalogs.

This means ARD is not simply another way to find A2A agents.

It provides a broader resource discovery layer that can identify capabilities regardless of their native execution protocol.

There is also a trust dimension. ARD describes how publisher catalogs can be associated with verifiable identity metadata, helping clients evaluate whether the resource is actually associated with the claimed publisher.

In short:

A2A describes how to discover and communicate with an A2A agent. ARD describes how to discover and verify a broader range of agentic resources across a federated ecosystem.

The two can complement one another.

7. Security: interoperability introduces new trust boundaries

Standardized communication does not automatically create secure communication.

As agents gain access to external systems and other agents, the number of trust boundaries increases.

A system may interact with:

• An internal MCP server.
• An external A2A agent.
• A third-party API.
• A public resource registry.
• A catalog hosted by another organization.

Each connection introduces security questions.

MCP security considerations

Developers should consider:

• Authentication and authorization.
• Limiting tool permissions.
• Protecting credentials.
• Validating tool inputs and outputs.
• Preventing malicious instructions from influencing tool execution.
• Monitoring sensitive operations.

An agent should not receive unrestricted access to every tool exposed by a server.

A2A security considerations

Agent-to-agent communication requires clear trust and authorization boundaries.

Developers should evaluate:

• The identity of the remote agent.
• Authentication requirements.
• The permissions granted to the remote service.
• What information can be shared.
• Whether task outputs require validation.
• How long-running tasks are monitored.

An external agent should not automatically be trusted simply because it advertises a useful skill.

ARD security considerations

Discovery creates a separate risk: an agent may find a resource that appears relevant but belongs to an untrusted or impersonated publisher.

ARD's trust metadata and publisher verification model are intended to help address this problem.

However, verifying a publisher does not prove that every advertised capability is safe or correct.

A verified publisher can still expose a vulnerable service or an overly privileged tool.

Organizations therefore need their own policies for:

• Approved publishers.
• Allowed resource categories.
• Permission scopes.
• Resource versioning.
• Runtime monitoring.
• Revoking access when a capability becomes unsafe.

The broader lesson is that interoperability and security must be designed together.

8. What this means for developers building agent systems

The practical implications depend on the type of application being developed.

If you are building a single agent

Start with MCP if the application needs standardized access to tools and contextual resources.

You probably do not need A2A unless the agent must collaborate with independent agent systems.

ARD becomes useful when the application needs to discover resources dynamically rather than relying entirely on manually configured integrations.

If you are building a multi-agent application

Use A2A when agents need to communicate across different frameworks, vendors, or organizational boundaries.

MCP can equip each agent with its own tools.

ARD can help discover the agents and tools available across the ecosystem.

If you are building enterprise infrastructure

Consider all three as complementary components.

An enterprise may need:

• MCP for access to internal systems.
• A2A for communication between specialized agents.
• ARD for publishing and discovering approved capabilities across departments and partners.

However, enterprise governance should remain outside the assumption that a protocol alone provides security.

Identity management, access policies, audit trails, monitoring, and approval processes still need to be implemented.

9. Is the agentic web becoming the next internet of services?

The evolution of AI agents creates a different model for accessing software.

Traditional applications expose interfaces designed for human interaction or APIs designed for software integration.

Agent-oriented systems add another layer: capabilities that can be discovered and invoked by autonomous applications.

Consider the difference.

In a conventional workflow, a developer manually integrates a payment API, a CRM API, and a reporting service.

In an increasingly interoperable agent ecosystem, an agent could discover suitable capabilities, evaluate their metadata, connect using standard protocols, and delegate work to another agent.

This does not eliminate APIs, application interfaces, or traditional integrations.

Instead, it introduces standardized mechanisms that allow AI applications to interact with those systems more dynamically.

The combination of MCP, A2A, and ARD points toward a possible architecture for an agentic web:

• Published capabilities.
• Federated discovery.
• Verifiable publishers.
• Standardized tool access.
• Interoperable agent communication.

But this ecosystem is still developing.

Adoption, governance, security, compatibility, and the quality of advertised capabilities will determine whether these standards become practical infrastructure rather than another layer of technical complexity.

Final verdict: three protocols, three different responsibilities

MCP, A2A, and ARD should not be evaluated as competing solutions.

They address three distinct problems in the architecture of interoperable AI systems.

MCP is the connectivity layer. It standardizes how AI applications access tools, resources, and contextual capabilities.

A2A is the collaboration layer. It enables independent agents to exchange information, delegate tasks, and work together without exposing their internal implementations.

ARD is the discovery and publisher-verification layer. It provides a way to publish and find capabilities across organizations and connect to them through their native protocols.

For developers, the most useful mental model is:

1. Discover the capability.
2. Verify its publisher and permissions.
3. Connect using the appropriate protocol.
4. Execute the task.
5. Validate the result.

The future of agentic systems will not depend only on more powerful models. It will also depend on the infrastructure that allows those models to access services, coordinate with other agents, and operate across organizational boundaries.

That is why understanding these three standards is becoming an important part of building production-ready agent applications.

Sources and further reading

Official specifications and documentation

1. Model Context Protocol — Official Documentation
2. MCP — July 28, 2026 Specification Update
3. Agent2Agent Protocol — Official Documentation
4. A2A — Protocol Specification
5. Google Developers — Announcing the Agentic Resource Discovery Specification
6. Agentic Resource Discovery — Official Specification
7. Microsoft — Introducing the Agentic Resource Discovery Specification

Recommended technical reading

• MCP documentation — Architecture
• A2A documentation — Core Concepts
• A2A documentation — A2A and MCP

Editorial note: ARD was announced in June 2026 and is an evolving specification. A2A and MCP also evolve through versioned releases. Check the current specifications and implementation support before adopting any protocol in production.