ONX Check

Methodology

Validated against the published ONX spec, version 2026-08-06.

We don't read a static manifest – we open a side-effect-free live MCP session with your ONX server and inspect the fulfillment tools it actually declares.

  1. 1

    Discovery

    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 – and validate the response against that version's published schema. We confirm it returns a non-empty set of tools. If the server is unreachable, rejects the handshake, or requires a credential, the check stops here and tells you why.

  2. 2

    Schema validation

    We validate every declared tool's shape against the canonical ONX spec to flag deviations and compile each schema to confirm it is valid. Tool names are checked for valid naming or missing required parameters.

  3. 3

    Capabilities

    We check that all standard ONX fulfillment tools are present and that the server declares the required MCP capability flags. We then enumerate every tool the server actually exposes, including any custom ones.

  4. 4

    Endpoint probes

    We call a nonexistent method to verify it returns the correct JSON-RPC error code for unknown methods, and on initialize-era servers exercise a JSON-RPC ping round-trip (MCP 2026-07-28 removed ping) – evidence the server handles the protocol correctly.

  5. 5

    Hygiene

    We check transport-level basics such as the endpoint is served over HTTPS, and we surface the optional vendor block when present so the surface an agent reaches is delivered with integrity.

How ONX validation works

We check a brand's published surface against the current ONX 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 fulfillment tools it actually declares. Then we check that the standard ONX order-operations tools are present, well-formed, and shaped to the canonical ONX schemas. This is a stronger check than reading a static manifest because a published descriptor can claim anything, but a live session confirms the server is genuinely up, answering MCP correctly, and exposing the tools an agent would need to move an order from creation through fulfillment and returns.

What we intentionally don't check

This is a conformance and reachability check, not an end-to-end fulfillment test. We confirm the tools are declared, well-formed, and that the server speaks MCP correctly; we do not invoke the tools to create real orders, move inventory, or trigger shipments, and we do not verify the business correctness of the data behind each tool.

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