Skip to main content
Glama
Sign In

JW3 MCP Server

by io.github.agnostic4321-ops
OverviewDiscussionsAdmin

Read onchain balances

read_onchain_balances
Read-only

Read-only onchain wallet balances across EVM/Solana/TON/Tron/BTC via the balance cache + public RPCs. Server resolves the user's wallet addresses itself (addresses only, never keys). The chains filter uses canonical slugs and matches non-EVM chains exactly — sol never matches solana, bitcoin reads as btc; one linked EVM address is readable on any requested EVM chain. TON matches by chain slug, not address form — raw (0:…), bounceable (EQ…) and non-bounceable (UQ…) versions of one wallet resolve to the same balance. Every linked wallet and every requested chain gets an explicit row in reads (ok | empty | invalid-address | no-wallet): lowercased Solana/Tron rows surface as invalid-address with a re-link hint instead of vanishing.

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": "read_onchain_balances"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainsNoOptional comma list of canonical chain slugs, e.g. ethereum,solana. Non-EVM slugs (solana, ton, tron, btc) match exactly — no aliases or substrings; ton covers every TON address version. EVM slugs expand: one linked EVM address reads on any requested EVM chain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Annotations only supply readOnlyHint and openWorldHint; the description adds substantial behavior beyond them — the cache+RPC data path, that the server resolves addresses itself and never touches keys, exact-slug matching rules, EVM address reuse across chains, TON address-form equivalence, and that every wallet/chain pair yields an explicit row with a status (ok | empty | invalid-address | no-wallet) and a re-link hint for lowercased Solana/Tron rows.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The lead sentence is well front-loaded, but the remainder is a dense run-on that re-states schema content (non-EVM exact matching, TON address versions, EVM expansion) already present in the `chains` description. The status/row narrative is valuable; the chain-matching recap is partly redundant.

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?

With no output schema, the description usefully explains the shape of results via the `reads` row model and its status values. It stops short of describing ordering, pagination, or value formatting (decimals/native units), which are the remaining unknowns for a balance-reading tool.

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?

Schema coverage is already 100% for the single `chains` parameter, so the baseline is 3; the description goes further by spelling out the concrete matching gotchas ('sol' never matches 'solana', 'bitcoin' reads as 'btc') and confirming that 'ton' covers all address versions. The 'bitcoin reads as btc' phrasing is slightly ambiguous about whether 'bitcoin' is accepted, which keeps it off a 5.

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?

The first sentence states a specific verb and resource ('Read-only onchain wallet balances') plus the supported chain families and data sources (balance cache + public RPCs). It implicitly differentiates from read_venue_balances by specifying 'onchain wallet' as opposed to venue-held funds, but never names an alternative explicitly.

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 rather than stated: an agent can infer this is the tool for wallet balances across chains, and it is told the server resolves addresses itself so no address argument is needed. There is no explicit when-to-use / when-not / alternative-tool routing guidance.

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

All JW3 MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources