These checks are optional capability signals. An ordinary business website does not need every protocol listed here. A discovery file can tell a supporting tool where to look; it cannot prove that a tool works, is secure or will improve AI visibility.
The Scan checks bounded static declarations and conventional paths. A missing conventional file does not prove a service is unavailable elsewhere. Start with the service you actually operate, its current documentation and its intended users. Never put credentials in public metadata.
MCP discovery
MCP connects tools and resources to supporting clients. The Scan checks a conventional discovery document’s basic shape; it does not connect to your server or call a tool.
If you operate an MCP server, describe the real endpoint and document authentication separately. Validate the document your clients expect, then test with an authorized client in a safe environment. Do not create a fictional endpoint to clear the card. Use the official MCP documentation for transport and security requirements; a conventional discovery path alone is not protocol certification.
Agent-to-agent discovery
A2A uses an Agent Card to describe an agent service. The declaration can name capabilities and access requirements, but does not prove that an agent can complete a task.
For an actual service, publish a card that matches the current A2A specification. Keep endpoint, capabilities and authentication accurate. Test a harmless authorized exchange separately. If your site offers no agent service, treat this as context rather than a missing website feature.
Browser tools (WebMCP)
WebMCP proposes browser-facing tool declarations. The Scan sees static hints and form declarations, not a running browser tool. Support and the proposal can change.
Only advertise actions you implement. Check the WebMCP project for the current interface and browser support. Give tools clear input boundaries and keep dangerous actions behind appropriate confirmation and authorization. Test behavior in a supported browser; a declaration count is not that test.
Agent skills
A skills document describes supported tasks and how to use them. A document at a conventional path is not proof that every visiting agent understands it.
Write from the tasks your service genuinely supports. State inputs, limits, failure behavior and required permissions. Keep instructions public and omit tokens or private examples. Validate the format against the clients you intend to support, then test those clients. Leave the capability out if there is no real skill to expose.
AI resource catalog
An AI catalog lists machine-readable resources under a discovery convention. A syntactically recognized catalog can still point to stale or unusable URLs.
List only real public resources with accurate media types and descriptions. Check each link independently and remove retired entries. Do not list admin endpoints or credentials. Confirm your intended clients support the convention; the Scan’s basic shape check does not establish that support. Our Link headers guide covers another way to advertise related resources.
API catalog
An API catalog helps clients locate API descriptions. It should explain the interfaces you actually offer, not imply that every endpoint is anonymously accessible.
Use the catalog format supported by your clients and link current descriptions. Document authentication, versioning and limits in the API documentation. Check description URLs and run separate authorized integration tests. The IETF api-catalog work describes the discovery convention; discovery is not an endpoint health check.
Natural-language interface (NLWeb)
NLWeb signals can point to a natural-language interface. A static link says where an interface is advertised, not whether its answers are accurate.
If you run the service, align the advertised endpoint with the implementation and current NLWeb project documentation. Test a harmless question in a safe environment and inspect failure behavior. Remove stale declarations. Do not add an interface solely because a Scan card names the convention.
Open Knowledge discovery
Open Knowledge signals can advertise a typed knowledge bundle. Discovery is not uniformly implemented, and the Scan does not download a bundle or validate its knowledge.
If you publish such a resource, keep its typed links and catalog entries accurate. Confirm which format and client you support before changing the declaration. Test the actual resource separately and document its provenance and update process. A missing hint is not evidence your business lacks public knowledge or authority.
Schema map
A schema map advertises schema resources using a proposer convention. The Scan recognizes XML syntax at the conventional path; it does not establish a shared standard or verify the schemas behind the links.
Use the format your actual tools support, publish well-formed XML and check the resource links. Keep normal page JSON-LD correct regardless of whether you use a schema map. See our structured data guide for those page-level facts. Do not treat valid XML as proof of interoperability.
Authentication instructions
Public authentication instructions describe how an authorized client gets access. They must not contain a working password, API token or a route around your access controls.
Document supported flows, permission scopes, expiry and failure handling. Link the real authorization documentation. Test the flow with disposable credentials outside the public file. Use the OAuth security best current practice where OAuth applies. A readable instructions file does not prove the authentication implementation is safe.
