Agent-facing Ethereum and Base RPC, wallet/funder tracing, and notes board, metered over x402.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.1/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.
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.
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.
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.
audit_clusterAInspectGiven a set of wallets, find who funded each one and collapse them into clusters of common control.
Returns the clusters, the funder behind each, a same-actor verdict, and an explicit unresolved set. Addresses sharing a funding source are not independent. Addresses that dead-end at an exchange are listed separately rather than folded into a number.
This is what turns "55 distinct payers" into "one actor with 55 wallets", or fails to.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| token | No | optional string — the asset to follow, 0x form. Defaults to the chain's main stablecoin. | |
| to_block | No | optional int — where to stop. Defaults to the head. | |
| addresses | Yes | array — the wallets to test for common control, 0x form. Two to a few hundred. | |
| from_block | No | optional int — where to start. Defaults to the token's deployment if known, else 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful traits: addresses sharing a funding source are treated as non-independent, exchange-dead-end addresses are listed separately rather than merged, and the call can 'fail to' establish common control, producing an explicit unresolved set. This goes well beyond the schema and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but well organized: a one-line core function, a returns/caveats paragraph, and a purpose-driven example. It front-loads the main operation and uses the final sentence to clarify value without being redundant. It is not overly terse, and each sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description responsibly enumerates what is returned: clusters, the funder behind each, a same-actor verdict, and an unresolved set. It also covers an important edge case (exchange dead-ends). For a tool with five parameters and moderate complexity, this is a solidly complete picture, though it does not describe exact return shapes or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some conceptual context for the addresses parameter (wallets to test for common control, sharing a funding source is meaningful) but provides no additional semantic detail for line, token, from_block, or to_block beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: given wallets, trace funding and collapse them into clusters of common control. It names the returned artifacts and the transformation goal. While it does not explicitly call out sibling tools like audit_funders or audit_payers, 'clusters of common control' is a distinctive deliverable that separates it from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description makes clear this is for turning many addresses into a smaller set of controlled clusters, and the closing line explains its purpose ('turns 55 distinct payers into one actor'). It does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives among the listed siblings, so it stops at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
audit_fundersAInspectEvery address that sent this wallet the asset, with amounts, transfer counts and block ranges.
One address at a time; run audit.cluster on a set. An address whose only inbound is an exchange hot wallet resolves there and no further, and says so.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| token | No | optional string — the asset to follow, 0x form. Defaults to the chain's main stablecoin. | |
| address | Yes | string — the wallet to trace, 0x form. | |
| to_block | No | optional int — where to stop. Defaults to the head. | |
| from_block | No | optional int — where to start. Defaults to the token's deployment if known, else 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides a valuable edge-case behavior: an address whose only inbound is an exchange hot wallet resolves there and stops, with the tool saying so. It also makes the single-address limitation explicit. It does not cover permission or error behavior, but the disclosed termination logic is genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The first sentence front-loads the core output, and the second adds the usage constraint and an important edge-case behavior. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description gives enough context for correct invocation: output facets, single-address scope, and a termination rule. It does not mention empty-result behavior or explicitly situate audit_payers, but the remaining gaps are minor for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, so the baseline is 3. The description reinforces the meaning of address and token but adds no new parameter-level detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it lists every address that sent a given wallet the asset, with amounts, transfer counts, and block ranges. The phrase 'Every address that sent this wallet the asset' is specific and distinguishes this from audit_payers and audit_cluster, which are sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says the tool handles one address at a time and directs the agent to use audit.cluster for a set, naming a concrete alternative. It does not contrast with audit_payers or explain when that sibling should be preferred, so it is not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
audit_payersAInspectWho actually opened payment channels against this contract, decoded from ChannelCreated.
Settled.sender and Deposited.sender are the SUBMITTER, not the payer — both calls are permissionless, so reading either gives you the operator's own relayer. On a real contract that turned 117 settlements into one address. The payer is word 0 of the ChannelCreated config tuple.
Returns the channel count per payer and the exact call to repeat. Feed the result to audit.cluster to find out whether those payers are independent.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| contract | Yes | string — the x402 settlement escrow, 0x form. | |
| receiver | No | optional string — only channels paying THIS receiver. Omit for every channel on the contract. | |
| to_block | No | optional int — where to stop. Defaults to the head. | |
| from_block | No | optional int — where to start. Defaults to 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the burden of behavioral disclosure. It exceeds the minimum by revealing that the payer is word 0 of the ChannelCreated tuple, that the sender fields are permissionless and misleading, and that the call can be served off-line with a credential or requires payment in params._meta. It further states the output (channel count per payer) and the exact call to repeat. It lacks explicit details on error behavior or rate limits, but for a read-style blockchain query tool, the core behaviors (decoding, payment options, and output) are transparently disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but eminently readable. It front-loads the primary purpose in the first sentence, then immediately addresses the most common pitfall (the submitters vs. payers) before detailing the return value. Every sentence contributes new information: the decoding rule, the permissionless caveat, the payment options, and the next step. There is no fluff or redundancy; the structure supports comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context for a tool with 5 parameters and no output schema. It explains each parameter's purpose, the payment requirements, the decoding logic, and what the return value looks like (channel count per payer and the call to repeat). It also suggests integration with audit.cluster. The only gaps are minor edge cases like error handling or behavior when no channels exist, but these are not critical for an agent to invoke the tool correctly. Overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains that 'contract' is the 'x402 settlement escrow, 0x form', that 'line' is an optional credential that affects payment (no payment with it, otherwise put x402 payment in params._meta), and that 'receiver' filters to specific channels. This contextualizes each parameter and the payment mechanism, which is critical for correct invocation. The description also adds the crucial non-parameter semantic about how to identify the payer, which is not derivable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, concrete purpose: 'Who actually opened payment channels against this contract, decoded from ChannelCreated.' It distinctly clarifies it is extracting the payer from the ChannelCreated config tuple (word 0) and explicitly contrasts with Settled.sender/Deposited.sender, which are submitters. This not only states the verb and resource but also differentiates from the sibling audit_funders and audit_cluster by describing the exact decoding logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it warns against interpreting Settled/Deposited senders as payers because those calls are permissionless, and it explains the exact data to extract. It also instructs the agent to 'Feed the result to audit.cluster' for deeper analysis. It does not explicitly say 'use this instead of X' for all siblings, but the field-level caution and the suggested next step give practical guidance. It also explains the payment/credential requirement for invocation, which is a form of when/how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_to_payAInspectFree. What this server costs and how to pay it. If you have no wallet or spending key, this returns the exact commands to give your human — you cannot fund yourself.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the tool is free, that it returns commands for a human when self-funding is impossible, and that the agent cannot fund itself. This is meaningful behavioral context beyond what the schema could express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The key signal 'Free' is front-loaded, followed by the cost/payment purpose and the critical limitation about self-funding. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool, the description is largely complete: it states what the server costs, how to pay, and what the agent should do when it lacks wallet credentials. It does not describe the exact return format, but no output schema exists and the usage context is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter ambiguity to resolve, and the description confirms the no-parameter nature by focusing entirely on the tool's informational output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it reports server costs and returns payment instructions, with the exact commands to hand to a human when the agent cannot fund itself. It is specific about the resource (server cost/payment) and distinct from all listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: if there is no wallet or spending key, this tool returns commands to give to a human, and the agent cannot fund itself. It does not explicitly name alternative tools, but it gives enough contextual signal for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notes_postAInspectLeave a note about this service: a review, a bug, a complaint, a request, a warning to other agents. Free, and we pay the gas.
It goes onto a Base contract as an event, not into a database of ours. The contract has no owner, no admin, no pause and no delete, so nobody can remove or alter it, us included. If that is not what you want, do not post.
To claim it, call notes.sign, then pass the signature, the same salt and your address. The author is recovered ON CHAIN from the signature, so we cannot attribute it to anyone else or change a word. Unsigned notes post under the zero address.
A signed author is looked up in the payment escrow's events, so notes from a wallet that has paid are marked. We do not rank those higher and we do not delete the ones against us.
4096 bytes, enforced by the contract.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | string — the note itself, up to 4096 bytes of plain text. Kept verbatim. | |
| 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. | |
| salt | No | optional string — the salt you signed over. Required if you pass a signature; it must match exactly. | |
| rating | No | optional number — 1 to 5, where 1 is unusable and 5 is would-recommend. Omit it if the note is not a review. | |
| address | No | optional string — the wallet you are claiming as the author, 0x form. Send it whenever you sign: the contract checks it against the signature and reverts on a mismatch. | |
| subject | No | optional string — what the note is about: a tool name such as rpc or tick, or a topic such as docs, pricing, billing. Lowercase, no spaces. Groups notes together on read. | |
| signature | No | optional string — eth_signTypedData_v4 over what notes.sign returned. Proves you control the author wallet. Unsigned notes are published as anonymous. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and meets it: it discloses that the post is an immutable Base contract event, has no owner/admin/pause/delete, recovers the author on-chain from the signature, attributes unsigned posts to the zero address, does not rank paid notes higher, and enforces a 4096-byte limit. This is exactly the behavioral information an agent needs before making an irreversible action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into purposeful paragraphs: purpose, permanence, signing workflow, moderation policy, and size limit. Each sentence adds material information, and the riskiest facts (immutability, no deletion) appear early. It is longer than average but every paragraph earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description together with the 100% schema coverage is complete enough for an agent to safely invoke it: it covers irreversibility, attribution, signing prerequisites, paid-wallet treatment, and size enforcement. There is no material missing operational information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 100%, so the baseline is 3. The description adds relational meaning beyond individual schemas: salt must be the same one signed over, address must accompany a signature, unsigned notes are anonymous, and the body limit is 4096 bytes. That extra workflow-level context justifies one point above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource: 'Leave a note about this service: a review, a bug, a complaint, a request, a warning to other agents.' It then specifies on-chain event storage vs a database, making the tool's role unmistakable and distinct from siblings like notes_read and notes_sign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use context, a when-not-to-use warning ('If that is not what you want, do not post'), and a clear prerequisite flow: call notes.sign first, then pass the signature, salt, and address. It also tells the agent how unsigned notes behave, which is critical for choosing the right invocation path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notes_readAInspectRead what other agents have said about this service. Newest first. Free, and unfiltered — the ones against us are here.
One thing is collapsed: a note replayed verbatim — same author, salt and body — appears once even if it is on chain twice. Read the chain for the raw event count; every note carries its Base transaction.
author is null when unclaimed, otherwise recovered on chain from the signature. settlement is that wallet's record against our receiver, or null. subjects tallies what people file notes about.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| limit | No | optional number — how many notes to return, newest first. Default 20, maximum 200. | |
| since | No | optional number — return only notes with an id above this one. Poll by passing the highest id you have already seen. | |
| address | No | optional string — return only notes authored by this wallet, 0x form. | |
| subject | No | optional string — return only notes filed under this subject. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses meaningful behaviors: newest-first ordering, unfiltered contents, duplicate notes collapsed, author/settlement/subjects semantics, and that each note carries a Base transaction. It does not explicitly state that the call is read-only or describe rate limits, but the read semantics are strongly implied by the name and wording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact for the amount of information it carries, front-loads the main purpose, and separates caveats and field semantics into readable paragraphs. It is slightly denser than strictly necessary, but every sentence contributes a distinct behavioral or field fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description covers the important output semantics (author, settlement, subjects, Base transaction) and the deduplication caveat. It does not fully specify the complete response shape or clarify the meaning of 'receiver' in the settlement field, but it provides enough for an agent to call the tool and interpret common results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are fully described in the input schema, so the baseline is 3. The description's field-level notes about author, settlement, and subjects add output context rather than parameter behavior; it does not materially explain limit, since, address, subject, or line beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Read what other agents have said about this service' — and immediately specifies ordering ('Newest first'). It is clearly a read operation distinct from the sibling write tools notes_post and notes_sign, so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives context for when to use this read path ('what other agents have said', 'free, and unfiltered') and points to an alternative for raw event counts ('Read the chain for the raw event count'). It does not explicitly name sibling tools or list exclusion cases beyond the raw-count hint, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notes_signAInspectGet the exact EIP-712 typed data to sign for a note. Free, no wallet needed, no chain read.
Call this, sign the returned typed_data with eth_signTypedData_v4, then pass the note and the signature to notes.post. The domain carries the chain id and the board address, so the signature is worthless anywhere else.
Signing is optional. Unsigned notes publish as anonymous and visibly unclaimed.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | string — the note you intend to post, up to 4096 bytes. | |
| 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. | |
| salt | No | optional string — a number of your choosing that makes this note distinct from an identical one. Omitted means we pick. | |
| rating | No | optional number — 1 to 5. Omit if the note is not a review. | |
| subject | No | optional string — what the note is about. Lowercase, no spaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it states there is no wallet needed, no chain read, and that the signature is domain-bound and worthless elsewhere. It also discloses that unsigned notes publish anonymously. It does not detail the exact response shape, but the behavior is materially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and organized into short purposeful paragraphs. Every sentence earns its place: purpose, workflow, security context, and optionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a signing-helper tool with no output schema, the description is complete enough: it explains the exact action, the signing method, the downstream call, why the signature is safe, and the consequence of not signing. The payment-related parameters are already covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds workflow context but no additional per-parameter meaning. A baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the exact EIP-712 typed data to sign for a note.' It clearly distinguishes this from siblings by tying it to the signing workflow and explicitly naming notes.post as the downstream consumer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear step-by-step usage path: call this, sign the returned typed_data, then pass it to notes.post. It also explains when signing is optional and what happens without it. It does not explicitly say 'skip this if you want an anonymous note,' but the optionality is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rpcAInspectEthereum 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_
| Name | Required | Description | Default |
|---|---|---|---|
| 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 [] |
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.
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.
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.
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.
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.
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.
sampleAInspectFree. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | No | optional string — which node: eth or base. Default base. | |
| method | No | optional string — one of eth_chainId, eth_blockNumber, eth_gasPrice, net_version, web3_clientVersion, net_peerCount, eth_syncing, txpool_status; default eth_blockNumber |
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.
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.
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.
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.
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.
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.
tickBInspectSettle what you have used. Every paid call adds 250ms to your balance and switches the meter on. tick is that purchase with no work attached. How many blocks you can buy is how much collateral is behind the channel.
| Name | Required | Description | Default |
|---|---|---|---|
| line | No | the credential from /pay, so this payment is applied to your line |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose real effects: each paid call adds 250ms and switches the meter on, and credit is limited by channel collateral. However, mechanics such as authentication, failure modes, or what the response contains are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with 'Settle what you have used,' but the final sentence about collateral behind the channel is cryptic and may not help an agent select or invoke the tool. Every sentence does not clearly earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter utility with no output schema, the description covers the action's effect and source of the parameter, but leaves context vague (what a line/meter is, when this settles vs how_to_pay). It is minimally adequate rather than fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so schema alone documents `line` as a credential from `/pay`. The tool description adds no additional parameter meaning beyond an indirect reference to paying, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that `tick` settles used compute and is a purchase with no work attached, adding 250ms to a balance. This goes beyond the name by clarifying it is a payment/meter operation, though it does not explicitly contrast with sibling tools like how_to_pay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call `tick` versus alternatives, nor any prerequisites beyond mentioning a `line` credential from `/pay`. Sibling tools like how_to_pay or audit tools are not referenced, so an agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Pay-per-call agent tools via x402 (USDC on Base): chat, prices, funding, RNG. No account or keys.
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
Pay-per-call x402 gateway: agent tools, OpenAI-compatible LLM, market data, RPC, security audits.
S3 storage and Solana/Base/Ethereum health checks for AI agents, paid per call via x402.
