Theme
AI Resources
Agentic Resource Discovery
Agentic Resource Discovery, or ARD, is a draft specification for publishing, discovering, and searching agentic resources such as MCP servers, A2A agents, Skills, APIs, and workflows.
The current v0.91 proposal puts ARD entries in domain-hosted /.well-known/ard.json manifests or other advertised sources, then lets registries search them before a client uses the selected resource through its native mechanism. The older ai-catalog.json path remains an optional compatibility source. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.
What it is
A discovery layer for agent resources
ARD gives publishers a way to describe callable AI resources and gives registries a common search interface for returning matching capabilities before a client connects to the chosen tool or service.
Why it stands out
Discovery stays separate from invocation
ARD proposes a common way for registries to find and return agent resources while leaving credentials, permissions, safety checks, and execution to the systems that connect to them.
Availability
Draft spec plus implementation trail
Readers can inspect the ARD specification site, the public GitHub spec repository, Google and Hugging Face launch posts, and Hugging Face Discover as a working ARD client and server implementation.
Why it matters
What makes it useful
Agentic Resource Discovery tackles the step before an agent invokes a tool: how MCP servers, A2A agents, Skills, APIs, and workflows can be published, searched, and checked. Its draft status and Hugging Face implementation show both the proposal and an early working path without treating the standard as settled.
What to know
Where it fits
ARD is not an execution runtime, a central catalog, MCP, A2A, Skills, AI Catalog, or an API runtime. It is a discovery layer that points clients toward resources, while invocation, permissions, safety checks, and production review still belong to the systems around the selected resource.
Notable points
What stands out
The v0.91 proposal requires consumers resolving a domain to fetch /.well-known/ard.json and honour rel="ard" links. It keeps the older ai-catalog.json name as optional compatibility, and defines POST /search plus optional POST /explore and GET /agents endpoints, federation behavior, and trust metadata fields.
Implementation trail
How Hugging Face is testing it
Hugging Face describes Discover as a reference implementation that exposes ARD search over Hub Spaces, Agent Skills, and MCP servers, with REST and MCP access paths and filters for returned artifact types.
Before using
What to review
Current draft status, schema changes, issue discussions, conformance tooling, and repository updates before treating ARD behavior as settled.
Which registry or catalog is being queried, who operates it, what it indexes, and how its ranking, trust, and access policies work.
What publisher identity or trust metadata is actually present, and whether the client verifies it before connecting to a returned resource.
The native protocol, credentials, permissions, privacy terms, rate limits, and logging behavior of the resource after discovery hands off to invocation.
Whether ARD is being used alongside MCP, A2A, Skills, APIs, or internal catalogs rather than replacing those systems.
Reader fit
Who may find it relevant
Builders tracking how agents find tools, skills, and services across provider boundaries.
Teams comparing agent registries, internal catalogs, MCP servers, Skills, A2A agents, APIs, and trust metadata.
Builders who want a published specification and working reference implementation for testing discovery across agent formats.
Less relevant for readers looking for a finished consumer assistant, a model checkpoint, or a one-click decision about every returned tool.
Editorial note
Why LifeHubber lists it
ARD separates finding an agent resource from invoking it. Its draft specification and early implementation cover discovery across MCP, A2A, Skills, APIs, and registries while leaving permissions and safety checks to the systems that connect to the chosen resource.
Source links
Source materials
Reader note
Before relying on this entry
LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.
What to explore next
Decide what happens after discovery returns a resource.
ARD helps a client find agent resources, then hands off to their native tools and protocols. These links cover reviewing a discovered skill and examining policy controls around later agent actions.
More in AI Agents
Keep browsing this category
Explore more AI agent projects.
RAGFlow
infiniflow/ragflow
A self-hostable RAG and agent-context platform whose v0.27 line adds Knowledge Compilation, Agentic RAG thinking modes, document and data-source connectors, citations, APIs, and agent workflows.
Magnitude
magnitudedev/magnitude
An early open-source local inference server that profiles a computer, recommends model configurations that fit, downloads the selected model, and connects it to existing agent harnesses through local OpenAI- and Anthropic-compatible APIs.
Awesome GPT Image 2
freestylefly/awesome-gpt-image-2
A prompt-as-code library for GPT Image 2 with a categorized case gallery, reusable visual prompt templates, a live browsing site, and an installable agent skill for turning image ideas into structured prompts.
For project maintainers
Listed here? You can use the badge.
If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.
