Agentic Resource Discovery (ARD): the missing discovery layer for agentic AI

Over the past two years, agentic AI has moved from prototype to production. Two open protocols have emerged as the foundation: the Model Context Protocol (MCP), which connects an agent to its tools and data, and Agent2Agent (A2A), which lets agents talk to one another. Yet one question neither answers: how does an agent find the right resource to call, among hundreds of MCP servers, agents and APIs?

Announced on 17 June 2026, Agentic Resource Discovery (ARD) fills that gap. It is a discovery protocol, not an invocation one — a distinction that changes everything. Here's the breakdown.

Discovery: agentic AI's blind spot

MCP and A2A answer how to call a resource you already know about. Neither answers where to find it. At enterprise scale — let alone across the open internet — an agent that wants to get something done runs into three questions, all sitting before the call:

1. Where does the right capability live? Which MCP server, which A2A agent, which API?
2. Which one to choose among several equivalent candidates?
3. Is it safe to connect to? What identity, what compliance attestations?

An analogy: MCP and A2A tell you how to place a phone call once you have the number. ARD is the phone book and directory assistance. Without it, every agent orchestrator hand-wires its own list of resources — an approach that doesn't scale.

What exactly is ARD?

ARD is an open specification that defines how to catalog, search and discover agentic resources: agents, MCP servers, A2A agents, Skills, APIs, workflows — anything that can be represented as a catalog entry. The core idea fits in one sentence, taken from the spec:

ARD sits entirely before invocation. It helps the client find the right resource; the resource is then called through its own native mechanism.

In other words, ARD is an agnostic envelope: it replaces neither MCP, nor A2A, nor API runtimes. It references those artifacts, helps pick the right one, then steps aside.

On governance, the pedigree is notable. The authors are Junjie Bu (Google), R.V. Guha (Microsoft) and Shaun Smith (Hugging Face). Guha's name is no accident: he is one of the architects of schema.org, RSS and RDF — exactly the profile to standardize a discovery layer at web scale. The spec is published under the Apache 2.0 license and backed at launch by Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, ServiceNow and Snowflake. It builds on a pre-existing open data model, AI Catalog, extending it with discovery primitives.

Two layers: a manifest and a registry

ARD rests on two complementary mechanisms. The diagram below sums up the full journey, from publishing a catalog to invoking the resource.

1. Static discovery: the ai-catalog.json manifest

An organization publishes a manifest at a conventional, spec-defined location, /.well-known/ai-catalog.json, listing its resources. Each entry carries a domain-anchored URN identifier (urn:air:<publisher>:<namespace>:<name>), a type expressed as a spec-defined media type (not yet IANA-registered — for example application/mcp-server-card+json or application/a2a-agent-card+json), and either a URL to the artifact or the artifact inlined directly.

{
  "specVersion": "1.0",
  "host": { "displayName": "Pulse by Astek", "identifier": "did:web:pulse.astek.com" },
  "entries": [
    {
      "identifier": "urn:air:pulse.astek.com:server:portal",
      "displayName": "Pulse Portal MCP Server",
      "type": "application/mcp-server-card+json",
      "url": "https://pulse.astek.com/.well-known/mcp/portal.json",
      "capabilities": ["SearchCatalog", "ShowTechRadar"],
      "representativeQueries": [
        "find a Kubernetes skill",
        "show the tech radar"
      ]
    }
  ]
}

The representativeQueries field is a smart design choice: it states, in natural language, the questions the resource knows how to answer. That's what feeds semantic indexing on the registry side.

2. Dynamic discovery: a registry you query in plain language

On top of the manifests, registries crawl and index these catalogs, then expose a REST search API. The mandatory method is POST /search: you send a natural-language query and get resources ranked by relevance.

{
  "query": { "text": "an agent to book a flight" },
  "federation": "referrals",
  "pageSize": 5
}

The response returns a list of results, each with a relevance score (0 to 100) and the registry source. One important — and refreshingly honest — point: that score is purely informational. The spec explicitly forbids interpreting it as a trust, compliance or safety rating. Federation (auto, referrals, none) lets an enterprise registry refer out to public registries, with no single central index.

Trust, built into the model

Each entry can carry a trustManifest: a verifiable identity (SPIFFE, DID), attestations (SOC 2, HIPAA, GDPR…) and a provenance trail. You can therefore filter a resource on its compliance level before even connecting to it — a valuable building block for regulated enterprise use.

ARD replaces neither MCP nor A2A: it completes them

That's the key takeaway. Each protocol holds a distinct place in the agentic stack.

Protocol	Role	Question answered
ARD	Discovery (before the call)	Which resource? where? is it safe?
MCP	Invocation agent ↔ tools	How do I call tools and data?
A2A	Invocation agent ↔ agent	How do I delegate a task to another agent?
OpenAPI	REST invocation	How do I call an API?

The end-to-end flow is clean: an orchestrator queries a registry ("find me an agent that can file an expense report"), receives ranked and attested candidates, picks one, then invokes it through its native protocol — MCP, A2A or REST. ARD has done its job before the first byte of invocation is exchanged.

What's at stake for the enterprise

As an organization multiplies internal MCP servers, agents and APIs, the problem is no longer how to invoke, but how to find and choose the right resource. ARD opens three direct use cases:

• An internal directory: publish an ai-catalog.json on the company domain, listing its MCP servers, agents and APIs. An orchestrator discovers them dynamically, with no hard-coded configuration.
• Cross-organization federation: an agent can query a partner's registry (federation: referrals) with no shared index — governed discovery between entities.
• Governance through trust: expose only attested resources to agents, leaning on the trustManifest.

A young standard, worth watching closely

Let's be honest about maturity: ARD is at version v0.9 (draft), dated 28 May 2026. The spec is open and evolving, and still carries a few minor inconsistencies between its text, schemas and examples — the usual lot of a standard that's a few weeks old. This is not a protocol to push to production blindly today.

But the signal is strong. This is the first credible multi-vendor attempt — Google, Microsoft, Hugging Face and eight other major players — to address a layer left so far to each framework. And it arrives precisely as the MCP and A2A ecosystems reach the critical mass that makes discovery indispensable.

The Pulse by Astek view

Our recommendation: watch and prototype, don't industrialize yet. ARD deserves a spot in active monitoring and R&D, for two reasons. First, the spec is still moving. Second — and this is the essential point — an ai-catalog.json can reference an existing MCP server today without changing anything about how you invoke it. The cost of experimentation is low, the differentiation potential is real.

One angle we find especially compelling at Pulse by Astek: ARD could become a foundational building block of the company's engineering context. Publishing an internal catalog of our MCP servers, agents and APIs means giving every new product — and the coding agents assisting it — a way to automatically discover the relevant context: which internal resources exist, what they can do, whether they can be trusted. Instead of hand-wiring that context project after project, you make it queryable. The agentic-resource catalog and the engineering context become one, and discovery turns into an engineering-productivity lever.

For organizations deploying agentic architectures at scale, ARD could become what DNS and directories were for the web: invisible yet structuring infrastructure. The kind of building block you're better off understanding early.

---

Further reading

• Specification and schemas: agenticresourcediscovery.org
• Repository and reference implementations: github.com/ards-project/ard-spec
• Official announcement: Google Developers Blog