On June 26, 2026 Cisco, Google, Microsoft, GitHub, Hugging Face, NVIDIA, Salesforce, ServiceNow, Snowflake, Databricks, and GoDaddy jointly published the Agentic Resource Discovery (ARD) specification. The latest smol.ai AINews issue led with it because ARD answers a question every team building AI agents has been quietly piling up tickets about: how does an agent find the right MCP server, tool, or sub-agent at runtime instead of having all of them hard-coded into the prompt. For teams shipping mobile apps, n8n automation, and AI agent orchestration like the work we do at Halmob, ARD is the missing piece between MCP and a stack where agents can grow without a context-window rewrite.
The release matters for a specific reason. Until now, "giving an agent a new tool" meant editing a system prompt or a tool registry inside the application. That stops scaling the moment your organisation has more than a handful of MCP servers. ARD moves the selection problem out of the LLM context and into a dedicated discovery service that any agent can query the same way a browser queries DNS. The agent asks what is available for this task, ARD returns a ranked list of agents, MCP servers, skills, APIs, or workflows, and the agent invokes the one it picked using that resource's own protocol.
The 30-Second Version
What ARD Actually Is
The cleanest way to think about ARD is as DNS for agentic capabilities. DNS does not run your web request — it returns the address. ARD does not run the tool — it returns the description, endpoint, and metadata. The agent then invokes the resource through whatever protocol that resource speaks, which today is most often MCP, but is allowed to be a direct API, an A2A agent endpoint, or a workflow trigger.
Three concrete pieces ship with the spec:
- A resource manifest format. Publishers describe what they offer — name, capability, inputs, outputs, auth, invocation protocol — in a standard JSON shape that registries can index.
- A discovery query API. Clients send a natural-language or structured task description and get back a ranked, paginated list of resources, with the metadata needed to call them.
- A federated registry model. Registries can mirror, cross-reference, and delegate to each other, so a company can run a private internal registry that fronts both internal tools and the public ARD network.
The first reference implementation that ships with public momentum is GitHub Agent Finder, an ARD-backed service that lets GitHub Copilot dynamically discover and call the right MCP servers, skills, tools, and agents at runtime. Hugging Face has announced an ARD index of its agent and tool registry. Cisco's Outshift team is running a public test registry. Microsoft is folding ARD into the Command Line agent stack.
Why It Is Not Just a Better Tool List
Today's standard pattern is to inject every tool description into the LLM's context window and let the model pick. That works at ten tools. It breaks at a hundred, and it is a non-starter at the thousands of MCP servers Anthropic, Microsoft, and others have been publishing this quarter. The model spends most of its context budget reading tool descriptions it will never call.
ARD moves the selection problem outside the LLM into a dedicated search service. Information retrieval is a solved problem at the scale ARD targets — embeddings, BM25, hybrid search, re-rankers all apply directly. The agent gets a shortlist of five matching resources instead of a manifest of five thousand, and the saved context is real money on every call. The same architectural insight the team behind Sakana Fugu made for model selection — keep it out of the prompt, train a small specialised system to decide — ARD makes for tool selection.
ARD is to MCP what DNS is to HTTP. MCP defines how the agent calls the tool. ARD tells the agent which tool to call.
How ARD, MCP, and a Hand-Written Tool List Compare
| Approach | Where the tool list lives | What changes when a new tool ships |
|---|---|---|
| Hand-written tool registry | Inside your application code or system prompt | Engineer adds the tool, retests prompts, redeploys |
| MCP server only | Each MCP server published independently, client must know URLs | Operator hard-codes the new MCP server URL into the client |
| ARD-indexed registry | A discovery service the agent queries at runtime | Publisher adds the manifest; every agent on the network finds it |
| ARD + private federation | A private registry mirroring internal + public resources | Internal tools land in the private index; public tools inherited from the federated network |
The right row depends on how many resources you expect to maintain. A two-tool prototype does not need ARD. A platform team with a hundred internal MCP servers, an evolving partner catalogue, and a handful of agents calling them all is the case ARD was written for. It pairs cleanly with the cataloguing pattern we covered in the Agentic AI Foundation piece, where the AGENTS.md proposal asked the same question one level down: how does the agent know what the project itself offers.
The Spec at a Glance
Resource manifests
Every publishable resource — an MCP server, an API endpoint, a skill, a workflow, an agent — gets a JSON manifest with a canonical schema: identifier, human-readable name, capability descriptions, supported tasks, input/output schemas, auth method, invocation protocol, and metadata for ranking (latency, cost class, region, freshness, owner). The manifests are designed to be machine-readable for indexing and human-readable for review.
The discovery query
Clients send either a structured query (task type, required capability, constraints) or a natural-language task description. The registry runs information retrieval over the manifest index and returns a ranked list. Pagination, filtering, and cursor semantics are part of the spec, so a discovery call does not blow up into a giant payload. The shape is intentionally close to standard search APIs — there is no new query DSL to learn.
Federated registries
A registry can delegate, mirror, or proxy other registries. The private-plus-public split is first-class: a company runs an internal ARD registry that publishes its private MCP servers, mirrors a curated subset of the public network, and presents one query endpoint to its agents. That layout maps onto the same control plane we sketched in the Microsoft Scout always-on agent piece, where governance for what an agent can see lives in the org boundary rather than the prompt.
Trust and verification
Resources can be signed by their publishers, and registries can mark manifests as verified, sandboxed, or unverified. This is the part the spec authors flag as still evolving — the early consensus is that signature + provenance metadata gives clients enough to refuse unsigned resources in regulated workloads, with a fuller trust model arriving in a follow-up draft.
Why It Matters for Mobile and Automation Teams
Two patterns that land on Halmob desks every week look noticeably different the day after ARD adoption. The first is a mobile app that calls an agent backend with a fixed tool list. The second is an n8n workflow whose AI node has been pinned to a fixed set of integrations because changing it is a release-day risk. Both can move to ARD-backed discovery without rewriting the downstream behaviour, because the agent keeps invoking tools the same way — only the selection step changed.
For mobile in particular, the win is that the available tool set can grow without an app update. The phone never sees the tool catalogue. It calls a server-side agent endpoint. The server queries ARD, the registry returns whatever is available today, the agent calls it. New capability ships at the registry, not at the App Store. That pairs naturally with the server-owned loop pattern we walked through in the loop engineering piece: the phone is the surface, the loop is the server, and the server can pick up a new tool the same day it is published.
For n8n automation, ARD drops in as a new node type: query the registry, get a resource, invoke it through the existing HTTP, MCP, or A2A connectors. The same workflow that used to call three hard-coded integrations can route to whichever resource currently best matches the task — provided your team owns the registry, signs the manifests, and treats the discovery step the way it would treat any other request that influences a business decision.
Where ARD Fits in the 2026 Agent Stack
ARD does not replace the rest of the stack. It collapses one layer of it — capability selection — into a query against a search service. The other layers remain exactly where they were.
| Layer | What it owns | Where ARD sits |
|---|---|---|
| Application loop | Retries, schema validation, durable state | Above ARD — you still engineer this loop |
| Capability selection | Which tool, MCP server, or sub-agent should handle this task | Replaced by an ARD query |
| Invocation | Actually calling the tool over MCP, REST, or A2A | Untouched — ARD returns endpoints, the agent calls them |
| Model selection | Which LLM answers the prompt | Untouched — that is the Fugu/Conductor problem |
| Distribution | Mobile app, webhook, chat surface, voice | Untouched — ARD is one server-side dependency |
That layout pairs cleanly with the orchestration patterns we covered in the Cognizant Neuro + ServiceNow write-up and the executor/advisor split in the executor-advisor pattern piece. ARD is the "which resource" lookup that sits in front of those graphs, not the graph itself. For the MCP layer underneath, our take in the WebMCP implementation guide is still the cleanest starting point on the invocation side of the line.
The Failure Modes Worth Designing Around
- Registry poisoning. If anyone can publish a manifest, an attacker can publish a resource that ranks well for a sensitive task and steals data on invocation. Treat the registry the way you treat a package index: signature verification, allow-lists, and provenance metadata on every entry you act on.
- Stale or wrong rankings. A discovery service that returns a resource which is offline or deprecated turns the agent into a flaky client. Bake liveness checks, freshness scoring, and a fallback registry into the loop.
- Cross-tenant leakage. A federated registry that mirrors a private index into a public query path is a confidentiality bug waiting to happen. Keep private indices behind auth, and never mirror private manifests into a public delegate.
- Cost surprises from cascading discovery. Each query is a search request. An agent that retries discovery on every sub-task can drive a non-trivial registry bill. Cache lookups per session, and treat ARD calls as instrumented telemetry the same way you treat LLM calls.
- Latency added before invocation. Discovery adds a hop. For latency-sensitive paths — voice, on-device agents, real-time control — pre-resolve at session start rather than per-step.
- Vendor capture of the index. If one registry becomes the only place anyone publishes, the "federated" promise quietly evaporates. Run a private mirror, even if your public traffic goes through a vendor index.
A Practical Adoption Plan for Existing Workloads
- 1Pick the agent whose tool list is hardest to maintain. The one your team rewrites every quarter because a new MCP server or API has to land is the right starting point.
- 2Stand up a private ARD registry. Index your own MCP servers, internal APIs, and sub-agents first. Run it inside your VPC. This is the cheapest, lowest-risk way to learn the spec.
- 3Shadow-mode the discovery step. Have the agent run its existing hard-coded selection, log what ARD would have returned, and compare. A week of shadow data shows where the registry adds value and where the current list is already good enough.
- 4Promote discovery on low-stakes flows first. Internal summaries, draft generation, classification. Keep the money paths on the pinned tool list until you have telemetry.
- 5Federate to a public registry behind a policy filter. Only when discovery on private indices is stable. The filter enforces signature, owner allow-list, and freshness rules at the registry boundary, not in the agent.
- 6Document the contract you depend on. "We call ARD with this query shape, we accept resources matching this policy, we invoke them through MCP or HTTP." That sentence is your spec. If it breaks, you know what to rebuild.
When to Adopt ARD, When to Stay With a Static List
How It Fits the Halmob Stack
Most of what we ship at Halmob is the layer above the protocol: a mobile app talking to an n8n workflow that drives an AI agent, and increasingly a fleet of MCP servers and sub-agents underneath. ARD slots into that picture in exactly one place: in front of the tool registry that used to live in the agent prompt. The day after adoption, "adding a tool" is a registry operation, not a release. The day after that, the registry becomes the place where governance, allow-lists, and provenance actually live.
For iOS and Android teams the immediate move is to keep the phone dumb and put the registry behind a server-side agent endpoint. The phone calls the endpoint. The server queries ARD, picks a resource, invokes it. That single seam is what makes the next MCP server adoption a configuration change instead of an App Store submission. For OpenClaw consultancy engagements, ARD is the layer that lets a private agent stack inherit a curated slice of the public agent ecosystem without inheriting its risk.
The Bottom Line
Agentic Resource Discovery is the first cross-vendor attempt to give agents a shared way to find capabilities at runtime. It is open-source, Apache-2.0, and backed by the same lineup of vendors that signed MCP — Cisco, Google, Microsoft, GitHub, Hugging Face, NVIDIA, Salesforce, ServiceNow, Snowflake, Databricks, GoDaddy. For mobile, n8n, and agent orchestration teams the practical effect is that the tool list stops being a release-day artifact and becomes a query against a search service.
The right question for the next sprint is not "should we move every tool into ARD." It is "which of our agents would behave better if its tool list could grow without a redeploy." At Halmob we pair mobile development with n8n automation and AI agent orchestration for teams that want the answer to that question to be most of them.
For sources, see the smol.ai AINews newsletter coverage of the June 26 release, the official ARD specification site, the Google Developers Blog announcement, the Microsoft Command Line write-up, and the ards-project/ard-spec repository on GitHub.