Agentic Resource Discovery

Agentic Resource Discovery (ARD) is an attempt to standardize the question every agent has to answer before it can do anything useful: what is out there that can help me with this? Tool-calling is solved — MCP wires an agent to tools, A2A lets agents delegate to each other, and OpenAPI describes the HTTP underneath all of it. None of them tell a client where to look in the first place. ARD is the envelope around that gap: resources are described using the AI Catalog standard, published at a well-known path on the publisher’s own domain, indexed by whoever wants to index them, and searched through three endpoints. It was published as a v0.9 draft proposal on 28 May 2026 under Apache 2.0 by three authors — Junjie Bu (Google), R.V. Guha (Microsoft) and Shaun Smith (Hugging Face) — with a contributors wall of eleven organizations: Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Microsoft, Nvidia, Salesforce, ServiceNow and Snowflake.

• Discovery, not execution - ARD is explicitly an envelope. Once a client finds a resource it invokes it natively — JSON-RPC for an MCP server, the agent’s own protocol for an agent card, HTTP for an API. Authentication is left to the artifact protocol, not the discovery layer.
• Three endpoints, one required - POST /search (mandatory) takes natural-language text plus optional filters and returns ranked entries with a 0–100 semantic relevance score. GET /agents (optional) is deterministic paged browsing; POST /explore (optional) returns faceted aggregations instead of a ranked list.
• Domain anchoring instead of registration - Publishers host https://<domain>/.well-known/ai-catalog.json — or point at one with a DNS TXT record — and every entry carries a urn:air:<domain>:<namespace>:<name> identifier. Origin authority comes from the domain, so no central body has to grant a namespace.
• Federated by design - The specification assumes many independent discovery services rather than one catalog, and a search response can carry referrals to other registries. Existing tool registries become ARD discovery services rather than competitors.
• Media types as the type system - Entries are typed with application/mcp-server-card+json, application/a2a-agent-card+json, application/ai-catalog+json and application/ai-registry+json, which is how one interface stays honest across very different kinds of resource.
• Search that reads like a task - Each entry supplies 2–5 representativeQueries in natural language, which is what makes semantic matching against “what can help me do X?” work at all.
• Scores are relevance, never trust - The specification is emphatic that score MUST NOT be read as a compliance, safety or cryptographic trust rating. Trust lives in the catalog’s trustManifest, not the ranking.
• Three commit bits, no foundation - Governance is a CODEOWNERS file naming the three authors, a rule that normative changes open an issue first, and a public ledger of nine architecture decision records. No charter, no CLA, no participant roster, no working groups — and no tagged release, which is why two publishers in the wild are still on the urn:ai: prefix ADR-0009 renamed.

The reason to pay attention to this one is that it names the actual bottleneck. Scoring the catalog for the standard reports found 672 reachable MCP servers, 65 Agent Cards across 22,341 hosts, and /.well-known/ coverage running between 22% and 47% depending on the market — a landscape with plenty of capability and almost no way for a machine to find it. ARD’s bet is that the fix is not another registry to submit to but a file at a fixed path on your own domain, which is the cheapest agent-readiness move available to any API provider and the one most of them still have not made. Whether ARD itself wins is a separate question from whether the pattern is right; a v0.9 draft with eleven of the largest agent builders on it is worth publishing a catalog for regardless, because the same .well-known artifact serves every other discovery client too.