ZEAM Prism MCP

rpc

Ethereum and Base JSON-RPC, forwarded to our own nodes.

BASE - chain:"base" reth v2.3.0-9384bc5, archive, at tip. Flashblocks on: the "pending" tag returns the preconfirmed next block.

eth_getLogs page it. Over 100,000 results the node replies with the exact range to retry. eth_accounts eth_blobBaseFee eth_blockNumber eth_call eth_callBundle eth_chainId eth_coinbase eth_createAccessList eth_estimateGas eth_feeHistory eth_gasPrice eth_getAccount eth_getBalance eth_getBlockByHash eth_getBlockByNumber eth_getBlockReceipts eth_getBlockTransactionCountByHash eth_getBlockTransactionCountByNumber eth_getCode eth_getFilterChanges eth_getFilterLogs eth_getLogs eth_getProof eth_getStorageAt eth_getTransactionByBlockHashAndIndex eth_getTransactionByBlockNumberAndIndex eth_getTransactionByHash eth_getTransactionCount eth_getTransactionReceipt eth_getUncleCountByBlockHash eth_getWork eth_hashrate eth_maxPriorityFeePerGas eth_mining eth_newBlockFilter eth_newFilter eth_newPendingTransactionFilter eth_protocolVersion eth_sendBundle eth_sendRawTransaction eth_simulateV1 eth_syncing eth_uninstallFilter net_listening net_peerCount net_version web3_clientVersion web3_sha3 txpool_content txpool_contentFrom txpool_inspect txpool_status debug_getRawBlock debug_getRawHeader debug_getRawReceipts debug_getRawTransaction debug_traceBlockByHash debug_traceBlockByNumber debug_traceCall debug_traceTransaction No trace_ methods are served on Base.

ETH - chain:"eth" reth v2.2.0-88505c7. State history is 10064 blocks. Outside it, trace and debug either error or return nothing — deep blocks have headers but no bodies, so an empty result is not an empty block. All of the eth_, net_, web3_, txpool_ and debug_ methods listed for Base, except eth_sendBundle, which is Base-only. trace_block trace_call trace_callMany trace_filter trace_get trace_rawTransaction trace_replayBlockTransactions trace_replayTransaction trace_transaction

Refused on both: admin_ personal_ miner_ engine_

Input Schema

TableJSON Schema

Name	Required	Description
`line`	No	optional — credential from the /pay socket. With it the call is served off your line and carries no payment. Without it, put x402 payment in params._meta.
`chain`	Yes	string — which node to forward to: eth or base
`method`	Yes	string — any JSON-RPC method the node serves: eth_, net_, web3_, txpool_, debug_, trace_. Node-control namespaces (admin_, personal_, miner_, engine_) are refused.
`params`	No	optional array — JSON-RPC params, default []

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses node versions, archive-at-tip behavior, Flashblocks 'pending' tag semantics, eth_getLogs pagination limits, the exact 10064-block state history on ETH, and the non-obvious fact that deep blocks return empty results because bodies are missing, not because the block is empty.

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?

The description is long but well-structured: a one-sentence intro, separate BASE and ETH sections, grouped method lists, and a final refusal rule. No filler is present; the length is justified by the need to document method availability and chain-specific quirks.

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 broad RPC tool with no annotations and no output schema, the description covers chains, method availability, pagination, state history, empty-result semantics, payment-line behavior, and refused namespaces. An agent has enough context to select the correct chain and method and to anticipate important edge cases.

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

Parameters5/5

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

Input schema coverage is 100%, so the baseline is 3, but the description adds substantial parameter-level meaning: it enumerates supported methods per chain, explains pagination behavior for eth_getLogs, documents trace_ restrictions on Base, and clarifies eth_sendBundle chain exclusivity. This goes far beyond the generic schema descriptions.

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 opens with 'Ethereum and Base JSON-RPC, forwarded to our own nodes,' which clearly identifies the tool as a JSON-RPC forwarding/calling tool for two specific chains. The detailed method lists and chain-specific notes distinguish it sharply from sibling tools like audit_cluster, notes_post, and tick, which have unrelated purposes.

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?

The description gives clear selection context: chain must be 'eth' or 'base', Base serves no trace_ methods, eth_sendBundle is Base-only, and admin_/personal_/miner_/engine_ namespaces are refused. It does not explicitly say 'use this tool when you need raw RPC access' or name alternatives, but the sibling tools are so unrelated that no alternative routing is needed.

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

All ZEAM Prism MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

The audit_* tools are carefully differentiated: cluster groups wallets, funders traces inbound transfers for one wallet, payers decodes channel openers. The notes_* tools also have clear lifecycle separation, and sample vs rpc is distinguished by free vs paid access. Minor overlap exists between sample and rpc since both expose RPC methods, but the descriptions make the boundary clear.

Naming Consistency3/5

There are consistent internal prefixes like audit_* and notes_*, but the overall surface mixes verb_noun (audit_cluster, audit_funders), noun_verb (notes_post, notes_read), and single bare words (rpc, sample, tick, how_to_pay). The names are readable and groupable, but they do not follow one predictable convention across the whole server.

Tool Count5/5

Ten tools is well within the ideal scope for a server with distinct functional areas: on-chain auditing, notes, RPC access, and payment/settlement. Each tool has a clear job, and none feel redundant or superfluous.

Completeness4/5

The core workflows are well covered: cluster auditing, funder/payer investigation, notes post/read/sign, RPC access, and payment instructions/settlement. A minor gap is the lack of a dedicated usage or credit read tool, though tick and how_to_pay partially cover the payment lifecycle.

Resources

Need Help?