QuickBuild token-saver tools + x402

x402 pre-flight check (will this URL accept payment, what it costs)

x402_preflight

Read-onlyIdempotent

[PAID $0.005 USDC per call via x402 on Base; errors are free] For developers of buyer agents. Makes ONE unpaid request (GET, POST fallback if GET is not allowed; 4 s timeout; max 2 redirects; 64 KB read) to the target and parses its HTTP 402 challenge (v2 PAYMENT-REQUIRED base64 header or v1 JSON body). Returns normalised accepts[] (scheme, CAIP-2 network, asset, amount in USD, payTo), pass/fail checks (valid challenge, supported mainnet network, USDC asset, parseable amount within a sanity cap, well-formed payTo, latency, TLS, Bazaar metadata, CORS), a verdict with plain reasons, latency, and the measured /ai-search score + sample size when the host is in our index. NEVER sends a payment or payment header. https + public hostnames + port 443 only; IPs, localhost, .local/.internal and credentials refused (400). Unreachable/timeout target = 502/504 JSON with verdict do_not_pay, never charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "x402_preflight"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	https URL of the x402 endpoint your agent plans to pay (public hostname, port 443).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Extremely forthcoming beyond the read-only annotations: exact price ($0.005 USDC on Base, errors free), single request with GET→POST fallback, 4 s timeout, max 2 redirects, 64 KB read cap, and the two challenge formats parsed. It also discloses failure semantics — 400 for refused targets, 502/504 with verdict do_not_pay, and no charge on failure — which the annotations do not cover at all.

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?

Front-loaded with price and the core one-request/parse-challenge action, then constraints, then failure modes — good ordering with no filler sentences. It is a dense single paragraph of stacked parentheticals, which costs a little scanability for an agent parsing it quickly.

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?

Even without an output schema, the description enumerates the return payload (normalised accepts[] with scheme/network/asset/amount/payTo, pass-fail checks, verdict with reasons, latency, /ai-search score) and the error shapes. For a network-probing single-parameter tool, nothing an agent needs to call or interpret it is missing.

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

Parameters4/5

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

Schema coverage is 100% with a single documented url parameter, so the baseline is already 3; the description adds real meaning on top by enforcing https, port 443 and public hostnames and enumerating what gets a 400. Only the trivial format detail (the https:// prefix pattern) is redundant with the schema.

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?

States a specific verb+resource: makes ONE unpaid request to an x402 endpoint and parses its HTTP 402 challenge to report price and payability. It also scopes the audience ("developers of buyer agents") and states the key differentiator versus any sibling: it NEVER sends a payment, unlike a real paying call.

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

Usage Guidelines4/5

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

Usage context is clear — call this before your agent pays a URL — and refusal cases (IPs, localhost, .local/.internal, credentials, non-443) tell the agent when the call will fail. It does not name any sibling alternative (free_site_check, website_audit, launchcheck_full) or explicitly say when not to bother, so it stops short of full routing guidance.

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

All QuickBuild token-saver tools + x402 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?