MCP Check

Methodology

Validated against the published MCP spec, version 2026-07-28.

We don't read a static descriptor – we open a side-effect-free live MCP connection with your server, detect which MCP handshake it speaks, and inspect the tools it actually advertises.

  1. 1

    Handshake

    We connect to the URL you provide and detect which MCP handshake your server speaks: the stateless server/discover of MCP 2026-07-28, the initialize handshake of earlier versions, or both. We validate each response against that version's published schema (2026-07-28, or 2025-11-25 for initialize-era servers). If the server is unreachable or rejects the handshake, the check stops here and tells you why.

  2. 2

    Tool inventory

    We call tools/list to enumerate the tools your server actually exposes and then validate each tool's shape – a valid name, and an inputSchema that compiles as real JSON Schema – so the surface an agent would discover is genuinely usable, not just declared.

  3. 3

    Hygiene

    We check transport and protocol basics such as that the endpoint is served over HTTPS, that server version follows semver, that a JSON-RPC ping round-trips on initialize-era servers (MCP 2026-07-28 removed ping), and that calling an unknown method returns the correct JSON-RPC error code – evidence the server handles the protocol correctly, not just that it answered once.

  4. 4

    Commerce overlay

    Finally we scan the advertised tool names for commerce- and fulfillment-shaped patterns – carts, checkout, orders, products, inventory, payments, shipping, and the like. This is an informational overlay, not a compliance gate: it tells you whether your server exposes commerce-relevant tools given the accelerating adoption of open-standard agentic commerce protocols.

How MCP validation works

We check a live server against the published MCP specification. But the phase most validators skip is the one that matters most in practice.

We open a real MCP connection with your server – the stateless 2026-07-28 protocol where the server supports it, the initialize handshake where it doesn't – and inspect the tools it actually advertises. Then we exercise the server with a deliberate unknown-method call, a tools/list enumeration, and, on initialize-era servers, a ping. This is a stronger check than reading a static descriptor because a published manifest can claim anything, but a live session confirms the server is genuinely up, negotiating a protocol version, speaking JSON-RPC correctly, and exposing tools an agent could actually discover and call.

The commerce overlay is intentionally light. MCP itself is general-purpose connectivity – it doesn't mandate commerce tools – so we don't fail a server for lacking them. Instead, with the growing prominence of agentic commerce, we report whether the advertised tools look commerce-shaped, which is a useful signal if you're building toward shopping in the age of AI.

What we intentionally don't check

This is a conformance and reachability check, not an end-to-end exercise of your tools. We confirm the handshake succeeds, the tools are declared and well-formed, and that the server speaks MCP correctly; we do not invoke your tools, read your resources, or verify the business correctness of the data behind them.

Servers that require authentication are reported accordingly rather than fully exercised.