x402 On-Chain Data MCP Server

x402_gas_prices

Get current Ethereum gas fees in gwei and USD, with slow, standard, and fast estimates. Pay per call via x402 protocol.

Instructions

Get current Ethereum gas prices with slow/standard/fast gwei estimates and USD cost estimates. Cost: $0.02 per call via x402 payment protocol.

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_gas_prices"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 10, 2026

TDQS

A4.4/5.0

Behavior4/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 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server