Reference

ARD glossary

41 terms, each defined by what it is for rather than by restating its name. Current to specification v0.91.

The terms you need most often: an ARD entry describes one resource; a manifest (ard.json) holds entries and lives at /.well-known/ard.json; a registry crawls manifests and answers POST /search; and representativeQueries is what makes an entry findable rather than merely valid.

Where a definition restates the specification it says so and quotes it. Where it goes further, that is this site adding what the spec leaves implicit, and you should weigh it accordingly. The official glossary is at agenticresourcediscovery.org and defines 22 terms.

Terms

Agentic resource: Any external capability an AI client can call on to get something done: an MCP server, an A2A agent, a skill, a plugin, a workflow, or a plain REST API. ARD is deliberately vague about what one is, because the point is to describe them all with one envelope.
ARD: also: Agentic Resource Discovery Agentic Resource Discovery. An open specification for how agentic resources describe themselves, how clients ask for them, and how discovery services answer. It sits entirely before invocation: it helps you find the thing, then gets out of the way. Announced 17 June 2026, Apache 2.0.
ARD entry: The unit ARD is defined over: one agentic resource described so that search can find it. Every ARD entry is a well-formed catalog entry, but not every catalog entry is an ARD entry. The difference is representativeQueries.
ard.json: also: ARD manifest The manifest file, hosted at /.well-known/ard.json. A JSON document with an entries array. This is the current normative path; ai-catalog.json is the predecessor.
AI Catalog: A separate manifest standard that predates ARD and shares much of its vocabulary, from the AI Catalog Working Group at the Linux Foundation. ARD is built on its data model but defines its own entry and its own manifest path. The two are independent specifications.
ai-catalog.json: The predecessor manifest path, /.well-known/ai-catalog.json, along with the link relation ai-catalog. Superseded by ard.json in v0.91 on 26 August 2026. A consumer may still check it; none is required to.
Agentmap directive: A line in robots.txt pointing at an entry source, written Agentmap: https://example.com/entries.json. One of the five publishing mechanisms, and the cheapest to add if you already control robots.txt.
AI client: also: client The orchestrator doing the discovering: a chatbot, an IDE assistant, an automation. It queries a registry, picks a result, and invokes it over that resource's own protocol.
Agent Name Service (ANS): also: ANS A DNS-inspired directory where an agent's name resolves to a PKI-verified X.509 identity. Complementary to ARD rather than competing: ARD answers which resource fits the job, ANS answers whether the name behind it is really who it claims.
A2A: also: Agent2Agent Agent2Agent. A protocol for agents to talk to each other, where each agent publishes an Agent Card. ARD discovers A2A agents; A2A is how you then speak to one. The distinction in full.
Attestation: A verifiable compliance claim referenced from an entry's trustManifest, such as SOC 2 or HIPAA, that a registry or client can fetch and check. ARD carries the reference; it does not evaluate the claim.
capabilities: An optional array of short tokens on an entry, such as ["WeatherTool"], that lets a registry filter structurally without fetching the artifact. Cheap to add, and it puts you in filtered searches.
Catalog: A publisher's listing of its resources. A catalog entry commits to as little as possible so it can hold whatever the publisher wants to say. That is exactly why it is not automatically discoverable: search needs guarantees a catalog does not make.
Catalog entry: One resource description inside a manifest: identifier, type, location, optional metadata. Becomes an ARD entry when it also carries the discovery signals.
Context window problem: The reason ARD exists. Tool descriptions are loaded into the model's context, so each tool costs tokens on every request and accuracy degrades well before the window fills. ARD moves selection out of the model and into a search service.
Dense retrieval: Ranking by embedding similarity rather than word overlap, which is how a query about scraping finds a server called Hydrafetch. Not mandated by ARD, but it is how representativeQueries is meant to be used.
Discovery service: also: registry A service that indexes agentic resources and answers POST /search. The specification's formal term is Agent Registry; in practice the words are used interchangeably.
Dynamic discovery: The searchable half: live registries answering queries at runtime. The other half is static discovery, which is documents sitting on domains waiting to be crawled.
Explore (POST /explore): An optional endpoint returning an aggregation over the matched set instead of ranked results, so a client can ask what a registry contains rather than for a specific thing. With no query at all it describes the whole registry.
Federation: How registries draw on each other. A search carries federation set to auto (the registry merges upstream results itself), referrals (it hands back other registries for you to query), or none.
filter: The structured half of a query. Keys are term paths, values are arrays. Within one key the values are ORed, across keys they are ANDed. Any term an entry carries can be a filter key, with no change to the specification.
identifier: The required, globally unique handle for an entry, in URN form. Stable across infrastructure changes, which is why it is a URN rather than a URL.
In-page markup: Publishing an entry as JSON-LD embedded in a web page about the resource, found by ordinary web crawling. One of the five mechanisms, and the one that needs no new file.
JSON-LD: The data model v0.91 restated entries in terms of. An entry is a JSON-LD node whose plain terms come from a default namespace. Entries written before this change remain valid and need no edits; what it adds is a seam for other vocabularies.
Media type: The IANA type in an entry's type field saying what the artifact is: application/mcp-server-card+json, application/a2a-agent-card+json, application/ai-skill+md. Note the spec's own warning that these are de facto community standards still tracking towards formal registration.
MCP: also: Model Context Protocol Model Context Protocol. How an agent calls a tool once it has one. The largest resource family in every public ARD index by a wide margin. ARD compared to MCP.
Namespace: The middle segment of a URN identifier, grouping your own resources: urn:air:acme.com:server:weather. Yours to choose. Also, in the JSON-LD sense, a vocabulary an entry draws terms from through its @context.
Publisher: Whoever hosts an ard.json. The publisher segment of every identifier in it must be a domain they control, and that binding is what a verifying registry checks.
Publisher authority binding: The rule in section 4.5.1: the trust domain in trustManifest.identity must match the publisher segment of the entry's identifier. An entry claiming urn:air:google.com:... is rejected unless it can produce an attestation issued by google.com. This is ARD's defence against namespace squatting.
Referral: An entry in a search response pointing at another registry the client can query itself. What you get back when you ask for federation: "referrals".
Registry / Agent Registry: A discovery service exposing the standard REST search interface. Any system can run one, and the specification expects registries to disagree: each applies its own curation, ranking and access policy. Curation is the trust boundary, not the protocol.
Relevance score: The 0 to 100 score on a search result. Semantic relevance only. The specification states in normative language that it must not be read as a trust, compliance or safety rating.
representativeQueries: Two to five plain-language questions a user might ask that this resource can answer. The signal a registry builds its semantic index from, and the practical difference between being listed and being found.
rel="ard": The link relation, used as <link rel="ard" href="..."> in a page head. Consumers must honour it, which makes it a genuine alternative to the well-known path rather than a hint. Replaced rel="ai-catalog" in v0.91.
Search (POST /search): The one endpoint every registry must expose. Takes a query with required text and optional filter, returns entries ranked by relevance. A result must carry identifier; everything else is at the registry's discretion.
Skill: A packaged instruction set, usually Markdown, that an agent loads to do a specific job. Second largest family in the public index after MCP servers.
Static discovery: Publishing entries as documents that sit on your domain waiting to be crawled, with no service to run. Decentralised, and the reason nobody has to grant you permission.
Trust manifest: The optional trustManifest object: cryptographic identity, attestations, provenance, signature. ARD constrains only identity, so a manifest defined by SPIFFE, a DID method or an enterprise PKI is all structurally valid.
urn:air identifier: The URN scheme for entries: urn:air:<publisher>:<namespace>:<name>. Roots identity in DNS and stays stable while your infrastructure moves around underneath it.
Well-known URI: The conventional manifest location, https://<domain>/.well-known/ard.json, where every conformant consumer is required to look.
Web ingestion: Crawling manifests and in-page markup from discovered URIs. Required of every ARD implementation. Scanning git, npm or OCI registries is optional on top.

Last reviewed 2026-09-04. Checked against ARD v0.91 (Proposal, 2026-08-26).