x402-pilot
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| decode_402A | Parse and validate an x402 PaymentRequired (HTTP 402) response and explain every field. Flags missing economic fields (scheme/network/asset/payTo/amount), number-typed or human-decimal amounts (must be atomic-integer strings), and missing explicit decimals. Provide ONE of: |
| inspect_payment_responseA | Decode and validate an x402 PAYMENT-RESPONSE, surfacing success, settlement id, payer, network, and amount. Optionally recomputes the on-chain truth: pass |
| check_complianceA | Heuristically scan x402 code (a file or directory) for the high-severity classes: hardcoded chain id, hardcoded decimals, magic-number decimal scaling (10**N, 1eN, *1_000_000), human-decimal/float amounts, and literal asset/token addresses. Returns findings with file:line and severity. Heuristic — a documented default may be a false positive; every finding cites a location for human judgement. No network. |
| lint_scheme_specA | Lint a draft scheme spec (markdown) against the bundled scheme_template.md: reports missing/extra template sections and whether the draft pins down the load-bearing concepts a scheme must specify (value/recipient assertion, settlement identifier, replay protection, atomic+decimals amount encoding, verify/settle flow). Reads the bundled corpus; no network. |
| validate_extensionA | Structurally validate an x402 extension payload: checks the typed { info, schema } envelope and runs light known-extension field checks (offer-and-receipt, payment_identifier, gas-sponsoring, sign-in-with-x, builder_code). Pass |
| run_conformanceA | Drive the x402 conformance sequence against a facilitator. Holds NO keys: automates the 402 negotiation (with |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct artifact: PaymentRequired decoding, PAYMENT-RESPONSE inspection, code compliance scanning, spec linting, extension validation, and end-to-end conformance runs. The decode_402 vs inspect_payment_response pair could be momentarily confused, but descriptions clearly split request-side vs response-side, and run_conformance is clearly an orchestrator over the others.
All tools follow a consistent snake_case verb_noun pattern (check_compliance, lint_scheme_spec, validate_extension, run_conformance). decode_402 is the only minor deviation, embedding a number instead of a noun, but it remains readable and predictable.
Six tools is well-scoped for an x402 validation/compliance toolkit, with each tool covering a distinct stage of the protocol surface. No bloat and no obviously missing companion tool given the read-only, no-keys design.
The surface covers parsing 402 requests, inspecting responses with on-chain recomputation, spec linting, extension validation, code compliance, and conformance sequencing—a broad lifecycle. Minor gaps exist (no payment construction/signing), but that omission is deliberate given the server holds no keys.