Live Base mainnet gas oracle: current gas price, base fee, recent base fee trend, priority fee percentiles, and the estimated cost of a plain ERC-20 transfer in ETH. Costs $0.001 per call, paid in USDC over x402 on Base. Calling this tool returns the payment requirements; failed calls are never billed.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses cost ($0.001 per call), payment method (USDC over x402), that failed calls are never billed, and that calling returns payment requirements. This is thorough and sets accurate expectations for a paid oracle tool.
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?
Two sentences, front-loaded with the tool's purpose, then specific data points, then cost and billing details. Every sentence adds value without redundancy. Perfectly sized for a stateless oracle tool.
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 description covers return content, cost, billing, and failure behavior. With no output schema and no annotations, this is complete for an agent to understand what to expect and how to handle the tool. No missing critical context.
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?
There are zero parameters, so schema coverage is vacuously 100%. The description goes beyond the schema by explaining what the tool returns (gas components and cost estimate), which is valuable for an agent deciding whether to call it and how to interpret the response.
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 opens with a specific verb and resource: 'Live Base mainnet gas oracle', then enumerates the exact data returned (current gas price, base fee, trend, priority fee percentiles, transfer cost). This clearly distinguishes it from sibling tools like base_price or base_token_price, which deal with asset prices, not gas metrics.
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?
While it doesn't explicitly state 'use this when you need gas data', the description implies its purpose and differentiates it from siblings by content. It also mentions payment requirements and failed-call billing, giving implicit context for when to call (when gas info needed) and what to expect. Could be improved by explicitly stating alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct concern: address pre-flight, allowance, contract audit, contract type, gas, portfolio, prices, tx status. Even the two pricing tools are clearly separated (Chainlink ETH/BTC vs. any token via Uniswap V3), so selection ambiguity is minimal.
All tools share the base_ prefix and snake_case, which is highly predictable. However, the pattern mixes noun-style names (base_allowance, base_gas, base_token) with verb-including names (base_simulate_transfer, base_tx_check), so it is not a pure verb_noun convention throughout.
Twelve tools is a well-scoped set for a Base-focused on-chain analytics server. Each tool provides a meaningful capability without bloating the surface, and the free demo tool is a sensible inclusion.
The server covers the main read/analytics lifecycle: address checks, contract verification, token metadata, pricing, gas, portfolio, allowances, simulation, and transaction confirmation. Minor gaps exist, such as no generic contract-state reader or non-synthetic historical deep dives, but the core domain is well served.