MCP Check

Methodology

Validated against the published MCP spec, version 2025-06-18.

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

  1. 1

    Handshake

    We connect to the URL you provide and perform an MCP initialize handshake. We confirm it returns an MCP shaped response and a non-empty set of tools. 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, 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 session with your server, complete the initialize handshake, and inspect the tools it actually advertises. Then we exercise the server with a ping, a deliberate unknown-method call, and a tools/list enumeration. 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.