Evidence note: this article rests on primary publisher material — the project pages and repositories that publish Agentic Resource Discovery themselves, plus one vendor announcement from Amazon Web Services — read in mid-October 2026. Material published by a party about its own work is treated as evidence of what that party claims, not as confirmation that the claim holds. No independent reporting, third-party audit, or benchmark reproduction corroborating any part of the discovery stack was located while preparing this piece, and no test was run for it. Specific figures carry their evidence level inline.
Key finding: across the whole Agentic Resource Discovery stack as it is published today, exactly one quantified performance number is available — and it belongs to a storage layer, not to the ranking step. It measures retrieval recall under filter ordering, not whether a ranked list of tools is ordered correctly.
The step before invocation
Agentic Resource Discovery describes a step most agent integrations currently skip. Instead of an agent arriving at runtime with a fixed list of tools compiled into it, the client first asks what is available and receives a set of candidate resources back, ranked. Invocation happens afterward, against something discovery selected.
The architectural argument is easy to follow: a hard-coded tool list goes stale the moment a server adds, renames, or withdraws a tool, and it cannot represent resources the developer did not know existed when the code was written. A discovery call moves that problem to runtime. The description of what the protocol proposes here is drawn from the project’s own published material (agenticresourcediscovery.org, ards-project/ard-spec); the sources available do not include an independent review of the specification’s design.
Where the specification is actually written down
The normative material is published in two places that belong to the same effort: a project site at agenticresourcediscovery.org, and a specification repository at ards-project/ard-spec. Those are the addresses to read first, because the name is not confined to them.
Two further repositories carry essentially the same name: neuronto/agentic-resource-discovery and api-evangelist/agentic-resource-discovery. That multiple independently published repositories exist under the Agentic Resource Discovery name is attested by the repositories themselves — the pages are there to open. What remains open is the relationship between them: no governance document, cross-reference audit, or independent account of how the three projects relate was found, so a reader should not assume that one is the canonical home of the other two, or that any of them has ratified the others.
Three repositories, three different jobs
Separating them by function is the single most useful thing a developer can do before writing any integration code. On the evidence available, they do not do the same job:
- The specification.
ards-project/ard-spec, paired with the project site, carries the written protocol. - An index with a benchmark attached.
neuronto/agentic-resource-discoveryis published as an index — an operating service layer over registries, rather than a document describing one. - A third-party profile.
api-evangelist/agentic-resource-discoveryappears to be a profile of a public API surface authored by API Evangelist rather than by the specification’s maintainers. That reading comes from the repository’s own framing and is not independently confirmed; whether it is genuinely arms-length from the specification effort, and what it commits to maintaining, are open questions on the available sources.
A specification, a running index, and an outside commentary’s profile of an API surface imply three different trust models. Reading one as evidence for another is the mistake the shared name invites — the same failure mode as in a previous PlayAgit analysis of two repositories claiming the same four platforms, where only one of them was the thing the name implied.
What the Neuronto index says it indexes
The index project describes a feature set with three load-bearing parts: federated search spanning public Agentic Resource Discovery registries, a tool index built by reading each MCP server’s own tools/list response, and hybrid retrieval combining lexical and semantic matching (project repository).
This section carries the article’s strongest reservation. Every element of that description is the project’s account of its own system, and none of it is independently corroborated: no third-party coverage of the index’s registry coverage, no external measurement of the hybrid retrieval, and no outside confirmation that the tool index is populated the way the description says. Whether the federation reaches every public registry — as opposed to a subset — is likewise open. The reader should treat the feature list as a statement of intent that happens to be checkable, not as a verified capability.
A benchmark published by the party being benchmarked
ARD-Bench appears alongside the index as part of the same project (project repository). That the benchmark and the indexed service it measures come from one publisher is itself a finding, and it is not independently confirmed — sources do not establish ARD-Bench’s methodology, its task set, what baselines it compares against, or whether any party other than its publisher has run it.
The existence of a benchmark is a genuine positive signal; most discovery-layer projects do not ship one at all. But a first-party benchmark establishes that the publisher has defined a measurement, not that the measurement has been passed under scrutiny. Until someone outside the project reproduces it, ARD-Bench numbers should be read as self-reported.
Why ordering is not a detail for a two-person team
For a solo developer, the discovery layer is not one component among many — it is a filter on reality. The agent only ever sees what discovery returned. A resource ranked tenth in a list the client truncates at five does not exist from the model’s point of view, and nothing downstream will report its absence as an error. Misordering produces silent capability loss, which is the hardest class of bug to notice without a baseline to compare against.
That exposure is growing rather than shrinking as managed agent platforms take over the invocation layer — the direction visible in reporting such as this site’s earlier coverage of managed agents in Amazon Bedrock. The less of the loop a small team writes itself, the more of its behaviour is decided by a ranking it did not produce and cannot inspect.
The one quantified figure in the stack belongs to storage
Amazon Web Services announced that S3 Vectors now supports metadata pre-filtering: filters are evaluated before similarity search rather than after, and the announcement states this delivers up to 5x higher recall on filtered searches, targeting retrieval-augmented generation, agentic applications, and document search (AWS’s own announcement). The figure is a vendor self-report — AWS’s own post, with no workload, dataset, filter selectivity, or index configuration independently verified — and no third-party reproduction of it was found.
The mechanism is nonetheless intelligible and matters for anyone assembling a discovery layer on object storage. Post-filtering retrieves a fixed number of nearest neighbours and then discards those failing the metadata predicate, so a selective filter can empty most of the result set. Pre-filtering restricts the candidate space first, so the same budget of neighbours is spent entirely on eligible records. Developers weighing storage choices underneath a retrieval layer may find the related trade-offs in this site’s earlier piece on agent discovery and data access relevant.
Two measurements that are easy to mistake for one
Here is the distinction that reorganises the whole picture. The 5x figure is about retrieval recall under filter ordering: of the records that satisfied the predicate and should have been returnable, how many survived to the result set. It says nothing about whether the records that came back were ordered sensibly for the agent’s purpose.
Ranking quality is a different measurement entirely. It asks whether the most appropriate tool appeared above the less appropriate ones — which requires relevance judgements, a task set, and an agreed notion of correct order. Recall can be perfect while ranking is useless: return every eligible tool, in an order that puts the wrong one first, and a top-1 client fails on a technically complete result set.
So the published stack divides cleanly. The layer with a number attached measures completeness of candidate sets. The layer that decides what the agent sees — the ordering — has no independently measured number at all. A platform describing a change in one of these as an improvement in the other is the pattern examined in this site’s report on GitHub’s less precise Actions run counts: the figure moved, but not the thing a reader assumed it tracked.
What a self-reported tool list can and cannot establish
Reading each MCP server’s own tools/list is the only verification mechanism the index describes, and it is a real one — far better than a hand-maintained catalogue, because it is pulled from the authority that actually implements the tools, and drift between catalogue and server shows up as a changed response.
Its limits are structural, not incidental. A server’s tools/list is authoritative about what the server declares; it cannot attest that a declared tool works, that its description matches its behaviour, or that its stated parameters are the ones enforced. Nor does freshness follow automatically: how often an index re-reads each server, and what it serves in the interval, are not established by the sources available here. Verified-at-the-source and verified-as-correct are different guarantees, and only the first is claimed.
A proposed check, not a result
One experiment would settle the most practically useful open question, and it has not been run — what follows is a proposal, offered so that a reader with a registry snapshot can run it before trusting anyone’s ranking.
The proposed design: take a point-in-time snapshot of a public registry’s resource set with metadata intact; define a set of realistic discovery queries, each paired with a metadata predicate a client would plausibly apply (protocol, capability, licence); establish ground truth by exhaustively evaluating the predicate across the full snapshot, since at snapshot scale the complete eligible set is computable rather than estimated; then measure recall at a fixed result budget twice — once filtering before similarity search, once after — and report the gap, with filter selectivity recorded per query, because selectivity is where the gap should vary most. Sample size, embedding model, index parameters, and snapshot date would all have to be published for the result to mean anything, along with the failures.
No figures from this design appear anywhere in this article, and none should be inferred from it. It is a method a reader can execute, not an outcome.
Developer takeaway
For a one- or two-person team wiring an agent to several MCP servers, the defensible position today separates the structural change from the quality claims:
Adopt the client-side discovery call. Replacing a compiled-in tool list with a runtime query is sound architecture on its own merits, independent of any ranking quality — it removes the staleness class of bug, and it is reversible. Read the protocol from the specification repository and project site, not from the similarly named repositories.
Treat the rankings as unaudited. No independent measurement of discovery ordering was located. Do not let a ranked list silently truncate: log what discovery returned, keep the full candidate set rather than only the top result, and apply the team’s own relevance check before invocation. Where an index’s position matters to correctness, verify against the server’s tools/list directly — the one mechanism in the stack that is checkable from outside.
Keep the layers straight when budgeting. Pre-filtering in the storage layer addresses candidate-set completeness, per AWS’s own announcement; it is not a fix for bad ordering. Teams with no budget to host a registry can consume a public index while owning the final selection step — the smallest piece to keep in-house, and the one with the least evidence behind it if handed away.
The open question worth carrying forward: will anyone outside the projects publishing Agentic Resource Discovery reproduce a ranking measurement? Until that exists, the stack’s only number describes the floor the results arrive on, not the order they arrive in.