The Anti-MCP Alliance Built a Protocol That Needs MCP to Work
Table of contents
The Headline
On June 17, 2026, Google published the Agentic Resource Discovery specification. Co-authored with Microsoft and Hugging Face. Backed by Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, ServiceNow, and Snowflake.
The framing from every tech outlet: a coalition to counter Anthropic and OpenAI. The anti-MCP alliance. The enterprise incumbents striking back.
There is one problem with that narrative. ARD does not replace MCP. It is not an alternative to MCP. It is a discovery layer that helps agents find MCP servers.
The coalition built infrastructure for the protocol they are supposedly fighting.
What ARD Actually Does
ARD solves one specific problem: how does an AI agent find the right tool at runtime without having every tool pre-loaded in its context?
The current model is static. A developer installs MCP servers, lists them in the agent's configuration, and the agent has access to those tools forever. Research shows this creates context pollution. Agents pre-loaded with 50+ tools consume 77,000 tokens before the task even starts. Dynamic selection cuts that to roughly 8,700 tokens. A 90% reduction.
ARD enables that dynamic discovery through two primitives.
First, a static manifest file. Organizations publish a manifest file called ai-catalog.json on their domain. Each entry describes one capability: an identifier, what protocol it speaks (MCP, A2A, OpenAPI), and a link to the resource.
Second, registries. Search engines that crawl published catalogs, index them, and expose a REST API. An agent can query: "find a tool that can book flights from SFO to JFK" and get ranked results.
Four discovery mechanisms: well-known URI, agentmap entry in robots.txt, HTML link tag, and DNS service binding records.
The spec includes trust attestations (SOC2, HIPAA, GDPR compliance) and cryptographic identity via SPIFFE or DID. Federation between registries is supported in three modes.
It is v0.9, licensed under Apache 2.0, and built on the AI Catalog data model from the Linux Foundation.
The Protocol Stack Nobody Is Explaining Clearly
Here is where the "anti-MCP" framing falls apart.
The agentic protocol stack in 2026 has three layers:
Layer 1: Tool Access. How an agent connects to and uses a tool. This is MCP. Anthropic published it in late 2024. By July 2026, it has 97 million monthly SDK downloads, 78% of enterprise AI teams have MCP-backed agents in production, and 28% of Fortune 500 companies run MCP servers. OpenAI adopted it. Google adopted it. Microsoft adopted it. It won.
Layer 2: Agent-to-Agent Communication. How independent agents coordinate with each other. This is Google's A2A protocol, published April 2025. Supported by 50+ enterprise partners. It handles task delegation, status updates, and result sharing between agents that may be built on different platforms.
Layer 3: Discovery. How agents find the right tool or agent at runtime. This is ARD. The new one.
ARD sits entirely before invocation. It finds the resource. Then the resource is called through its own native protocol. Which, in most cases, is MCP.
The spec's own ai-catalog.json example includes entries typed as MCP server cards. The ARD spec literally defines how to discover MCP servers.
This is not a counter to MCP. It is a complement. The framing as a competitive move is a story about corporate positioning, not technical reality.
Why the Coalition Exists Anyway
If ARD complements MCP, why did Google, Microsoft, and Salesforce coordinate a launch with twelve companies and frame it as a counter to Anthropic?
Because the real fight is not about protocols. It is about who controls the registry layer.
MCP is the plumbing. Everyone adopted it because it works and it is open. But whoever controls the search engine that agents use to find MCP servers controls which tools get selected. That is the business.
Google's implementation is the Agent Registry within the Gemini Enterprise Agent Platform. If Google's registry becomes the default, then Google Workspace tools get preferential discovery. Same logic for Microsoft with 365 and Salesforce with CRM.
The ARD spec itself is genuinely open. Apache 2.0. Federated. No single owner. But the registry implementations are where the lock-in happens. A world where AI agents automatically find and use Google Workspace, Microsoft 365, and Salesforce CRM is a world where those subscription revenues keep growing.
Anthropic and OpenAI are absent from the supporter list. Not because the spec is hostile to them, but because they do not need a discovery layer that favors incumbent enterprise software. Their models are the ones doing the discovering.
What ARD Misses
ARD solves the registry problem. But registry queries are the last step in how agents actually select tools.
The full sequence: Train, Search, Fetch, Environment, Registry.
ARD covers step 5.
The training prior is step 1. Agents in July 2026 operate on roughly five-month-old training data. If an agent already "knows" your product from training, it answers from memory. It never fires a registry query.
Web search is step 2. When agents break out of their training prior, they search the web first. Research shows agents surface 215 domains in a single research task but only fetch roughly 13 of them. A 6% open rate.
Environment files are step 4. A single AGENTS.md file in a project root can produce a 100% selection flip, overriding everything else. No registry involved.
ARD standardizes the last mile. The first four miles are where most decisions happen.
The imiel.dev Angle
I already ship agent discovery headers on imiel.dev. The middleware sends RFC 8288 Link headers pointing to well-known URIs for the API catalog, agent skills index, and MCP server card. The site exposes WebMCP tools for in-browser agents and supports markdown content negotiation for AI crawlers.
I did this months before ARD was published. Not because I anticipated the spec, but because the problem was obvious. If you build tools for agents, agents need to find them.
The interesting thing about implementing discovery early: it changes how you think about your entire content surface. Every blog post, every API endpoint, every structured data file becomes a resource that an agent might query. The line between SEO and agent optimization blurs. The skills are the same. The audience is different.
ARD formalizes what early adopters were already doing. That is the best thing about it.
The Real Takeaway
ARD is good infrastructure. The spec is clean. The federation model is sound. The trust layer with compliance attestations addresses a real gap. The representativeQueries field in catalog entries is essentially keyword research for the agentic web, and it will matter.
But the "anti-MCP alliance" narrative is wrong.
MCP won the tool access layer 18 months ago. ARD does not challenge that. ARD builds on top of it. The coalition is not fighting Anthropic's protocol. They are fighting over who controls the search engine that sits in front of it.
The protocol wars are over. MCP is the standard. A2A handles agent coordination. ARD handles discovery. They are complementary layers, not competitors.
The business war over registry control is just starting. That one will be interesting.
But do not confuse a business positioning story with a technical one. The twelve companies that launched ARD built a discovery layer for Anthropic's protocol. That is the fact the headlines missed.