What a Real MCP and A2A Conformance Scan Actually Checks

"Does this URL support MCP?" is the easy question. A 200 response from a Streamable HTTP endpoint answers it in one request. The harder, more useful question is whether that endpoint actually implements the spec correctly enough to be worth depending on — and that requires checking a lot more than whether it answers at all.

Agent Protocol Inspector reports a three-state result for every protocol it checks: not_detected, indicated (some signal, not fully validated), or confirmed (found and validated). Getting to confirmed means passing a specific set of checks per protocol, each producing its own evidence — not a single boolean.

MCP: Two Eras, One Scanner

The Model Context Protocol's 2026-07-28 revision replaced the original stateful design with a fully stateless core, and a real conformance scan has to speak both.

Legacy (pre-2026-07-28). A client sends a JSON-RPC initialize request with its protocolVersion and clientInfo; the server responds with its own serverInfo, negotiated protocolVersion, and a Mcp-Session-Id header that scopes every subsequent call.

Modern (2026-07-28+). The stateful handshake is gone. Every request carries its protocol version via _meta, and a new mandatory server/discover call advertises supported versions and capabilities up front, with no session to establish first. This revision also put Roots, Sampling, and Logging on a deprecation track (removal no earlier than 2027-07-28) and shortened the runway for the dedicated HTTP+SSE transport (protocol version 2024-11-05), which has been deprecated since March 2025.

A scanner that only speaks one era silently misreports every server on the other one as broken. Agent Protocol Inspector probes server/discover first and falls back to the legacy initialize handshake — both paths produce a real confirmed result with the era recorded, not just a pass/fail.

Beyond the handshake itself, the scan checks things that only show up on a second look:

• Tool list stability — calling tools/list twice and comparing ordering. A tool list that reorders between identical calls is a real integration hazard for any client that indexes tools positionally.
• Cache metadata presence — whether the server declares a TTL and scope for its tool list, missing on servers that never considered client-side caching.
• Extensions — non-core capability extensions the server advertises beyond the baseline spec.

MCP Authentication: Beyond "Requires OAuth"

An MCP server behind auth answers with a 401 or 403 and a WWW-Authenticate header. From there, the scan follows the actual discovery chain a real client would have to implement:

1. Parse resource_metadata out of the challenge, or check /.well-known/oauth-protected-resource directly (RFC 9728).
2. Read the declared authorization_servers[0] as the issuer.
3. Check the issuer's /.well-known/openid-configuration and /.well-known/oauth-authorization-server (RFC 8414) independently — not one as a fallback for the other, since an issuer can genuinely serve both.
4. Classify the client-registration mechanism: Client ID Metadata Documents (client_id_metadata_document_supported: true) versus Dynamic Client Registration (a bare registration_endpoint, RFC 7591). DCR-only gets flagged with a specific deprecation note, since CIMD is the current mechanism.

That step-3 independence turned out to matter in practice — we cover exactly how, and what it looks like on real MCP servers, in a dedicated post on detecting OpenID Connect vs. bare OAuth 2.0.

A2A: Spec-Lint, Not Just Card-Parsing

Fetching an Agent Card successfully only means the JSON parsed. A confirmed A2A result also runs the card through a set of spec-hygiene checks:

• Required fields — protocolVersion, version, url, description all present.
• Skill quality — at least one skill declared, and every skill has a description. A routing agent selects which agent to delegate to based on skill descriptions; a skill with no description is invisible to that routing logic even though it technically exists.
• Input/output modes declared — defaultInputModes and defaultOutputModes present, since a client can't negotiate content types with an agent that never states what it accepts.
• Security scheme declared — flagged when a production-shaped agent has no securitySchemes at all.
• Legacy path warning — a card served only from /.well-known/agent.json (the pre-0.3.0 path) rather than the current agent-card.json.
• Embedded secrets — the card's raw JSON is checked against a credential-pattern regex. An agent card is a public document by definition; a stray API key or bearer token baked into one is a real, surprisingly common leak class.
• OIDC URL resolution — if the card declares an openIdConnectUrl in its security schemes, the scan actually fetches it and confirms it resolves to a document with an issuer or authorization_endpoint — a declared-but-dead discovery URL is worse than not declaring one, since a client will trust it until it tries to use it.

Two of these rules exist specifically because of false positives caught during validation against real targets, not theoretical ones: an early "agent-card" keyword and later a "schema" keyword were both dropped from unrelated matching logic after they fired on ordinary API-documentation language that had nothing to do with the capability being checked. Every rule that ships has been checked against a real card, not just written from the spec text.

Why the Distinction Matters

A confirmed badge that only means "an endpoint returned 200" isn't something you can build a decision on. The warnings and lint layer is what turns "this looks like MCP" into "this is a spec-conformant MCP server with declared, resolvable authentication metadata" — the difference between a detection and something you can actually route production traffic to.

Run Agent Protocol Inspector against your own MCP server or A2A agent before you tell anyone else it's ready — the warnings it surfaces are the same gaps a real integrating client would hit first.