Agentic Resource Discovery (ARD): A Practical Guide for AI Agents, MCP, and Skills

Direct answer

Agentic Resource Discovery (ARD) is an open discovery protocol for AI-facing capabilities. It lets an AI client search for a suitable MCP server, skill, agent, API, plugin, or workflow at runtime instead of requiring every integration to be hard-coded in advance. ARD does not execute the capability: after discovery, the client connects directly through the resource’s native protocol, such as MCP, A2A, or HTTP.

For developers, the practical starting point is a domain-hosted /.well-known/ai-catalog.json file. A registry can crawl that catalog, index its entries, return matches for a natural-language task, and pass back metadata that helps the client verify the publisher before connecting.

Key takeaways

• ARD is a discovery layer, not a replacement for MCP, A2A, Skills, or an API runtime.
• Providers publish catalogs under their own domains; registries search and curate those catalogs.
• Search results should be treated as untrusted suggestions until identity, endpoint, permissions, and policy are checked.
• The static catalog format is useful for small providers; registries add ranking, federation, and enterprise curation.
• ARD is most valuable when an agent has more possible capabilities than can be safely preloaded into its context.

Why agent discovery is becoming a systems problem

MCP standardizes how an AI host can call tools. A2A standardizes communication between agents. Skills package task-specific instructions. None of those interfaces, by themselves, answer the first operational question: which capability should an agent use for this task?

Today, teams often solve discovery with configuration files, marketplace pages, internal service catalogs, or a large list of tools placed into the model context. Those approaches work for a small, stable set of integrations. They become expensive when teams publish hundreds of internal agents, vendors expose changing MCP surfaces, or an enterprise needs to search only approved resources.

Google’s announcement describes ARD as an open way to publish, discover, and verify capabilities across organizational boundaries. Snowflake independently describes the same problem from an enterprise perspective: a client can search by intent, receive ranked resources and endpoints, then invoke the selected resource directly while the discovery service stays out of the execution path. Hugging Face provides a working implementation that exposes searchable Skills, Spaces, and MCP-enabled resources.

The important design boundary is discovery versus execution. Finding a tool must not automatically grant that tool permission to act.

The ARD request flow

The following diagram is an original implementation model based on the ARD specification and the provider documentation. It shows where discovery ends and authorization and execution begin.

Visual 1 — ARD discovery and execution boundary. The catalog and registry help locate a resource; the selected resource still owns its authentication and request handling. See the official ARD specification and Google’s announcement for the protocol model.

How the catalog works

A provider publishes a JSON catalog at a well-known path on its own domain. The catalog identifies the host and lists entries with fields such as a stable identifier, display name, media type, URL, and description. Entries may represent an MCP server, an AI Skill, an agent, an API, or a registry.

Hugging Face’s live catalog is a useful concrete example. It advertises a Discover Registry and an MCP server card, while DataRobot’s catalog lists task-specific Skills for model training, deployment, predictions, monitoring, explainability, and agent assistance.

A minimal provider catalog can look like this:

1{
2  "specVersion": "1.0",
3  "host": {
4    "displayName": "Example AI Platform",
5    "identifier": "example.com",
6    "documentationUrl": "https://example.com/agents"
7  },
8  "entries": [
9    {
10      "identifier": "urn:ai:example.com:mcp:analytics",
11      "displayName": "Analytics MCP Server",
12      "type": "application/mcp-server-card+json",
13      "url": "https://example.com/mcp/analytics",
14      "description": "Query approved product analytics and generate reports.",
15      "tags": ["analytics", "reporting", "mcp"]
16    }
17  ]
18}

Visual 2 — Catalog manifest example. This is an illustrative, non-production manifest showing the fields a provider needs to make one capability discoverable. Do not treat a catalog description as an authorization policy.

The provider should serve the file over HTTPS, keep identifiers stable, publish accurate descriptions, and link to documentation that explains authentication and permitted use. A registry may then crawl the catalog, apply its own inclusion rules, and expose a search endpoint.

Static catalogs versus registries

The specification separates a publisher’s catalog from the service that searches catalogs. That separation allows an organization to publish once while different registries apply different trust, ranking, compliance, or community policies.

Visual 3 — Responsibility comparison. Keeping these responsibilities separate reduces the chance that a convenient search result turns into an unreviewed capability grant.

A practical client-side discovery algorithm

A production client should make discovery an explicit policy pipeline rather than handing registry results straight to a model:

1. Normalize the task into a search request that does not contain secrets.
2. Query an approved registry or fetch a known provider catalog directly.
3. Filter by allowed media type, organization, environment, data classification, and protocol.
4. Validate the result’s identifier, HTTPS URL, documentation, and publisher metadata.
5. Apply allowlists and blocklists before the model sees the candidate.
6. Show a confirmation for write, delete, payment, credential, or external-message actions.
7. Connect through the native protocol and authenticate for the intended audience.
8. Log the selected resource, policy decision, version or digest when available, and outcome.

The client should pass descriptions and examples to the model as untrusted data. A result that says “ignore previous instructions” is still just a string returned by a remote system. It must not change permissions, expand scopes, or bypass user approval.

Security and governance checklist

ARD improves discoverability, but it also creates a new input surface. Treat catalogs, registry responses, documentation, endpoints, redirects, and tool descriptions as attacker-influenced until verified.

Verify identity and endpoint ownership

Prefer catalogs fetched from an organization’s expected HTTPS domain. Validate redirects, DNS resolution, IP ranges, and outbound access through an egress policy. Domain anchoring is useful evidence of control, but it is not a substitute for endpoint authentication or authorization.

Separate discovery from authorization

A registry may recommend a resource; it should not silently authorize the resource to access data. The resource server must validate the caller, token issuer, audience, scopes, tenant, and requested operation. For consequential actions, keep a human approval step in the host.

Pin what changes slowly

For internal deployments, maintain an approved registry list and pin important resources to an identifier, version, digest, or reviewed catalog snapshot where the implementation supports it. Re-check changes to descriptions and endpoints because metadata can influence model behavior even when the executable code is unchanged.

Limit capability and data exposure

Use separate credentials per resource and least-privilege scopes. Do not send the full conversation, unrelated files, or ambient production credentials to a newly discovered capability. Add request timeouts, response-size limits, rate limits, audit events, and a kill switch.

Test malicious discovery results

Include adversarial fixtures in client tests: a catalog with a private-network URL, a redirect to localhost, a misleading destructive description, an expired certificate, an unexpected token audience, and a result that attempts prompt injection. The expected outcome for each should be a clear rejection or an explicit approval request.

Example registry search with Hugging Face Discover

Hugging Face documents both a CLI and HTTP interface for its ARD implementation. The exact availability and response shape should be checked against the current documentation before production use, but the documented pattern is straightforward:

1uv tool install huggingface_hub
2
3hf discover search "Fine tune a language model"
4
5hf discover search "Generate an image" --json --kind mcp

For direct HTTP access, the documented endpoint accepts a natural-language query and filters. A client should still apply its own organization and security policy after receiving the response; registry ranking is not a security decision.

What ARD means for MCP developers

If you maintain an MCP server, ARD can make it findable without requiring every client vendor to add a bespoke integration. Start with a precise catalog entry and a documentation page that states:

• what the server does and does not do;
• which operations are read-only or mutating;
• authentication method, token audience, and required scopes;
• supported transports and version compatibility;
• data retention, tenant isolation, and rate limits;
• operational contact and deprecation policy.

Do not describe a broad capability as if it were narrow. “Manage infrastructure” is a poor discovery description when the server can delete resources. Make risky operations visible so clients can route them through stronger approval policies.

Common mistakes and debugging steps

The catalog returns 404

Confirm that the host serves the exact well-known path, uses the correct content type, and does not require a browser session or authentication for public discovery. Test from an external network and inspect redirects.

Search returns irrelevant capabilities

Improve descriptions with representative natural-language queries, explicit tags, supported inputs, and boundaries. Avoid marketing phrases that do not help an agent distinguish the resource from similar entries. Also check whether the selected registry is indexing stale data.

The client discovers a tool but cannot connect

Discovery does not guarantee invocation compatibility. Check the media type, endpoint URL, transport, protocol version, authentication metadata, token audience, tenant, and network egress rules separately. Record the failing stage rather than reporting a generic “tool unavailable” error.

A discovered resource behaves unexpectedly

Treat its metadata and results as untrusted. Revoke the resource from the allowlist, preserve the catalog and registry response for investigation, rotate any exposed credentials, and review whether the host incorrectly allowed model output to act as policy.

FAQ

Is ARD the same as MCP?

No. MCP defines a protocol for connecting an AI host to tools, resources, and prompts. ARD helps a client discover which capabilities exist. A discovered MCP server is still responsible for authentication and authorization.

Does ARD require a central marketplace?

No. The specification describes multiple discovery services with their own indexes and policies. Enterprises can run private registries, providers can publish catalogs on their domains, and public registries can federate where appropriate.

Should every AI agent discover tools dynamically?

No. Static configuration is often safer for a small set of sensitive, well-known integrations. Dynamic discovery is most useful when the capability set is large or changes frequently. Use it with explicit policy, provenance, and approval controls.

Can an ARD result be trusted because it came from a registry?

No. A registry is a source of candidates. The client and resource server still need to verify identity, endpoint, permissions, and request scope. Discovery without verification only makes it easier to encounter the wrong capability.

Conclusion

ARD addresses a real missing layer in agent infrastructure: finding the right capability before invocation. Its simple shape—a domain-hosted catalog plus searchable registries—means teams can adopt it without replacing MCP, A2A, Skills, or existing APIs.

The safe implementation is equally clear. Let registries help agents search, but keep authorization at the resource boundary. Verify publisher and endpoint metadata, constrain egress and credentials, make risky actions reviewable, and log why a capability was selected. The winning pattern is not “let agents call anything they can find.” It is “let agents find approved capabilities without making discovery itself a permission grant.”

Sources and visual credits

• Google Developers Blog: Announcing the Agentic Resource Discovery specification — primary announcement and architecture overview.
• Agentic Resource Discovery Specification — specification, terminology, and protocol boundaries.
• Hugging Face: Agentic Resource Discovery — Let agents search — independent implementation details, CLI, REST, and MCP examples.
• Hugging Face AI catalog — live catalog example inspected for this article.
• Snowflake: Exploring Agent Discovery — independent enterprise architecture and governance perspective.
• DataRobot: Agent Skills and MCPs through ARD — provider catalog example and adoption details.

The Mermaid architecture diagram and responsibility comparison are original editorial visuals by Essa Mamdani. The catalog JSON is an illustrative example; live catalog links above are credited to their respective providers.

Related reading

• MCP Developer Guide: Architecture, TypeScript & Python Examples
• MCP Security Threat Modeling Guide
• Harness Engineering for AI Coding Agents
• AI Tools Directory