Skip to main content
Glama

ZEAM Prism MCP

by com.zeamprism

sample

Free. No payment, no wallet. Works with no arguments.

args chain: eth|base (default base), method (default eth_blockNumber) methods eth_chainId, eth_blockNumber, eth_gasPrice, net_version, web3_clientVersion, net_peerCount, eth_syncing, txpool_status on eth or base checks same shelf and node as a paid call, so compare the answer to any other source

Matching block numbers prove the DATA, not the operator — a reseller matches too. What a reseller cannot serve is on the paid path: archive state at any height, debug_*, trace_*, and wide eth_getLogs over an arbitrary contract. Does not rule out a paid archive provider behind us. /bootstrap is a cached index of one contract, not the node — not proof of anything. web3_clientVersion names the BUILD, not the operator. net_peerCount is not liveness here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lineNooptional — 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.
chainNooptional string — which node: eth or base. Default base.
methodNooptional string — one of eth_chainId, eth_blockNumber, eth_gasPrice, net_version, web3_clientVersion, net_peerCount, eth_syncing, txpool_status; default eth_blockNumber

TDQS

A4/5.0
Behavior5/5

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

No annotations exist, so the description carries the full behavioral burden. It honestly discloses that matching block numbers prove data but not operator identity, that resellers can match, that advanced RPC features are unavailable on the free path, and that /bootstrap is only a cached index.

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

Conciseness4/5

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

The description is structured into core usage, method list, and caveat paragraphs, with the free claim front-loaded. It is longer than typical but each caveat earns its place for trust decisions, though phrases like "same shelf and node" are cryptic.

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

Completeness3/5

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

Input options and trust limitations are covered well, but the description never explicitly states that the tool returns the selected JSON-RPC method's result. Since there is no output schema, an explicit return-value statement and a clearer reconciliation of the no-payment claim with the x402 fallback would make it complete.

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 coverage is 100%, so the description's restatement of chain defaults and the method list adds little beyond the schema. There is also a lingering tension between the claim "No payment, no wallet" and the schema's instruction to put x402 payment in params._meta when no line credential is supplied.

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 description conveys a free, wallet-less sample of the eth/base RPC surface by listing valid methods and the default chain, and it contrasts this with the paid path. It does not use an explicit verb like "return" or "call," but the method list and the instruction to compare the answer make the operation clear.

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 opening states it is free with no payment or wallet, and the caveats explicitly move archive state, debug/trace, and wide eth_getLogs needs to the paid path. It tells the agent to compare results to any other source and warns about misleading signals such as web3_clientVersion and net_peerCount, though it never names the rpc sibling directly.

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 toolsInspect
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