The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the MCP x402 – Evidence Backed Web Verification listing page.
Give an AI agent a public HTTP(S) page and 1 to 10 concrete conditions. The verificar_condicoes tool returns an evidence-based decision for every condition:
confirmado — the page clearly supports the condition.rejeitado — the page clearly contradicts the condition.incerto — the available page evidence is insufficient.Each verification includes the final source URL, page title, timestamp, condition-by-condition explanation, quoted evidence when available, a unique verificationId, and a SHA-256 pageHash.
$0.05 USDC per verification on Base mainnet.https://mcp-x402-production.up.railway.app/mcpPOST https://mcp-x402-production.up.railway.app/preflight/mcpPOST https://mcp-x402-production.up.railway.app/preflight/verify-conditionsPOST https://mcp-x402-production.up.railway.app/verify-conditionsGET https://mcp-x402-production.up.railway.app/healthThe service also provides paid public URL analysis and general AI consultation through analisar_url and consultar_ia.
https://mcp-x402-production.up.railway.appGET /healthPOST /mcpPOST /analyze$0.05 USDC per paid requesteip155:8453)eip155:8453)verificar_condicoes — $0.05 USDCA paid decision-verification tool for agents.
Give it a public URL and one or more concrete conditions. It returns a decision based only on evidence extracted from that page:
confirmado — the page clearly proves the condition.rejeitado — the page clearly contradicts the condition.incerto — the page does not provide enough evidence.Each result includes the final source URL, page title, verification timestamp, condition-by-condition explanation, and a short quoted proof where available.
Example conditions:
This is designed for agents that need an evidence-based decision before taking the next action.
| Tool | Description | Price |
|---|---|---|
consultar_ia | Sends a prompt to the OpenAI Responses API. | $0.02 USDC |
analisar_url | Fetches and analyzes a public HTTP or HTTPS page. | $0.05 USDC |
verificar_condicoes | Verifies concrete conditions on a public page and returns evidence-based decisions. | $0.05 USDC |
/v1/responses| Variable | Required | Description |
|---|---|---|
OPENAI_API_KEY | Yes | OpenAI project API key. |
OPENAI_MODEL | No | OpenAI model. Defaults to gpt-5-mini. |
HOST | No | Listening host. Defaults to 0.0.0.0. |
PORT | No | Listening port. Defaults to 3000. |
RAILWAY_PUBLIC_DOMAIN | Railway | Automatically supplied by Railway. |
PUBLIC_SERVICE_URL | No | Canonical public HTTPS origin used in discovery metadata. Railway derives it automatically from RAILWAY_PUBLIC_DOMAIN; the production URL is the fallback. |
OBSERVABILITY_SALT | Recommended | Stable secret salt used only to pseudonymize source/client fingerprints across restarts. |
| Variable | Required | Description |
|---|---|---|
EVM_PRIVATE_KEY | Yes | Private key of the Base mainnet buyer wallet. Never commit this value. |
JOURNEY_ID | No | Existing correlation ID to reuse; otherwise the buyer generates one. |
Example local .env.test file:
Install dependencies:
Start the development server:
Build the project:
Start the compiled server:
The health endpoint is public and does not require payment:
Railway currently accepts --since for historical HTTP logs but rejects
--until. On Windows PowerShell, export a bounded application and HTTP log
window without using the broken flag:
The script retrieves logs from the lower bound and applies the upper UTC bound
locally using ordinal ISO-8601 comparison, which preserves Railway's nanosecond
timestamps. It writes raw captures plus bounded app and http NDJSON files.
Analyze both bounded files while reading and validating every physical line:
The report includes per-file coverage, empty/valid/invalid line counts,
timestamp bounds, separation of Diogo-*, RailwayHealthcheck, known probes
or indexers and potentially external traffic, journey reconstruction and funnel
stopping points. It joins application railwayRequestId values to Railway HTTP
requestId values, understands HTTP clientUa, groups server-generated journey
IDs by fingerprint and temporal proximity, and counts only accepted normalized
feedback. It deliberately does not treat an isolated 402 as purchase intent
and does not infer human identity or motivation from request metadata.
The repository includes ready-to-run buyers for applications and AI agents. The MCP buyer connects to the live service, validates the x402 payment requirements against Base mainnet USDC and a maximum payment of $0.05, signs the payment, retries the same tool call, and prints the settlement receipt and result.
Clone and prepare the buyer:
Create a local .env.test file in the project root:
Never commit .env.test or expose the private key.
Build the project:
The following commands authorize real x402 payments on Base mainnet:
consultar_ia: $0.02 USDCanalisar_url: $0.05 USDCverificar_condicoes: $0.05 USDCA successful MCP payment prints:
PAGAMENTO MCP: successThe MCP buyer never prints the private key and rejects any payment that:
The discovery document at GET /.well-known/x402 and every successful free
preflight response publish a complete continuation sequence. A compatible
agent no longer has to infer what to do after the first unpaid request:
x-journey-id;payment-required requirements;REST metadata recommends @x402/fetch; MCP metadata recommends @x402/mcp.
Paid responses also link back to the discovery instructions through
x-payment-instructions. They additionally publish an RFC 8288 Link header
with the registered payment and help relations, so generic HTTP agents can
discover the same machine-readable continuation and optional feedback path
without depending on project-specific headers. The flow never requests a
private key, Railway or GitHub credentials, or an OpenAI key.
Every paid HTTP or MCP response advertises x-feedback-endpoint and the
allowed normalized reason, stage, and intent values. The free preflight
responses include the same information in a feedback block. Feedback is
submitted to POST /feedback, contains no free text, and never includes a
private key, prompt, URL, page content, or payment payload.
The three buyers accept:
When --feedback-reason is supplied without --feedback-stage, the stage
defaults to payment and the buyer does not authorize a payment. The HTTP
buyers first receive the unsigned 402 challenge, submit the explicit feedback,
and stop. The MCP buyer stops after its free preflight and submits the explicit
feedback without requiring a wallet.
Example: report that the price stopped an evaluation, without paying:
To submit explicit feedback after a completed delivery, select that stage:
Buyers automatically submit only integration_error, and only for an
objectively detected technical failure such as failed discovery/preflight, an
HTTP 5xx result, a paid MCP tool error, or a missing settlement receipt after
a payment was made. They never infer price, research_only, no_wallet, or
another human or commercial motivation.
After deployment, validate discovery, preflight, the OpenAPI feedback contract, normalized feedback submission, HTTP 402 challenges and feedback headers, HTTP method handling, MCP initialization, tool discovery and the MCP x402 challenge:
Use SERVICE_URL to target another deployment. The test uses one persistent
x-journey-id, sends User-Agent: Diogo-Smoke/1.2.9, verifies that the MCP
x402 challenge advertises the public HTTPS endpoint with type=mcp and the
correct toolName, and never creates or
signs a payment.
The three payment buyers now perform discovery and a free preflight before the
paid request, using the same persistent journey ID throughout. Set JOURNEY_ID
to reuse an existing journey; otherwise each buyer creates and prints one.
The MCP buyer additionally requires the exact advertised price, Base USDC,
Base mainnet, and the configured service recipient before it can sign.
The server emits structured events for MCP tool attempts, x402 challenges, payment verification, execution, settlement and final tool outcome. It does not log tool arguments or payment payloads. Settlement logs include the public network and transaction identifier so completed purchases can be counted and deduplicated.
Rejected MCP requests include safe protocol diagnostics such as method,
content type, Accept, JSON-RPC shape and the SDK error classification. All
events include the request and journey correlation fields when available.
Calls to a known paid tool that never reach its payment wrapper additionally
emit mcp_pre_payment_rejection, classified as invalid method, content type,
JSON-RPC envelope, arguments, transport/protocol rejection, or an otherwise
unreached handler. Argument values and payment payloads are never logged.
OpenAI usage events inherit the same request, journey, client, and source
correlation. Railway's X-Railway-Request-Id, edge POP, and request-start time
are also recorded, while client source fingerprints use Railway's stable
X-Real-IP value and remain pseudonymized with OBSERVABILITY_SALT.
The main branch is connected to Railway. Every successful push triggers a new deployment. Railway uses:
The deployment health-check path is /health.
ISC