Skip to main content
Glama

preflight402

One free call before your agent pays. Health, authenticity, and Sybil-filtered reputation — one verdict.

License: MIT Python 3.10+ MCP

A free trust/health preflight for the agent payment economy (x402). It probes an endpoint before your agent pays and returns one trust-preview.v1 verdict: liveness, TLS, the 402 handshake (x402 v1/v2 + MPP detection), price sanity, continuous uptime history, ERC-8004 identity binding, and Sybil-filtered on-chain reputation — rolled into a proceed / caution / avoid recommendation with plain-language reasons. No wallet, no key, no charge.

Why filtered reputation matters: one live agent shows a 99.8/100 average from 996 reviewers — until Sybil filtering collapses those reviewers into 12 independent funding clusters at 89.7. Raw reputation is trivially farmed; this is what the verdict actually scores. (Separately, only ~4% of x402 payees bind to any ERC-8004 identity at all — so most verdicts run on health, price, and handshake, and say so honestly.)

Why "listed" means little: across 7.76M probes over 15 days of a 51,331-endpoint catalog, two squatting hosts account for 58% of every listed x402 endpoint — one serving a uniform 404 behind a "This app isn't live yet" placeholder, the other a uniform Cloudflare TLS failure. Strip them out and 87% of real endpoints work; measured per provider, about one host in seven (13.9%) serves no valid 402. Read the findings: What 7.8M probes say about the x402 economy — including why a GET-only crawl (ours included, before we fixed it) overstates x402 invalidity ~2×. Full method and caveats: docs/checkpoint-m3.md.

30-second quickstart

Point any agent at the hosted MCP endpoint — no wallet, no key, no install:

https://preflight402.ironshell.io/mcp

Or check an endpoint over plain HTTP:

curl 'https://preflight402.ironshell.io/preflight?url=https://api.example.com/paid'

Related MCP server: Agent Identity MCP Server

Guard every payment automatically

preflight402-guard turns the service into a payment gate for the x402 Python SDK — safety becomes default-on instead of something an agent has to remember to call:

pip install "preflight402-guard[x402]"   # PyPI publish pending; for now: pip install "git+https://github.com/duskwire/preflight402.git#subdirectory=guard"
from preflight402_guard import Guard
from x402 import x402Client

guard = Guard()          # block "avoid", warn on "caution"
client = x402Client()
guard.install(client)    # every payment is preflighted before signing;
                         # a bad verdict raises PaymentAbortedError

It also cross-checks that the payee your client selected matches the endpoint that was preflighted (the 402's resource URL is attacker-controlled), enforces an optional max_price_usd ceiling against the actual selected terms, and fails open by default so your commerce never depends on our uptime. There's a CLI too: preflight402-guard check <url>. See guard/README.md.

Status

Live at preflight402.ironshell.io and in the official MCP registry as io.ironshell/preflight402. The free preflight engine (health + 402 parse + verdict), continuous probing with uptime history, ERC-8004 binding, and the Sybil filter are all shipped and serving live. The whole service is free — there is no paywall.

Use it

As an MCP tool (no wallet, no key)

The preflight tool takes a url and returns a trust-preview.v1 verdict.

Easiest — point any MCP client at the hosted instance, no install:

https://preflight402.ironshell.io/mcp   (streamable-http)

Or run it yourself over stdio. Claude Code — one line (PyPI publish pending; until then point --directory at a clone):

claude mcp add preflight402 -- uvx --from preflight402 preflight402-mcp
# pre-PyPI: claude mcp add preflight402 -- uv run --directory /path/to/preflight402 preflight402-mcp

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "preflight402": {
      "command": "uvx",
      "args": ["--from", "preflight402", "preflight402-mcp"]
    }
  }
}

Either way, run it as a hosted HTTP server with preflight402-mcp --transport streamable-http (serves the same tool at http://<host>:8000/mcp).

As a REST call

The hosted instance also serves REST:

curl 'https://preflight402.ironshell.io/preflight?url=https://api.example.com/paid'

Or run it yourself (serves REST + MCP on one port):

uv run uvicorn preflight402.api.app:app --port 8402
curl 'http://localhost:8402/preflight?url=https://api.example.com/paid'

Development

Requires uv.

uv sync                                        # create venv + install deps
uv run uvicorn preflight402.api.rest:app       # serve on :8000
curl http://localhost:8000/healthz             # {"status":"ok","version":"0.1.0"}

uv run pytest                                  # tests
uv run ruff check .                            # lint
uv run ruff format --check .                   # formatting

Layout

src/preflight402/
├── api/          # REST + MCP server
├── probe/        # async prober, TLS inspection, 402 parsers (x402 v1/v2, MPP)
├── verdict/      # rules -> trust-preview.v1 JSON
├── chains/       # ChainVerifier interface: EVM (Base), SVM (Solana)
├── reputation/   # ERC-8004 subgraph client, endpoint binding, Sybil filter
├── ingest/       # endpoint seed ingesters (Bazaar, x402scan, ...)
├── scheduler/    # probe loop with per-host politeness
└── db/           # SQLite (WAL) schema + queries
guard/            # preflight402-guard: client-side auto-preflight for the x402 SDK
tests/            # unit/ + golden/ (captured 402 responses) + integration/ (marked slow)
deploy/           # Dockerfile + deploy notes
docs/             # trust-preview.v1 schema + API docs (M8)

Available Tools

1 tool
preflightx402 Preflight Trust CheckAInspect

One free call before your agent pays.

Probes the URL (no wallet, payment, or auth) and returns a
trust-preview.v1 verdict: liveness and latency, TLS validity, the 402
payment handshake with protocol detection (x402 v1/v2, MPP-capable),
detected networks/asset/price with a USD estimate, ERC-8004 identity
binding with Sybil-filtered reputation for the payee (which can adjust
the recommendation), and a proceed / caution / avoid recommendation with
human-readable reasons. Paid-tier fields (uptime history, reseller
analysis) are present but null on the free tier.
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute https URL of the x402 or MPP payment endpoint to check

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states the call is free, requires no credentials, and returns a detailed verdict, including the recommendation and the fact that paid-tier fields are null. This is thorough and transparent about the tool's non-invasive, read-only nature.

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, starting with a benefit statement and then enumerating the key return fields and limitations. It's slightly dense but every sentence adds value, and it avoids unnecessary fluff. It could be more concise, but the structure is effective.

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?

Given that there is an output schema (not shown here) and no annotations, the description is remarkably complete. It explains the purpose, the exact checks performed, the returned recommendation, and the free-tier limitations. This provides sufficient context for an agent to decide when and how to invoke the tool, and what to expect in return.

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?

The input schema already provides 100% coverage for the single 'url' parameter with a clear description. The tool description does not add new semantic information about the parameter itself, but it does contextualize its use (probes the URL). This aligns with the baseline of 3 for full schema coverage.

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?

The description clearly states a specific action: 'Probes the URL' and returns a 'trust-preview.v1 verdict' with detailed criteria. It distinguishes itself as a preflight check before payment, which is a unique and well-defined purpose.

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?

The description opens with 'One free call before your agent pays,' which clearly indicates when to use the tool. It also notes that no wallet, payment, or auth is involved, implying it's safe for initial checks. However, it does not explicitly mention when not to use it or provide alternatives, since no sibling tools exist.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedpreflight

TDQS

A4.4/5.0
Disambiguation5/5

With only one tool available, there is no possibility of confusion between tools. The tool's purpose is clearly defined as a URL preflight check.

Naming Consistency5/5

The single tool name 'preflight' is clear and appropriate for its function, and with only one tool, there is no inconsistency to evaluate.

Tool Count3/5

A single tool is on the low end of the scale, suggesting a thin server. However, the tool is comprehensive and well-scoped to the server's stated purpose of preflight checks, making it borderline.

Completeness5/5

The preflight tool covers all essential aspects of the intended function: probing URLs, checking liveness/TLS, payment handshake, network detection, identity, and recommendation. No obvious gaps exist within the preflight domain.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP server exposing AgentForge Trust Score audit tools. Query trust, evaluate policies, list trusted servers, recommend with filter.
    4
    20
    1
    MIT
  • F
    license
    A
    quality
    D
    maintenance
    Reputation and trust scoring service for AI agents, exposed as an MCP server. Evaluate counterparties, report interactions, issue portable trust certificates, and detect Sybil attacks.
    23
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server that verifies storefront merchants before AI agents make payments, checking if the merchant is a real legal entity bound to the domain, and returning a PROCEED, ABORT, or REVIEW decision to prevent payment to clones or fraudulent stores.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/duskwire/preflight402'

If you have feedback or need assistance with the MCP directory API, please join our Discord server