Emerging Protocols Checker

Probe a domain for OAuth metadata, API discovery, A2A, MCP, Agent Skills, ARD, auth.md, WebMCP and agentic commerce protocol signals.

Enter any public page. The checker resolves its origin and probes documented discovery locations.
This is a discovery audit, not a compliance certificate. Missing experimental protocols are not automatically problems.
Run the broader Site Agent Readiness Checker →

What this checker adds beyond a basic protocol probe

  • Separates IETF RFCs from standards, drafts, proposals and operational ecosystem protocols.
  • Checks nine domain-level discovery surfaces plus runtime or static hints for WebMCP and agentic commerce.
  • Validates basic response shape instead of treating every HTTP 200 as a confirmed implementation.
  • Explains what a missing protocol actually means and when it is irrelevant to your site.

What are emerging protocols for AI agents?

Traditional websites were designed mainly for people and general web crawlers. Agentic systems increasingly need additional machine-readable answers to questions such as: What APIs exist? Which authorization server protects this resource? Does this domain expose an MCP server or an A2A agent? What reusable skills are available? Can an agent transact with the service?

Emerging protocols try to make those answers discoverable without a developer manually configuring every integration. The important nuance is maturity. OAuth Authorization Server Metadata, OAuth Protected Resource Metadata and API Catalog are IETF Standards Track RFCs. A2A has a published v1 specification. MCP Server Card, Agent Skills domain discovery and WebMCP are still drafts or incubating work. ARD is explicitly a proposal. Commerce protocols such as UCP, ACP, x402 and MPP are evolving in parallel.

That is why this tool does not treat every missing protocol as an error. A content publisher may not need any agentic commerce protocol. An API service may benefit from OAuth metadata and API Catalog. An agent service may care about MCP or A2A. The useful output is the gap between the capabilities you actually offer and how easily a machine can discover them.

How to read the output

Detected means the expected discovery endpoint returned a usable response and basic shape checks passed. Signal means static evidence suggests a protocol implementation, but the protocol requires runtime or resource-level testing. Not detected means the common discovery location was not found. Manual check means the protocol currently has no universal domain-level endpoint that a server-side checker can safely use as proof.

The top count covers only protocols with a documented domain-level discovery surface. WebMCP, x402, MPP and ACP are reported separately because static discovery is incomplete or implementation-specific. For a broader AI-readiness assessment that also checks crawl discovery, Markdown negotiation and bot policy, use the Site Agent Readiness Checker.

Why protocol discovery belongs in an AI-readiness strategy

Readable content and good semantic HTML help an agent understand a page, but an agent-ready service may also need to expose what it can do. Discovery metadata can reduce manual integration work by giving clients a predictable place to find authorization details, APIs, agent capabilities, reusable skills or commerce interfaces. This is especially relevant for products that expect agents to authenticate, call APIs, invoke tools or complete transactions rather than only read content.

Protocol adoption should follow a real use case. Publishing a speculative descriptor that points to nothing useful does not make a site more agent-ready. Implement the underlying capability first, then expose the discovery layer that matches it.

Emerging protocols FAQ

The checker probes a public domain for machine-discoverable protocol endpoints and static implementation signals used by AI agents, API clients and agentic commerce systems. It checks established standards such as OAuth metadata and API Catalog alongside newer conventions such as MCP Server Cards, Agent Skills discovery, ARD, auth.md, UCP and WebMCP hints.

Emerging protocols are machine-readable conventions that help agents discover capabilities, authenticate, select tools, interact with other agents or transact with services. Some are published IETF RFCs, some are stable protocol specifications, and others are drafts or proposals. They should not all be treated as equally mature or equally necessary.

Detected means the checker found a documented endpoint or structured response that matches the expected protocol shape. Signal means static evidence suggests an implementation but runtime or resource-level validation would still be needed. Not detected means the common discovery location was not found. Manual check means the protocol does not currently expose a universal domain-level endpoint that this server-side checker can reliably verify.

No. A content website may need none of them. An API service may care about OAuth, API Catalog or MCP. An agent service may care about A2A or Agent Skills. A commerce business may care about UCP, ACP, x402 or MPP. Use the output as a relevance map, not as a checklist that every site must complete.

Those documents are IETF Standards Track RFCs with stable normative requirements. MCP Server Card, Agent Skills discovery, WebMCP and ARD are at different stages of development. The tool shows maturity explicitly so a missing experimental capability is not presented as equivalent to a missing established metadata standard.

RFC 9728 lets a protected resource publish metadata at a predictable well-known location, including the resource identifier and authorization servers that can be used with it. This can reduce manual configuration when an agent or client needs authenticated access to a protected service.

RFC 9727 defines /.well-known/api-catalog and the api-catalog link relation so machines can discover a publisher's public APIs and metadata about them. It is useful when a service wants agents and other clients to find APIs without relying only on human documentation.

The A2A protocol requires servers to make an Agent Card available. The well-known URI strategy uses /.well-known/agent-card.json. The card describes identity, capabilities, skills and supported interaction protocols so other agents can decide whether and how to connect.

MCP Server Cards are a draft discovery mechanism proposed in SEP-1649 for HTTP MCP servers. The proposal uses a well-known JSON document to describe the server before a full MCP connection is opened. Because the MCP working group is still evolving this area, the checker labels it Draft rather than a stable requirement.

Agent Skills are an open format built around SKILL.md files. A separate draft from Cloudflare proposes /.well-known/agent-skills/index.json so organizations can publish an index of skills for machine discovery. The Skills format and the domain-level discovery draft should be understood as related but distinct layers.

WebMCP is a draft browser API that lets pages register tools through document.modelContext and related interfaces. Because tools can be registered dynamically after JavaScript runs, a server-side HTTP fetch cannot prove runtime support. The checker therefore reports static source hints and recommends browser-level verification.

They address different parts of agentic commerce. UCP publishes business capabilities through a well-known profile. ACP defines checkout APIs and capability negotiation. x402 uses HTTP 402 for internet-native payment flows. MPP provides machine-payment flows and can advertise payment offers in OpenAPI metadata. Their discovery models and maturity differ, so the checker does not reduce them to one generic commerce score.

This tool goes deep on protocol discovery and explains the maturity and meaning of each protocol. The Site Agent Readiness Checker is broader and also covers robots.txt, sitemap discovery, Markdown content negotiation, bot controls and other AI-readiness layers. Use this checker for protocol detail and the broader checker for an overall site review.

No. Discovery is only the first layer. The checker does not authenticate, execute MCP tools, run A2A tasks, invoke WebMCP in a browser, complete checkout or send payments. A detected descriptor can still be incomplete or point to a service that fails at runtime.

Why this output matters

Protocol discovery shows whether AI agents and machine clients can find the authorization metadata, APIs, agent capabilities, skills and commerce interfaces a service exposes. The output separates stable RFCs from drafts and proposals so teams can prioritize protocols that match real product capabilities instead of treating every emerging convention as mandatory.

Related AEO tools

View AEO tools
Markdown Negotiation Tester
Test whether a URL serves text/markdown to AI agents through HTTP content negotiation and inspect Content-Type, Vary and response overhead.
Site Agent Readiness Checker
Audit discovery, content accessibility, bot controls, agent protocols and commerce signals across established standards and emerging agent-web conventions.
Entity Coverage Analyzer
Analyze named entities, expected-entity coverage, contextual clarity, relationships and schema identity signals.
LLM Chunk Checker
Check page sections for retrieval readiness, standalone context, answer clarity and estimated token size.