x402-mcp-server_by_milza

Name: x402-mcp-server_by_milza
Author: Jannis-E

by Jannis-E

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

x402-mcp-server

Headless Chromium scraping, DOM-to-markdown extraction, and ephemeral secret vaults on Base Mainnet via x402 micro-payments — no API keys, no signup, pay per call in USDC.

This MCP server exposes a small catalog of x402-paywalled HTTP tools as native MCP tools. Every tool call pays for itself automatically: the server POSTs the request, catches the real x402 v2 402 PAYMENT-REQUIRED challenge, signs an EIP-3009 TransferWithAuthorization with viem using a local wallet, and resubmits with the PAYMENT-SIGNATURE header. No human signature prompt at call time — the agent just calls the tool.

Tools

Tool	Cost (USDC)	Description	Key input parameters
`spa-dom-to-md`	0.03	Renders JavaScript-heavy SPA pages in real headless Chromium (Cloudflare Browser Rendering), waits for network-idle/selector-ready, strips nav/footer/script chrome, and serializes the fully-rendered DOM into clean, LLM-ready Markdown.	`url` (string, required)
`markdown-extractor`	0.01	Fetches a public URL and returns clean, token-efficient markdown. For static/server-rendered pages.	`url` (string, required)
`burn-once-secret-vault`	0.01	Stores a secret (API key, webhook payload, signed URL) encrypted with AES-256-GCM and returns a claim URL that yields the secret exactly once, with an Ed25519-signed burn attestation. The recipient's claim read is free.	`secret` (string, required)
`svg-bar-chart-renderer`	0.015	Deterministic, paid-per-render SVG bar chart generator. Accepts labeled scalar data and layout options and returns schema-valid, byte-identical SVG for identical input.	`data` (array of `{label, value}`, required), layout options (optional)

All tools run on Base Mainnet (eip155:8453), settled through the x402.primer.systems facilitator. Exact request-body fields for each tool are also discoverable at runtime via <tool-url>/openapi.json.

Related MCP server: x402-json-repair-mcp

Quickstart

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "x402-mcp-server": {
      "command": "npx",
      "args": ["-y", "x402-mcp-server_by_milza"],
      "env": {
        "BASE_PRIVATE_KEY": "0xyour_base_mainnet_private_key"
      }
    }
  }
}

⚠️ Funding warning: BASE_PRIVATE_KEY must be a Base Mainnet wallet private key funded with a small amount of real USDC (e.g. $0.50 is enough for dozens of calls at these prices). Every tool call spends real money from this wallet. Do not use a key that holds funds you're not prepared to spend through this server, and never commit this key to source control.

Once configured, restart Claude Desktop and the four tools above become available to the assistant automatically — no further setup, no dashboard, no API key registration.

How payment works

BASE_PRIVATE_KEY is your own wallet — whoever installs this server sets their own key and pays for their own calls. Each call settles straight to the tool provider's wallet; your key never touches anyone else's funds and no one else's key ever touches yours. To set it up:

Use (or create) a Base Mainnet EVM wallet you're OK spending small amounts from.
Fund it with a bit of USDC on Base (e.g. $0.50).
Export its private key and set it as BASE_PRIVATE_KEY in your MCP client config, as shown above.

Security

BASE_PRIVATE_KEY never leaves your machine. It is read once from the local environment and used only to sign EIP-712 typed-data (EIP-3009 TransferWithAuthorization) payment authorizations locally with viem.
No raw private key, seed phrase, or signature is ever sent over the network — only the resulting signed authorization, exactly as the x402 protocol requires to settle payment for the specific request being made.
Payment terms (recipient, amount, network, asset contract, expiry) are read fresh from each live 402 challenge returned by the resource server, never trusted from a local cache, so a stale or tampered local catalog can't redirect funds.
This package does not phone home, collect telemetry, or store your key anywhere on disk.

Requirements

Node.js 18+
A Base Mainnet EVM wallet, funded with a small amount of USDC, whose private key you control

License

MIT

Available Tools

4 tools

burn-once-secret-vaultA

Store a secret (API key, webhook payload, signed URL) encrypted with WebCrypto AES-256-GCM and share a claim URL that yields the secret exactly once. A Durable Object serializes reads so single-use delivery is race-free, and every burn returns an Ed25519-signed attestation. Creating a vault requires x402 payment; the recipient's claim read (GET /v/:vault_id) is free. Costs 0.01 USDC per call on eip155:8453, paid automatically from BASE_PRIVATE_KEY. Request body fields are tool-specific -- see https://burn-once-secret-vault.jannioura.workers.dev/openapi.json.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses the encryption algorithm, single-use race-free delivery via Durable Object, Ed25519-signed attestations, payment requirements, chain details, and automatic payment from BASE_PRIVATE_KEY. This is rich behavioral disclosure beyond what any schema could provide.

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

Conciseness5/5

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

Four dense sentences, each adding essential information: purpose, delivery guarantee, payment model, and body-field documentation. It is front-loaded with the core behavior and wastes no words.

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

Completeness4/5

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

For a tool with no output schema and no annotations, the description covers the essential invocation details: encryption, single-use semantics, attestation, cost, payment source, and where to find request-body fields. The only minor gap is that it doesn't inline the actual body fields, but the provided OpenAPI URL adequately closes that gap.

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?

The input schema has zero formal parameters and is open, so the description cannot rely on schema documentation. It explicitly states that request body fields are tool-specific and provides a direct URL to the OpenAPI spec, giving the agent a way to resolve exact parameter semantics. It doesn't list the fields inline, so it stops short of a 5.

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 names a specific verb ('Store'), a concrete resource ('a secret'), and the key behavior ('claim URL that yields the secret exactly once'). This clearly differentiates it from the unrelated sibling tools, leaving no ambiguity about what the tool does.

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?

It explains when this tool is relevant and gives operational context: creating a vault requires x402 payment, claiming is free, and costs are paid automatically. It does not explicitly name alternatives, but the sibling tools are functionally unrelated, so explicit exclusions are unnecessary.

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

markdown-extractorA

Fetches a public URL and returns clean, token-efficient markdown, paywalled with the x402 v2 protocol on Base Mainnet. Designed for autonomous AI agents to call directly: no API key, no signup — pay per call in USDC. Costs 0.01 USDC per call on eip155:8453, paid automatically from BASE_PRIVATE_KEY. Request body fields are tool-specific -- see https://markdown-extractor.jannioura.workers.dev/openapi.json.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it does well: it discloses the paid nature, the x402 v2 protocol, the Base Mainnet network, the exact cost of 0.01 USDC per call, and automatic payment from BASE_PRIVATE_KEY. It also points to external API documentation for request body details. It could add failure behaviors or rate limits, but the key side effect—charging money—is explicitly stated.

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 three sentences and information-dense. The core action is front-loaded, followed by the payment/authentication model, then the pointer to detailed request fields. No sentence is filler; the only minor issue is some jargon ('x402 v2 protocol', 'eip155:8453') that may be opaque to some agents but is still precise.

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

Completeness4/5

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

For a tool with empty schema, no annotations, and no output schema, the description covers the essentials: what it does, cost, network, payment source, and where to find request body details. It could be more complete by stating the exact URL field name or response format, but the external OpenAPI link reduces that gap. It is strong but not flawless.

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?

The input schema is effectively open with additionalProperties true and zero declared parameters, so the description must compensate. It does not enumerate fields, but it identifies the core input by saying the tool 'fetches a public URL' and directs agents to the OpenAPI spec for tool-specific request body fields. This adds meaning beyond the empty schema, though it relies on an external URL rather than being fully self-contained.

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 opens with a specific verb and resource: 'Fetches a public URL and returns clean, token-efficient markdown.' This clearly distinguishes it from sibling tools like spa-dom-to-md or svg-bar-chart-renderer by emphasizing URL fetching and markdown conversion. Even without naming siblings, the core function is unmistakable.

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 gives clear usage context: it is 'designed for autonomous AI agents to call directly,' requires no API key or signup, and is restricted to public URLs. It explains the payment model and cost, which is essential for deciding when to use it. It does not explicitly contrast it with sibling tools, so it stops short of full alternative-based guidance.

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

spa-dom-to-mdA

Renders JavaScript-heavy SPA pages in real headless Chromium via Cloudflare Browser Rendering, waits for network-idle / selector-ready, strips nav/footer/script chrome, and serializes the fully-rendered DOM into clean, LLM-ready Markdown. Costs 0.03 USDC per call on eip155:8453, paid automatically from BASE_PRIVATE_KEY. Request body fields are tool-specific -- see https://spa-dom-to-md.jannioura.workers.dev/openapi.json.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses meaningful behavior: real headless Chromium via Cloudflare Browser Rendering, network-idle/selector-ready waiting, chrome stripping, and a per-call cost of 0.03 USDC paid from BASE_PRIVATE_KEY. This goes well beyond a simple render-to-markdown claim, though it omits rate limits, timeouts, and failure behavior.

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?

Three sentences, each earning its place: main behavior, cost/payment, and input documentation pointer. The first sentence is dense but not padded, and the key rendering purpose is front-loaded.

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

Completeness4/5

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

For a complex tool with no annotations and no output schema, the description covers the core rendering pipeline, cost, funding source, and input docs location. It does not explain return structure beyond 'Markdown' or error/timeout behavior, and it lacks explicit sibling distinctions, but the provided details are substantial.

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?

The input schema is an open object with additionalProperties true, so it defines no real fields. The description adds that request body fields are tool-specific and points to an OpenAPI spec, telling the agent where to get the actual parameter definitions. This exceeds the empty schema, though it does not inline the parameter semantics.

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 names a specific verb and resource: renders JS-heavy SPA pages in headless Chromium and serializes the fully-rendered DOM into Markdown. It also specifies what it strips (nav/footer/script chrome), which clearly separates it from a generic markdown extractor.

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

Usage Guidelines3/5

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

The context for use is implied by 'Renders JavaScript-heavy SPA pages in real headless Chromium' – an agent can infer this is for dynamic pages requiring real browser rendering. However, there is no explicit when-to-use/not-use guidance or comparison against siblings like markdown-extractor.

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

svg-bar-chart-rendererA

Deterministic, paid-per-render SVG bar chart generator for LLM agents. Accepts labeled scalar data and layout options, performs exact geometry math (min/max normalization, nice-interval y-axis ticks, label spacing, bar-width distribution), and returns schema-valid, escape-correct SVG with identical input always yielding byte-identical output. Costs 0.015 USDC per call on eip155:8453, paid automatically from BASE_PRIVATE_KEY. Request body fields are tool-specific -- see https://svg-bar-chart-renderer.jannioura.workers.dev/openapi.json.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

There are no annotations, so the description carries full behavioral burden. It discloses determinism, per-call cost, payment mechanism, exact geometry computation, escape-correct output, and byte-identical repeatability—far beyond a basic summary.

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

Conciseness5/5

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

The description is dense and front-loaded: the first sentence immediately establishes what the tool is, for whom, and its key constraints. Every following sentence adds critical operational or behavioral detail without rambling.

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?

Despite no output schema and no annotations, the description covers purpose, input categories, rendering behavior, determinism, cost, payment, and a documentation link. This is sufficient for an agent to decide to invoke the tool and know what to expect.

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?

The input schema is empty with additionalProperties true, and the parameter count is zero, so the baseline is 4. The description adds meaningful semantic categories ('labeled scalar data and layout options') and points to the OpenAPI spec for tool-specific field details.

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 states a specific resource and action: 'SVG bar chart generator' that accepts labeled scalar data and layout options and returns SVG. This clearly distinguishes it from unrelated sibling tools like markdown-extractor and burn-once-secret-vault.

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 intended use case is clear: an LLM agent that needs a deterministic, paid SVG bar chart from labeled scalar data. It doesn't explicitly compare against alternatives, but the sibling tools are so unrelated that no further routing is necessary.

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.

4 tool updatesv0.1.0Sep 20, 2026
- First observedburn-once-secret-vault
- First observedmarkdown-extractor
- First observedspa-dom-to-md
- First observedsvg-bar-chart-renderer

Deploy Server

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

TDQS

A4.1/5.0

Scored 2026-09-20 16:35 across 4 tools

Disambiguation5/5

Each tool targets a distinct domain: secret vaulting, markdown extraction, SPA rendering, and SVG chart generation. There is no functional overlap between any pair of tools.

Naming Consistency3/5

Names are descriptive and readable, but they do not follow a single verb_noun or noun_verb pattern. Three use hyphenated noun phrases (burn-once-secret-vault, spa-dom-to-md, svg-bar-chart-renderer) while one uses a noun-noun compound (markdown-extractor).

Tool Count4/5

Four tools is a reasonable, focused set for a paid utility server. It is slightly thin for a general-purpose toolkit, but each tool is substantial and earns its place.

Completeness3/5

The tools are independent utilities rather than a CRUD domain, so completeness is hard to assess. Each tool appears self-contained for its stated purpose, but the set lacks any broader workflow cohesion and there is no obvious way to manage or inspect the x402 payment side.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

WarpPay402 Gateway CDeprecated
com.warppay402.api
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Autonomous Agents Browser Automation Web3 & Decentralized Tech
211
WarpPay402 Gateway C
com.warppay402.api
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Autonomous Agents Browser Automation Web3 & Decentralized Tech
212
x402-scraper
io.github.ihen404
Autonomous HTTP 402 Web Scraping Mesh on Base for $0.02 USDC.
Web Scraping Autonomous Agents Blockchain
1
sovereign-engine A
io.github.invertedhoologan
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
AI & Machine Learning Payments & Billing Cryptocurrency
2

Related MCP Servers

x402farm-mcp
Cryptocurrency Blockchain Web Scraping
laurenthalbrun
A
license
Not graded
quality
C
maintenance
MCP server that provides AI agents with pay-per-call access to a suite of tools (honeypot check, token market, DeFi yields, etc.) via USDC on Base using the x402 protocol.
Updated 2 months ago (2026-07-29 01:15 UTC)
1 npm
MIT
x402-json-repair-mcp
Developer Tools Payments & Billing
ktcod
F
license
Not graded
quality
B
maintenance
A small, autonomous, pay-per-call MCP server that AI agents discover and pay for per call, with revenue landing directly in a USDC wallet on Base via the x402 payment protocol.
Updated a month ago (2026-08-15 03:58 UTC)
-
agentreader-mcp
Browser Automation Web Scraping Text Summarization
ajanani1
A
license
Not graded
quality
D
maintenance
MCP server providing 11 pay-per-call web intelligence tools (page reading, PDF extraction, RSS parsing, screenshots, summarization, structured data extraction) for AI agents, paid automatically in USDC via the x402 protocol on Base mainnet with no API keys required.
Updated a month ago (2026-08-10 03:10 UTC)
19 npm
MIT
apex-operations-center
Web3 & Decentralized Tech Blockchain Cryptocurrency
nikotherelic
F
license
Not graded
quality
C
maintenance
Production-grade Model Context Protocol (MCP) server delivering paywalled Web3 micro-services powered by autonomous x402 payment challenges on Base Mainnet.
Updated a month ago (2026-08-05 15:06 UTC)
-

x402-mcp-server

Tools

Quickstart

How payment works

Security

Requirements

License

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers