Skip to main content
Glama

Novarithm Agent Hub: trust and commerce checks

chain_balance

[PAID $0.003 USDC/call, x402, eip155:8453] Native ETH balance of any Base address, in wei and ETH, with the block of the read.

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": {
      "address": "<address>"
    },
    "name": "chain_balance"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressYesEVM address, 0x + 40 hex

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description itself supplies important behavior: a $0.003 USDC per-call charge, x402 payment, chain ID eip155:8453, results in wei and ETH, and the block at which the read occurred. “Read” implies a non-mutating lookup, but the description does not explicitly declare read-only behavior or explain payment and read failures.

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?

One compact line front-loads price, payment, and network metadata, then states the asset, address scope, output units, and block provenance. Every phrase contributes operational or selection information, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter balance lookup, the description and schema together provide the chain, asset, input format, cost, payment mechanism, output units, and read block needed to select and invoke it. An explicit usdc_balance cross-reference or read-only guarantee would help, but these are minor omissions given the already unambiguous native-ETH read scope.

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?

The sole address parameter is already fully documented by the schema as “EVM address, 0x + 40 hex,” and its required status is explicit. The description’s “any Base address” confirms scope but adds no substantive syntax, validation, or example beyond that coverage.

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 precisely identifies the operation and resource: reading the native ETH balance of any address on Base. “Native ETH” and the Base/eip155:8453 scope distinguish it semantically from usdc_balance and from siblings covering blocks, nonces, gas, code, and transactions.

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?

An agent can clearly select it when it needs an ETH-denominated balance on Base rather than a USDC balance or other chain state. It does not explicitly name usdc_balance as an alternative or state exclusions such as ERC-20 token balances, so the routing guidance is not exhaustive.

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.