ONX Check

Methodology

Validated against the published ONX spec, version 1.0.0.

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 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, 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 exercise a JSON-RPC ping round-trip to confirm it responds, and a call to a nonexistent method to verify it returns the correct JSON-RPC error code for unknown methods – 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 published ONX 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 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.