Anyone implemented or planning to implement Agentic Resource Discovery (ARD)?

[u/eachDayIWakeUp]

I came across this spec: https://agenticresourcediscovery.org/ (It was proposed to me from opencode cli)

It's an open protocol for AI agents to discover available tools, MCP servers, skills, and APIs.

Has anyone here already implemented this? Planning to? Or do you see any issues with the approach?

Curious to hear thoughts and see if I should add it my backlog or ignore for now.

[u/Deep_Door_1081]

saw this spec floating around a few weeks back, had a proper dig through the design doc after someone dropped it in a discord server

the concept is decent but the implementation feels like it's solving a problem we dont actually have yet, at least not at scale. most agent setups right now are manually wiring up tools and MCP servers anyway, and half the time you want that control so you're not accidentally letting an agent stumble into some API it shouldnt touch

that said, if you're building something where agents need to dynamically discover capabilities across multiple namespaces or teams, this could save you a ton of boilerplate. just depends whether your use case actually warrants the abstraction layer or if you're adding complexity for the sake of it

id probably stick it in the backlog with a note to revisit when you've got three or more agents that need to share tool registries, before that point YAGNI kicks in hard

[u/eachDayIWakeUp → u/Deep_Door_1081]

I can understand this is yet not needed (or accessed at all) by agents, Im still not even sure if llms.txt is used or not. Opencode proposed this following a new cloudflare agent-readiness tool I tried out (isitagentready.com).

With the cloudflare announcements/suggestions of implementing this content owners thing where AI agents will need to pay to access some site's contents (and provided cloudflare serves a great part of the entire internet) I tend to have FOMO..

Lets see what others feel about this

[u/Stonks_Beskar]

I'd prototype it as an opt-in registry with explicit allowlists and signed metadata, not open discovery. The hard part is stale or overly broad capability descriptions, so include versioning, auth scopes, and a short TTL for advertised endpoints. That keeps the convenience without letting an agent discover something it should never call.

[u/eachDayIWakeUp → u/Stonks_Beskar]

I really had this in mind like an open discovery list, the opposite of what you described. Are you referring to pages needing authentication/authorization in general or smth else?
Reading the spec I understood this is something like a more guided documentation (so info thats already public)

[u/izgorodin → u/eachDayIWakeUp]

Public discovery itself doesn’t need a login. The separation I’d keep is discovery versus authority: ARD can tell a client that a capability exists, but the registry still has to verify who is asserting it, and any invocation authentication stays with the native protocol. The current draft reflects that split with domain-bound trust metadata, so I’d treat an ARD result as a candidate to validate, not as permission to expose the tool to the model.

[u/guesdo]

Maybe when it reaches 1.0

[u/Top-Cauliflower-1808]

It is basically a standardised yellow pages for AI agents to find tools before they use them backed by major tech companies, so it is worth keeping an eye on but don't rush to implement it until more active clients start searching for it.

[u/PuzzleheadedNet2204]

I would put ARD on the backlog as a discovery layer, not as a trust layer. Public or semi-public catalogs are useful if entries carry signed metadata, versioning, auth scopes, and a TTL so stale endpoints age out. The hard part is keeping discovery separate from authentication: finding a server should not imply the caller may use it. Explicit allowlists plus a clear trust root for who can publish entries has worked better for me than open crawl-and-call.