# Agent Registry (ARD) An Agent Registry is the dynamic, searchable layer of the [[Agentic Resource Discovery Specification (ARD)|ARD]]. Where an [[AI Catalog (ai-catalog.json)|ai-catalog.json]] is a static file one publisher hosts, a registry indexes catalogs from across the web and answers natural-language queries against all of them. It's the search engine of the agentic web, as opposed to the app store. A registry shows up in the system as a catalog entry of type `application/ai-registry+json`, so catalogs can point at registries the same way they point at any other resource. ## How it fills its index Registries crawl. **Web ingestion is mandatory**: every ARD registry must be able to fetch `ai-catalog.json` files from the [[ARD Discovery Mechanisms|discovery mechanisms]] (well-known paths, Agentmap directives, DNS records, link tags). Optionally, a registry can also scan git repositories, npm, or container (OCI) registries. During ingestion it does the work that makes search fast later: it turns each entry's `representativeQueries` into semantic vector embeddings and indexes the `capabilities` list for exact filtering. That way it can rank by meaning without ever loading the full artifact. ## The API Every registry must expose a standard HTTP REST interface. Three endpoints: - **`POST /search`** (required) — semantic, natural-language search. You send `{ "query": { "text": "find me a flight booking agent", "filter": { ... } } }` and get back ranked results. Each result carries a `score` from 0 to 100. Important: that score is **relevance only**, explicitly not a trust, safety, or compliance rating. - **`POST /explore`** (optional) — faceted aggregation. "How many MCP servers do you have? Which publishers?" An empty query covers the whole registry; a filtered query gives dynamic facets. Registries that skip it return `501`. - **`GET /agents`** (optional) — deterministic browsing with explicit filters and ordering. No semantic ranking, highly cacheable, made for developer portals. The split is deliberate: `/search` is for "find me something that does X" (fuzzy, ranked), and `/agents` is for "list everything matching these exact fields" (precise, sortable). A registry may also wrap search as an MCP tool or an A2A skill for orchestrators that prefer those, as long as the response stays in catalog-entry format. ## A real one: Hugging Face's Discover The clearest reference implementation so far is Hugging Face's **Discover** tool. It already indexes thousands of Skills, ML apps and MCP servers, both from the Hugging Face Hub and from other ARD services, and it reuses the Hub's existing semantic search rather than building a new index from scratch. You can hit it as a plain REST endpoint (`POST https://huggingface-hf-discover.hf.space/search`) or as an MCP server at the same domain's `/mcp`. GitHub's Agent Finder and Google Cloud's Agent Registry are doing the same thing from their side. The point of the spec is exactly this: many registries, one query format. ## Why this layer matters This is the part that makes ARD scale where the old model didn't. Injecting every tool description into the [[Context Window]] falls apart at thousands of capabilities, let alone millions. By moving selection out of the model and into a dedicated search service, the registry lets an agent find the right resource using rich signals (semantic queries, publisher identity, compliance metadata) without spending a single context token on the ones it doesn't pick. It's the same instinct as [[Code Mode MCP Pattern|Code Mode]]: stop forcing the model to hold everything at once. ## References - https://agenticresourcediscovery.org/ - https://huggingface.co/blog/agentic-resource-discovery-launch - https://github.com/ards-project/ard-spec ## Related - [[Agentic Resource Discovery Specification (ARD)]] - [[AI Catalog (ai-catalog.json)]] - [[ARD Discovery Mechanisms]] - [[ARD Federation]] - [[ARD Trust Manifest]] - [[Context Window]] - [[Code Mode MCP Pattern]]