Confirm a Base mainnet transaction: success or reverted, block, confirmations and finality, gas used, and every ERC-20 transfer it moved with USDC amounts decoded. Costs $0.002 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 |
|---|---|---|---|
| hash | Yes | Base mainnet transaction hash (0x-prefixed, 32 bytes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it details output content, cost ($0.002 per call), payment method (USDC over x402), and billing behavior (failed calls not billed). This goes beyond minimal requirements and clearly explains what happens when called, including the return of payment requirements.
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 three sentences are efficiently written, with the main purpose first, followed by cost and billing details. Every sentence adds unique value, and there is no fluff or repetition. The description is well-structured and front-loaded with the most important 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?
Given a single-parameter tool with no output schema or annotations, the description is complete: it explains the tool's purpose, lists the return data, and covers cost and error-billing nuances. It provides all necessary context for an agent to invoke it 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 schema already describes the sole parameter 'hash' with 100% coverage ('Base mainnet transaction hash (0x-prefixed, 32 bytes)'). The description does not add parameter-specific details, so with high schema coverage the baseline of 3 applies as per calibration guidance.
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 a specific verb ('Confirm') and resource ('Base mainnet transaction') and enumerates the exact outputs (success/reverted, block, confirmations, finality, gas used, ERC-20 transfers with USDC amounts), which distinguishes it from siblings like base_gas or base_token_price. It is highly specific and action-oriented.
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 the tool is for confirming transaction details but does not explicitly state when to use it versus alternatives like base_address_check or base_simulate_transfer. The use case is inferred from the verb 'Confirm' and the output list, which is implied usage rather than explicit guidance.
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.