Provides tools to query Ethereum blockchain data including wallet profiles, token metrics, protocol TVL, and gas prices.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@x402 On-Chain Data MCP Server show gas prices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server wrapper for the x402 On-Chain Data API. Provides pay-per-call blockchain data including wallet profiles, token metrics, protocol TVL, and gas prices.
0xEtherial
Related MCP server: Onesource MCP
Wallet Profiles - ETH balance, transaction history, top tokens ($0.10/call)
Token Metrics - Price, market cap, volume, liquidity ($0.05/call)
Protocol TVL - Total value locked, chain breakdown ($0.05/call)
Gas Prices - Real-time gas estimates ($0.02/call)
Health Check - API status (free)
npm installCopy .env.example to .env and configure:
cp .env.example .envVariable | Description | Default |
| x402 On-Chain API base URL |
|
node server.jsx402_wallet_scoreGet comprehensive wallet profile.
Parameters:
address (string, required): Ethereum wallet address
Example:
{
"name": "x402_wallet_score",
"arguments": {
"address": "0x742d35Cc6634C0532925a3b844Bc9e7595f2bD5e"
}
}Returns: ETH balance, transaction count, first/last transaction, top 5 tokens
x402_token_metricsGet token price and market data.
Parameters:
address (string, required): Token contract address
Example:
{
"name": "x402_token_metrics",
"arguments": {
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
}
}Returns: Price, market cap, 24h volume, liquidity, FDV
x402_protocol_tvlGet DeFi protocol TVL data.
Parameters:
slug (string, required): Protocol identifier (e.g., "uniswap", "aave")
Example:
{
"name": "x402_protocol_tvl",
"arguments": {
"slug": "uniswap"
}
}Returns: TVL, 24h change, chain breakdown
x402_gas_pricesGet current Ethereum gas prices.
Parameters: None
Example:
{
"name": "x402_gas_prices",
"arguments": {}
}Returns: Slow/standard/fast gwei + USD estimates
x402_healthCheck API health status.
Parameters: None
Example:
{
"name": "x402_health",
"arguments": {}
}Returns: API health status
Open Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the MCP server to claude_desktop_config.json:
{
"mcpServers": {
"x402-onchain": {
"command": "node",
"args": ["/absolute/path/to/mcp-wrapper/server.js"],
"env": {
"API_BASE_URL": "https://nominated-safe-pairs-favorites.trycloudflare.com"
}
}
}
}Restart Claude Desktop
The x402 tools will appear in Claude's available tools
Open Cursor settings (Cmd+,)
Navigate to "Features" → "Model Context Protocol"
Add new server:
Name: x402-onchain
Command: node /absolute/path/to/mcp-wrapper/server.js
Environment: API_BASE_URL=https://nominated-safe-pairs-favorites.trycloudflare.com
Restart Cursor
Open Windsurf settings
Go to "AI" → "MCP Servers"
Click "Add Server"
Configure:
Name: x402-onchain
Command: node
Args: ["/absolute/path/to/mcp-wrapper/server.js"]
Env: {"API_BASE_URL": "https://nominated-safe-pairs-favorites.trycloudflare.com"}
Save and restart Windsurf
All endpoints use the x402 payment protocol (pay-per-call):
Endpoint | Cost | Description |
| $0.10 | Wallet profile + top tokens |
| $0.05 | Token price + metrics |
| $0.05 | Protocol TVL data |
| $0.02 | Gas price estimates |
| Free | Health check |
The server returns structured error responses:
{
"error": true,
"status": 404,
"message": "Wallet not found"
}Node.js >= 18.0.0
npm
npm installAPI_BASE_URL=http://localhost:8900 node server.jsMIT
Get current Ethereum gas prices with slow/standard/fast gwei estimates and USD cost estimates. Cost: $0.02 per call via x402 payment protocol.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about the paid nature of the call ("Cost: $0.02 per call via x402 payment protocol") and the specific estimates returned. It does not disclose potential side effects or rate limits, but the cost and payment requirement are meaningful disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose and outputs, the second discloses the cost. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is reasonably complete: it states what data is returned and the cost. It could mention update frequency or API key requirements, but these are not critical for basic understanding. Overall, it provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description adds useful information about the output types (slow/standard/fast gwei and USD cost estimates), which helps clarify what the tool returns even though there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool "Get current Ethereum gas prices" with specific output details (slow/standard/fast gwei estimates and USD cost estimates). This distinguishes it from sibling tools focused on wallet scores, token metrics, TVL, and health, all of which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use the tool (when you need current Ethereum gas prices with cost estimates), and the sibling tools are topically distinct, making the use case obvious. However, it does not explicitly mention when not to use it or list alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check API health status. Free endpoint - no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses the 'free' nature and implies a read-only operation via 'Check', but it does not describe whether authentication is required, what the response contains, or whether it checks underlying services. Adds some value beyond the empty schema, but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the core purpose front-loaded. The additional note about being a 'free endpoint' is a useful differentiator and earns its place without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 0-parameter health check tool. The description conveys its function and cost, which is adequate for basic selection. It could elaborate on what 'health status' entails or the response format, but given the simplicity, the current description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema already fully covers this (empty properties). The description does not need to add parameter semantics. Per rubric, a 0-parameter tool gets a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' with the resource 'API health status', clearly identifying the tool's purpose. It is distinct from sibling tools (wallet_score, token_metrics, etc.), which focus on metrics rather than health. However, it does not specify what 'health status' means (e.g., up/down, latency, dependencies) or the expected response format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description mentions it is a 'free endpoint', implying a cost advantage but does not state when this should be preferred over sibling tools or any exclusions. No sibling tools are referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DeFi protocol TVL data including total value locked, 24h change, and chain breakdown. Cost: $0.05 per call via x402 payment protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Protocol slug identifier (e.g., "uniswap", "aave") |
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 the cost ($0.05 per call) and payment protocol (x402), a key operational detail, and specifies output components. However, it omits rate limits, authorization requirements, and error behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states purpose and data content, the second discloses cost. No redundant text, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description covers the returned data categories and the cost model. It lacks explicit return structure or usage examples, but is otherwise adequate for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'slug' parameter is fully described in the schema with examples. The description adds no additional parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'DeFi protocol TVL data' and enumerates included fields (total value locked, 24h change, chain breakdown). This distinguishes it from sibling tools focused on wallet scores, token metrics, gas prices, and health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying protocol TVL but does not explicitly state when to prefer this tool over siblings or provide exclusions. No direct comparison to alternatives is made, though sibling names hint at distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token data including price, market cap, 24h volume, liquidity, and FDV. Cost: $0.05 per call via x402 payment protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Token contract address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the $0.05 cost and the x402 payment protocol, which is a significant behavioral trait, and the verb 'Get' implies a read-only operation. However, it doesn't mention error scenarios, authentication, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action ('Get token data') and packs in the output fields and cost without any redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description adequately covers the output scope and cost. It could be slightly more complete by noting the return structure or behavior on invalid addresses, but given the tool's simplicity, it is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter 'address' as 'Token contract address (0x...)', and the description adds no further detail about formatting or defaults. This meets the baseline given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves token data with a specific list of metrics (price, market cap, 24h volume, liquidity, FDV). This makes it distinct from sibling tools like wallet_score or protocol_tvl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives, but the purpose is clear enough that usage can be inferred when token-specific data is needed. It lacks any mention of exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive wallet profile including ETH balance, transaction count, first/last transaction timestamps, and top 5 tokens held. Cost: $0.10 per call via x402 payment protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum wallet address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It uniquely discloses a cost of $0.10 per call via the x402 payment protocol, which is critical behavioral information. It also lists the specific data fields returned, giving a clear sense of the tool's read behavior. It does not mention failure modes or authentication details, but the cost disclosure is a strong plus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that leads with the core action, enumerates the data items, and ends with cost. Every word earns its place; there is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers what data is returned, the cost, and the payment protocol. It does not explain the return format or error behavior, but for a read-only wallet profile tool with transparent pricing, this is largely complete. A score of 4 recognizes the missing but non-critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'address' parameter with a description 'Ethereum wallet address (0x...)'. The tool description adds no further meaning about the parameter, such as format validation, network specifics, or examples. According to the baseline rule for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get comprehensive wallet profile' which is a specific verb and resource, followed by a concrete list of included data (ETH balance, transaction count, timestamps, top 5 tokens). This clearly distinguishes it from sibling tools like x402_token_metrics or x402_gas_prices, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by detailing the wallet-specific data, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no 'use this when...' or reference to sibling tools, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0x402_gas_pricesx402_healthx402_protocol_tvlx402_token_metricsx402_wallet_scoreScored across 5 tools
Each tool targets a distinct on-chain data category: wallet profile, token metrics, protocol TVL, gas prices, and health status. There is no overlap or ambiguity between the tool purposes.
All tool names follow a consistent `x402_` prefix followed by a descriptive noun phrase in snake_case. The naming pattern is uniform and predictable across the entire set.
The server offers 5 focused tools covering a reasonable breadth of on-chain data. This is well-scoped for its stated purpose and each tool earns its place.
The core on-chain data endpoints are covered (wallet, token, TVL, gas), plus a health check. Minor gaps exist such as block or transaction details, but the primary domain surface is solid.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Crypto MCP with 21 tools for market data, DeFi, analytics, and sentiment. Post-paid USDC billing.
Abstraxn: public Web3 MCP server for read-only chain data and pay-per-call relays.