Google·Microsoft ARD commentary: Why AI agents should design discovery, verification, and registry boundaries first rather than adding more MCPs

Publication date: 2026-06-20 | Category: AI News

\n \n \n

1) One-line problem definition

Key summary: As the number of AI agents increases, the question shifts from “Can you call a tool?” to “Which tools can you trust and find and use?”

AI Times reported on June 20, 2026 that Google, Microsoft, Salesforce, Snowflake, ServiceNow, etc. are promoting the AI ​​agent connection standard Agentic Resource Discovery, or ARD for short. As of the original publication, ARD is an open draft specification for cataloging and searching external capabilities such as agents, MCP servers, A2A agents, APIs, and skills.

The target readers of this article are developers and team leads who create or operate in-house AI agents, MCP servers, business automation tools, and Copilot-type products. The scope is not a summary of the ARD presentation. We cover why ARD came out, how it is different from MCP·A2A·OpenAPI, and what companies should fix first when designing a small registry.

Conversely, ARD will not be viewed as a complete standard for integration of all agents right away. The official specifications are v0.9 Draft / Proposal as of May 28, 2026. The necessary attitude at this stage is to read the signs that a “discovery layer” needs to be designed separately rather than a full-blown adoption.

2) Conclusion first

Key summary: ARD is not a replacement for MCP, but a search/verification layer that goes through before finding MCP servers and agents.

• Team to review now: Team where MCP servers, in-house APIs, workflows, and agents have increased, making it difficult for people to remember which functions are where
• Teams with better observations yet:Early PoC teams making fixed calls to only 3-5 tools within a single app
• My judgment: The core of ARD is not the promotional slogan “Automatically connects AIs.” What it really means is that takes the agent tool selection out of the prompt context and moves it to the search/policy/trust layer

To put it simply, if MCP is an electric plug, then ARD is closer to “an address book and search engine that finds which outlets in which buildings are approved.” Plug specifications alone are not enough. When your organization has hundreds of outlets, you need to know which outlets can be used, who manages them, and when they were last updated.

Therefore, I view ARD not as model competition news, but as Agent operation infrastructure news. The AI ​​agent team of 2026 will need to have “the ability to find only approved tools at the moment of need” rather than “the ability to add a lot of tools.”

3) Core structure decomposition

Key takeaways: ARD is divided into five pieces: catalog, registry, search API, trust metadata, and native execution protocol.

3-1. ai-catalog.json: List of capabilities released by the organization

ARD is a catalog located on a well-known path, such as /.well-known/ai-catalog.json. This file contains agents, MCP servers, APIs, skills, and other catalogs provided by your organization. Each item can have identifier, displayName, type, url or data, description, tags, representative query, and trust metadata.

3-2. Registry: Search engine for AI

The registry crawls multiple catalogs or takes an internal inventory and indexes them. When a user asks “analyze sales outliers,” the agent sends a search to the registry instead of putting all the tooltips in the prompt. The registry returns a ranking of relevant financial analysis agents, database MCP servers, and approved reporting APIs.

3-3. Search API: Discovery is tailored to REST criteria

specification requires that registries provide a standard HTTP REST search interface. You can run it using your own method, such as MCP, A2A, REST, or workflow engine. However, the design requires a common standard that any client can access at the discovery stage.

3-4. Trust metadata: “I found” and “I believe” are different

ARD allows storing trust information such as domain-based identifiers, DIDs, and SPIFFEs. The reason it's important is simple. It is risky for agents to connect directly to a tool just because they found it in the search results. You need to check who posted it, what domain it is tied to, and what authentication/audit information it has.

3-5. Native protocol: After discovery, execute in the original way

ARD is not an executable runtime. The official documentation also states that ARD does not replace MCP, A2A, Skills, or API runtime. ARD is a layer that finds “what to write” before calling, and the actual call is made using the native protocol of the resource.

4) Explanation of design intent

Key takeaways: The design intent of ARD is to end the practice of endlessly stuffing tooltips into context windows.

Many agent apps now rely on prompt context for tool selection. Give the model a complete list of available tools and descriptions, and let the model choose one of them. If you have 5 tools, that's fine. However, as the number of in-house APIs, MCP servers, automation workflows, and external SaaS agents grows to hundreds, this approach quickly reaches its limits.

ARD spec clearly addresses this issue. Putting all tooltips in a context window does not scale and requires moving the discovery problem to a dedicated search service outside of LLM. Search services can utilize signals such as representative queries, publisher identity, compliance metadata, and usage patterns, without continuously consuming model context tokens.

What you get here are three things. First, as the tool list grows, it pollutes the model context less. Second, organizations can manage through policies which tools appear in search results. Third, agents can break away from the App Store-style structure of only using installed tools and find approved features at the moment they are needed.

An alternative is to give up. Because discovery registries control the results, who runs the registries and what ranking policies they use become new points of power. Even though ARD aims to be an open ecosystem, inside a company, “which public and private resources will our registry index” determines both security and productivity.

5) Evidence and comparison

Key takeaways: ARD's competition is not MCPs, but manual installation, in-house wikis, and closed tool lists for each platform.

Google Developers Blog explains that ARD publishes a catalog under an organization's domain, a federated registry indexes it, and search results include verifiable trust metadata. In the same vein, Microsoft explained that GitHub's agent finder finds MCP servers, skills, tools, and agents at runtime on top of ARD and puts them into context only when needed.

Snowflake speaks more specifically about the benefits from a corporate perspective. Once the Cortex Agent created by the data team is registered, employees can find it in multiple interfaces, such as Snowflake CoWork, Microsoft Copilot, and your own apps, without having to know the name. However, the important lines in the Snowflake explanation are the same. The discovery service is not involved in the execution path, and authentication and data access are handled between the client and agent.

6) Actual operation flow / step-by-step execution method

Key takeaways: Small teams can start with “an internal catalog of five approved in-house MCP servers” rather than the enterprise standard.

Step 1. Divide resource inventory into three types

First, divide the targets that agents can call within the company. All three are sufficient: a read-only MCP server, a writable business API, and another agent or workflow. At this time, you must write down the owner, authority, risk level, and update date instead of “there is/is not there.”

Step 2. Create a minimum ai-catalog.json

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Internal AI Resources",
    "identifier": "did:web:ai.acme.com"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.com:mcp:sales-readonly",
      "displayName": "Sales Readonly MCP Server",
      "type": "application/mcp-server-card+json",
      "url": "/mcp/sales-readonly.json",
      "description": "Read-only access to approved sales metrics and dashboards.",
      "capabilities": ["sales_metrics", "dashboard_lookup"],
      "representativeQueries": [
“Find this week’s sales outliers”,
“Check the conversion rate by customer segment.”
      ],
      "updatedAt": "2026-06-20T00:00:00Z"
    }
  ]
}

Step 3. Place policy filter before search

Even if you put all your resources in one registry, it shouldn't show the same results to all users. You should filter your search results by department, role, data class, and whether you have write permission. “Searchable” is different from “callable”

Step 4. Separate verification just before execution

Do not call the tool immediately after finding a search result. Immediately prior to execution, you should re-verify the domain, signature or trust metadata, permission scope, and risk level. In particular, write, delete, payment, distribution, and external sending functions must have a human approval gate.

Step 5. Leave a selection log

You must log what query the agent searched in which registry, what results it received, and why it selected a specific resource. When a failure occurs and it ends with “The model selected strangely”, it cannot be operated.

7) Mistakes/Pitfalls

Key takeaways: ARD adoption failures usually result from a lack of operational boundaries rather than specification implementation.

• Mistake 1: Misunderstanding ARD as an MCP replacement
  Prevention: In team documents, ARD is separated into discovery and MCP/A2A/REST is called invocation.
  Recovery: Catalog Each item specifies the actual execution protocol and the responsible person.
• Mistake 2: Trusting the public catalog as is
  Prevention: External registry results are essentially just candidates and must pass internal approval lists and trust metadata.
  Recovery: External resource call logs Checks, and unauthorized resources are blocked by the registry filter.
• Mistake 3: Just a pretty description and no representative query
  Prevention: Increase search quality by putting 2 to 5 actual business queries in each item.
  Recovery: Check the actual query in the agent failure log. Augment representativeQueries by selecting user questions.
• Mistake 4: Leaving the registry ranking policy as a black box
  Prevention: Internal registries use approval status, recency, risk, owner trust, and usage success rate as ranking signals. Document.
  Repair: Leave cases of incorrectly selected tools postmortem and adjust ranking rules.
• Mistake 5: Bundling search results and execution permissions at once
  Prevention: Separate discovery ACL and execution ACL.
  Recovery: Maintain search exposure but safely lack permissions at run time. Create a response path that describes

8) Strengths and limitations

Key summary: ARD is an essential layer when the agent ecosystem grows, but it is still a draft and security, evaluation, and operation are left to the team.

Strengths

• Context saving: Tooltips can be retrieved when needed rather than having to put them all in the model.
• Decentralized ownership: By putting your catalog under your organizational domain, you don't have to push all your tools into one central platform.
• Protocol neutrality: MCP, A2A, REST, skills, and workflows can be put into one discovery envelope
• Corporate Governance: Internal registries can display a mix of approved resources, selected vendor resources, and public resources.

Limit

• Draft Status: Since it is a v0.9 Proposal, type registration, tool ecosystem, and interoperability verification should be more mature.
• Security Not automatically resolved: Although ARD can contain trust metadata, the actual authentication, authorization, and auditing mechanisms must be implemented separately.
• Ranking Responsibility: Agent behavior changes depending on which resources appear on top, so the registry operator has a large responsibility.
• Quality assessment required: It is necessary to continuously evaluate whether the search results match the business intent and whether the selected tool was successfully implemented.

Counterexample: If only fixed tools are called within a single product, the difference in permissions for each user is small, and the number of tools is small, ARD is excessive. Conversely, if multiple teams are creating MCP servers, and Copilot, ChatGPT, Gemini, and their own agents need to find the same in-house functions, the ARD-style discovery layer should be designed now.

9) Points to study more deeply

Key summary: To properly understand ARD, you need to look at discovery, registry, trust, and ranking together rather than how to use MCP.

• ARD Specification: ai-catalog.json, POST /search, federation, trust Check the manifest structure.
• AI Catalog Standard: Let’s look at what media type and field the catalog item is expressed in.
• MCP and A2A: We need to understand which protocol the actual execution takes place after ARD finds.
• GitHub agent finder: View the flow of finding tools at runtime and injecting them into the context without putting all of them in advance.
• Enterprise search evaluation: You should measure search result hit rate, approval resource rate, execution success rate, and incorrect tool selection rate.

10) Execution Checklist + Author’s Perspective

Key takeaway: I see ARD as a signal not “There’s a new standard, let’s stick with it” but “Let’s manage our organization’s agent address book with code and policies”.

• Is the list of in-house agents, MCP servers, APIs, and workflows organized in one place?
• Does each resource have an owner, execution protocol, risk level, and latest update date?
• Are search availability and actual execution permissions separated?
• Do each resource contain 2 to 5 actual business questions as representative questions?
• Are external resources treated only as candidates after checking domain, publisher, and trust metadata?
• Do writing, deleting, distribution, payment, and external delivery tools have an approval gate before execution?
• Is it possible to reproduce through logs which search results the agent selected and why?
• Do the registry ranking criteria reflect approval status, recency, risk, and success rate?

Definition of Done: If the internal registry returns more than 80% of approved resources in the top 3 in 20 representative business queries, and the agent logs the reason for selection and execution permission checks, the first introduction can be considered a success. There is

My recommendation: The choice of waiting for ARD and doing nothing is not a good choice. What we need to do right now is not to declare a company-wide standard, but to organize the five MCP servers and agents within the team in the form of ai-catalog.json. In this small experiment, if “discovery, approval, and execution logs” are separated, it will not be shaken by GitHub Copilot, Microsoft Copilot, own agents, and external registries in the future.

Reference material

• AI Times - Google·MS announce AI agent connection standard 'ARD' (2026-06-20)
• Google Developers Blog - Announcing the Agentic Resource Discovery specification (2026-06-17)
• Microsoft Command Line - Introducing the Agentic Resource Discovery specification (2026-06-18)
• Agentic Resource Discovery Specification v0.9 Draft (2026-05-28)
• Snowflake - Exploring Agent Discovery and ARD (2026-06-17)