ARD spec: cataloging MCP servers and A2A agent cards across federated discovery services

The discovery gap ARD was written to close

An MCP server, an A2A agent card, a Skill and a plain HTTP API are all callable, and each one is described in its own format. A client that wants to find any of them has to know which registry to ask, what that registry returns, and how to map the answer into something it can call. ARD is a specification for that layer. The README describes it as a federated, domain-anchored standard for cataloging, searching and discovering agentic resources across networks of discovery services. Two words carry the design weight. Federated means there is no single catalog that every participant must register with, so discovery services can be run by different operators. Domain-anchored means the identity of a resource is tied to a domain, which is what lets a client decide whether to trust a listing before it calls anything. The intended audience is people building discovery services and the clients that query them, not end users looking for a plugin marketplace.

What is actually in the repository, and what is not

The top level contains .github/, .gitignore, LICENSE, README.md, adr/, conformance/ and spec/. Everything normative lives under spec/. The current specification is spec/ard.md at version 0.91. The previous version is kept at spec/ard-v0.9.md and the README says it is kept reachable, which matters if you have already written against it. Machine-readable definitions sit in spec/schemas/ as CDDL, JSON Schema and OpenAPI. The adr/ directory holds architecture decision records, and conformance/ holds conformance test tooling. There is no server, no CLI and no hosted registry in this repository. The rendered documentation at agenticresourcediscovery.org/spec is generated from spec/ard.md, so the file in the repository and the published page cannot drift apart. That single-source arrangement is a real advantage over specifications whose prose and schemas are maintained separately.

Reading the spec before you write code against it

There is nothing to install from this repository, because it distributes a specification rather than a package. The README points readers to the rendered version at agenticresourcediscovery.org/spec, and the same text is in the repository. Cloning it gives you the schemas and the decision records alongside the prose, which is what you want if you are generating types or writing a validator. The command below fetches the repository and lists the specification directory, so you can see the versioned files and the schema folder before reading anything.

git clone https://github.com/ards-project/ard-spec.git
cd ard-spec
ls spec spec/schemas

You should see spec/ard.md and spec/ard-v0.9.md, plus the schema files under spec/schemas/. The conformance directory is the other entry to look at, since the README lists it as conformance test tooling. The repository does not document a package name, a published module or an install command, so do not expect one. If you need a runnable component, you are writing it yourself against the schemas.

Version 0.91 and the cost of tracking a moving specification

The status section states plainly that the specification is open and evolving. Version 0.91 is below 1.0, and no releases were retrieved for this repository, so there is no tagged artifact to pin against. You pin a commit instead. The practical consequence is that a schema file under spec/schemas/ can change between the commit you generated your types from and the commit you read next month, and nothing in the repository announces that as a breaking change. The README does keep spec/ard-v0.9.md reachable, which suggests version-to-version continuity is taken seriously, but reachability is not a compatibility guarantee. The last push to the repository was on 2026-09-12, eight days before this writing, so work is ongoing rather than stalled. Treat the specification as a moving target and record the commit hash you built against.

Changing the spec is deliberately harder than fixing it

The contributing section splits changes into two tracks. Normative changes, meaning anything that alters the standard itself, covering spec/ard.md and the schemas in spec/schemas/, must start as an issue. A maintainer lands the change once there is agreement. Everything else, including examples, conformance tooling, reference implementations, documentation and typo or link fixes, accepts pull requests directly. That is an unusual split and it has a clear cost: if you find a genuine error in a schema, you cannot just send a patch, you have to open an issue and wait for a maintainer. The benefit is that every normative change has a rationale on record, which is what you want from a standard several parties implement. For a team that only consumes the schemas, the practical effect is that bug reports about the specification travel a slower path than bug reports about the tooling.

Where ARD is the wrong tool

If you need a registry running this afternoon, ARD does not give you one. The repository has no server and no hosted service, so the discovery service itself is yours to build. If your resources are internal and your clients are all yours, a private catalog with a schema you control will be faster to ship and easier to change, because ARD's value comes from other parties agreeing to the same format. If you only need to expose a handful of MCP servers to one agent, a static configuration file is simpler than a federated discovery protocol. The specification also does not settle trust for you. Domain anchoring gives a client something to check, but the README does not document a trust model, a signature scheme or a revocation path, so any deployment has to decide those questions itself. That is the largest gap between the specification and a production system.

How ARD differs from a single central registry

The obvious alternative is one central registry that every resource registers with, which is what most plugin and tool directories do. The difference is architectural. A central registry gives you one query endpoint and one availability guarantee, and it gives its operator control over what is listed and how ranking works. ARD inverts that. Discovery services can be operated by different parties and clients query across them, with domain anchoring used to establish where a listing came from. You trade a single point of failure and a single point of control for the problem of reconciling answers from services that may disagree, may be stale, or may not be reachable. The README does not describe how conflicting listings are resolved, so that reconciliation logic is left to implementers. That is the honest trade: federation removes the gatekeeper and hands you the consistency problem.

Licence and the questions a new implementer asks

The repository is licensed under Apache-2.0, and the README defers to the LICENSE file rather than restating terms. Apache-2.0 is a permissive licence with an explicit patent grant, which is generally what you want when you are building an implementation and shipping it. It does not oblige you to publish your discovery service. The schemas under spec/schemas/ sit inside the same repository, so the same licence covers them unless the LICENSE file says otherwise, and you should read it rather than assume. This is not legal advice. On maintenance, the last push was on 2026-09-12, and the repository is not archived, so the specification is being worked on. That is not the same as a stable interface, and the version number tells you the authors agree.

Editorial conclusion

Adopt ARD if you are building or operating a discovery service and need a shared vocabulary for MCP servers, A2A agent cards, Skills and APIs, and if you are willing to track a v0.91 document that can still change. Do not adopt it if you need a working registry today: the repository holds the specification, schemas, architecture decision records and conformance tooling, not a deployed catalog. Before committing, read spec/ard.md end to end, check that the CDDL, JSON Schema and OpenAPI definitions under spec/schemas/ agree with the prose you rely on, and open an issue for any normative change you need, since pull requests are only the accepted route for non-normative work.

Frequently asked questions

Official sources

1. ards-project/ard-spec on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README