SCVD General Store

Preflight an x402 Endpoint

preflight_endpoint

Read-onlyIdempotent

x402 endpoint preflight, free. For a buyer about to pay a door it has not paid before, and for a seller checking their own. Check any x402 endpoint's door before paying it: one unpaid probe answering whether the URL serves a well-formed x402 v2 payment challenge right now — 402 status, parseable PAYMENT-REQUIRED, signable accepts, testnet catch. Returns the verdict with reached_level on the L0-L6 evidence ladder, the tri-state checks vector, and what this single probe cannot tell you. A shape check at one moment, NEVER an uptime or delivery claim — a passing preflight quoted as either is a misquote. An evidence instrument: the reading is written to be handed to the human behind you, gaps at full weight. Rate limited; the result carries the stated ceiling. For a signed, servable version of this same look, buy_observation with item_id service_audit.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The https endpoint a buyer would GET expecting a 402 challenge.

Output Schema

TableJSON Schema

Name	Required	Description
`verdict`	Yes	ready \| not_ready \| unreachable.
`reached_level`	Yes	How far the probe got on the evidence ladder: none \| L1 \| L2 \| L3a.
`single_probe_note`	No	One request, one moment — the standing caveat.
`reached_level_meaning`	No	What that rung does and does not claim.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavioral context beyond annotations: the probe is rate limited, reflects only one moment in time, is never an uptime or delivery guarantee, and deliberately reports gaps. The description is detailed and does not contradict the readOnlyHint, idempotentHint, or destructiveHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by usage context, limitations, and alternative. It is somewhat verbose and contains a few metaphorical or redundant phrases, but the extra length is mostly justified by the tool's nuanced guarantees and limitations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only probe with an existing output schema and annotations, the description covers the essential context: when to use it, what it can and cannot tell you, rate limiting, and how to get a signed/servable version. Nothing critical is missing for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already fully documents the 'url' parameter as an HTTPS endpoint a buyer would GET expecting a 402 challenge. The description reinforces this context but does not add significant new parameter-level detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies the operation as 'preflight' of an x402 endpoint with a specific verb and resource. It also distinguishes itself from siblings by naming buy_observation as the signed/servable alternative and by describing this as a free unpaid single probe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool: by a buyer before paying an unfamiliar door, or by a seller checking their own endpoint. It also names the alternative tool and condition for using it, and warns against using the result as an uptime or delivery claim.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SCVD General Store tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.