How a GET probe makes working x402 endpoints look broken

A study of x402 endpoints reveals that only the request type used to probe the endpoint matters. A seemingly healthy payment server can be misclassified as broken if probed with a GET request, as the server may refuse to quote the payment before receiving the request body. This design is legitimate and common, but any census that uses only one method to probe endpoints will misclassify a large portion of the ecosystem.

The study found that nearly half of the 16,322 endpoints in the 402 protocol registry only respond to POST requests. To address this issue, the researchers now probe both GET and POST requests and record which method returns the 402 challenge response. They also mark endpoints with a templated path, such as /tx/:hash, as not probed to avoid incorrect classifications.

The researchers added two commands to mcpreflight: baseline, which reads the paid endpoint once and records the challenge shape, and drift, which re-reads the endpoint and exits with an error if the shape has changed, providing a field-level diff of the exact changes. By committing the baseline file and running the drift check on every push, operators can catch changes to the endpoint's challenge shape before they reach a buyer, ensuring a consistent and reliable payment experience.

The study emphasizes that the method used to probe the endpoint is more important than the number of working endpoints, as the number alone does not provide enough information about the endpoint's stability over time. The researchers publish the method, cohort definition, and per-endpoint results to allow anyone to re-derive the number and ensure transparency.

The weekly drift table is available at https://xka0085-byte.github.io/mcpreflight/x402-endpoint-inspector.html, and the full registry census is available at https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html.