Skip to main content
Glama

Onchain Read (EVM / Base)

agentbit.onchain_read
Read-onlyIdempotent

Cheap generic EVM reads on Base for AI agents: native balance, nonce, contract code, ERC-20 token balance, eth_call, gas price, latest block, and transaction/receipt lookups. One call, read-only, $0.001. Pay-per-call via x402 (USDC, Base).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "method": "<method>"
    },
    "name": "agentbit.onchain_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoContract address for method=call
dataNo0x-prefixed hex calldata for method=call
hashNoTransaction hash (0x + 64 hex) for method=tx/receipt
tokenNoERC-20 contract address for method=token_balance
methodYesWhich read to perform
addressNoEVM address (0x + 40 hex) — for balance/nonce/code/token_balance (the holder)
_paymentNoOptional base64 x402 PAYMENT-SIGNATURE payload. Omit to receive payment requirements.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds genuinely new operational context: unit cost ($0.001) and the x402 pay-per-call mechanism (USDC on Base), which materially affects whether an agent invokes it. It still does not mention rate limits or 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.

Conciseness5/5

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

Two tight sentences, ledger of capabilities front-loaded, pricing and payment constraints trailing. No wasted words and nothing redunant.

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?

Annotations carry the safety profile and there is no output schema to explain; the description plus schema together give an agent enough to call it. Minor gap: no note on which method requires which secondary parameter, though the schema covers that per-field.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the method enum is fully self-documenting, so the schema does the heavy lifting. The description lists the same read types the enum already encodes but adds no syntax, format, or edge-case guidance beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read) and resource (EVM/Base onchain data) and enumerates the supported reads: balance, nonce, code, ERC-20 token balance, eth_call, gas price, latest block, tx/receipt. An agent can tell it is a broad generic onchain reader, but the description never acknowledges overlap with siblings like agentbit.onchain_gas (gas price) or agentbit.wallet_transactions, so the boundary is inferred rather than stated.

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?

Usage is implied ('for AI agents', 'one call, read-only') but there is no explicit when-to-use guidance and no named alternative. For a tool that overlaps several siblings, the absence of any routing rule keeps this at minimum-viable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.