ZEAM Prism MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it is paid and metered on the line, and a cut returns partial results with partial:true, newest first, and instructs to continue with to_block. It also explains the dead-end concept and why such senders are not control. This goes beyond the annotations and is useful for an agent deciding whether to call and how to handle results.

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 four sentences long, front-loaded with the core purpose and outcome, followed by operational details and an example. Every sentence adds information: the purpose, the dead-end caveat, the parameter mapping, and an illustrative example. There is zero fluff or redundancy. It is well-structured and easy to scan.

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 that an output schema exists (per context signals), the description does not need to explain return values. It covers the tool's purpose, usage boundaries, behavioral quirks (metering, partial results), and parameter conventions. It even provides an example. Minor omissions include explicit error conditions or limits beyond the address count, but these are not critical for an agent to invoke the tool correctly. The description is sufficiently complete for its 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?

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds a concrete example with addresses and from_block, clarifies the acceptable range of addresses ('two to a few hundred'), and notes that token, from_block, and window behave 'as on audit_funders'. This extra context helps an agent understand the format and consistency, but the schema already carries the bulk of the semantic load. The addition is useful but not critical.

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 specific verb ('audit') and resource ('a set of wallets'), then explains the exact outcome: clustering wallets by common funder, with a same-actor verdict and unresolved set. It explicitly contrasts with siblings (audit_funders, audit_payers) and even gives a concrete transformation example ('55 distinct payers' → 'one actor with 55 wallets'). This is unambiguous and distinguishes the tool from its alternatives.

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 when-to-use guidance: it is for a set of wallets, while audit_funders is for one wallet's inbound and audit_payers is for who paid an escrow. It also states a negative condition: a shared sender that is a contract or pays out to many parties is a dead end, never control. This tells the agent exactly when to expect a meaningful cluster and when not to. No inference needed.

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

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

Although annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds substantial behavioral detail: it is paid and metered, contract senders are classified as return paths rather than funders, smaller windows cost more calls, and from_block partial scans return newest-first results with partial:true for continuation. This goes well beyond the annotation surface.

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 every sentence carries critical information: core behavior, contract exclusion semantics, payment/metering, defaults, window tradeoffs, sibling routing, and a concrete example. There is no filler, and the most important semantic distinction is front-loaded.

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 presence of an output schema and full parameter schema coverage, the description supplies all remaining context an agent needs: payment model, continuity semantics for partial scans, default parameter behavior, cost/latency tradeoffs, and routing among sibling tools. Nothing essential is missing.

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 baseline is 3. The description adds meaningful semantics beyond the schema by explaining default behavior (token defaults to the chain's stablecoin, from_block defaults to token deployment), cost implications of window size, and how from_block partial results should be continued with to_block.

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 specific verb and resource: it identifies every address that sent a given wallet an asset and lists the exact outputs (amounts, transfer counts, block ranges, sender kind). It also differentiates the tool from siblings by explicitly naming audit_cluster and audit_payers with their distinct 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 says when to use this tool versus alternatives: 'For a set and a same-actor verdict, audit_cluster; for who paid an escrow, audit_payers.' It also provides contextual usage guidance around payment, metering, token defaults, and window size, so an agent can decide whether this path is appropriate.

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

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

Annotations already mark it read-only and idempotent; the description adds the cost model ('Paid, metered on the line'), partial-scan continuation behavior, and the non-obvious semantic trap that Settled.sender and Deposited.sender are not the payer. No contradiction with annotations.

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?

Three dense but purposeful sections: core semantics, scope/cost controls, and sibling exclusions, capped with a concrete example. The trickiest detail (who the payer actually is) is front-loaded, and no sentence is filler.

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 complexity of x402 payer attribution, the description covers domain knowledge, parameter behavior, cost model, and sibling boundaries, while an output schema exists to carry return-shape detail. An agent has enough to decide when to call and how to set scope.

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% and the schema already explains line, window, contract, receiver, to_block, and from_block in detail, including partial results and timing. The description mostly restates defaults and receiver filtering, adding only slight interpretive context, so the baseline 3 is appropriate.

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?

Opens with the precise question the tool answers ('Who actually opened payment channels against a given x402 escrow contract'), names the event source, and states the concrete return shape ('channel count per payer and the exact call to repeat'). It also explicitly contrasts with audit_funders and audit_cluster, so it is not confused with 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?

Gives explicit when-not guidance ('Not a funding trace (audit_funders), not a control verdict (audit_cluster)') and explains how to adjust receiver, from_block, and window to control scope and cost. The metering and read-only warning also signals when this is a safe call to make.

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

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

The description goes well beyond the annotations: it discloses that the operation is paid and settled on chain, is not idempotent, each call buys another block, the line is cut when balance runs out, nothing more is charged, and unused time is refunded. This is rich behavioral context with no contradiction to the annotations.

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 consistently purposeful, front-loading the core action and then layering lifecycle, payment, and parameter details. The example at the end is helpful without bloating the structure.

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 purpose, purchasing mechanics, collateral, refunds, line-cut behavior, and the output values. Given the output schema exists union with the description's explicit return statement, an agent has everything needed to call this tool correctly.

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 the schema already covers 'line' at 100%, the description adds crucial nuance: omitting it lands the block on the channel, it is not needed when a call carries its own payment, and the example shows the expected credential format. This fully compensates and then some.

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 action: 'Buys one block of time on your line' and precisely defines the effect as 'a payment adds 250ms to a clock.' It also distinguishes the tool from work-bearing siblings by noting it 'never touches the switch' and is 'that purchase with no work attached.'

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 practical guidance on when to use it, such as 'Not needed when a call carries its own payment' and clarifies that omitting the line parameter places the block on the channel. It does not explicitly name sibling tools as alternatives, but the 'no work attached' contrast gives enough routing context.

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

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

Goes far beyond the annotations: describes archive-state limits, eth_getProof head-block window, flashblocks pending behavior, reth versions, history depth, refused method families, eth_getLogs pagination, and the zero-refund cut-off behavior on payment exhaustion. No contradiction with the annotations.

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?

Every sentence carries operational information and the core purpose is front-loaded, but the text is a dense wall of semicolon-separated details. It is appropriately sized for a complex RPC tool, though short bullet sections would improve scannability.

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?

Covers chain differences, method allow/refuse lists, payment mechanics, limits, pagination, and alternative endpoints, and delegates the exhaustive method list to /llms.txt. Combined with the input schema and annotations, an agent has enough context to call the tool correctly.

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?

Though schema coverage is 100%, the description adds crucial meaning: chain selects the node, params must be the exact JSON-RPC params array, and line is the optional payment credential. The concrete example ties chain, method, and params together clearly.

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?

States a specific verb and resource: it forwards JSON-RPC calls to Ethereum and Base archive nodes. It also distinguishes itself from siblings by naming sample_rpc for free availability checks and POST /rpc/{chain} for high-volume use.

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?

Explicitly tells the agent when to prefer alternatives: sample_rpc for checking node availability, POST /rpc/{chain} for volume, and warns that a call is cut when the balance empties. It also points to /llms.txt for the full per-chain method list, leaving no ambiguity about scope.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful context beyond those hints: 'Free, read-only, no arguments' and 'Not counted against the free ceiling,' which explains billing and operational constraints the annotations do not convey.

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?

Three short sentences deliver the purpose, exclusions, and usage context with no filler. The key information is front-loaded and every sentence 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?

The tool is trivial to invoke with no parameters and the output has an existing schema. The description fully covers what the tool returns, how it behaves, and how it differs from sibling tools, leaving nothing an agent needs in order to call it correctly.

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?

There are zero parameters and the schema already documents this with an empty properties object. The description reinforces this with 'no arguments' and shows an example empty object, so no additional parameter meaning is needed.

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 specific verb and resource: 'Returns who runs this, our operating theory, how we work, and how to check each claim.' It also distinguishes itself from related tools by explicitly excluding price or status feeds, so an agent can differentiate it from get_payment_terms and /status.json.

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 explicit when-to-use guidance by stating 'Not a price or status feed' and naming alternatives: 'get_payment_terms has the quote, /status.json the health.' It also notes the operation is free, read-only, and takes no arguments, giving clear context for safe invocation.

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

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

Annotations already declare readOnly/idempotent/destructive hints, and the description adds meaningful context: it is free, not counted against a ceiling, and returns a block when no wallet is present. These go beyond structured data and are consistent.

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 front-loaded with the core purpose, then adds essential details and an example. Every sentence carries information without redundancy, and the structure is easy to parse.

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?

It fully describes the return contents (quote, rows, line socket, optional block) and mentions cost implications. Given the output schema exists and the tool is simple, nothing an agent needs to call it correctly is missing.

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?

With zero parameters, schema coverage is trivially 100%. The description explicitly states 'no arguments' and provides an example '{}', leaving no ambiguity about invocation.

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 specific resource (cost and payment info) and action (returns), and explicitly distinguishes from paying itself ('Not the payment itself'). It also differentiates from siblings like get_operator, making it clear what this tool does.

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 tells when to use this tool (to get cost/payment info) and when not to (for payment, attach x402 to call_rpc or use buy_time). It also points to get_operator for identity, giving clear alternatives.

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

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

Annotations only signal read/write and idempotence hints, but the description adds rich behavioral context: no owner/admin/pause/delete, permanence, authorship recovery on chain, free gas, paid-note marking, and the 4096-byte contract enforcement. This is consistent with the annotations and goes far beyond them.

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 and information-packed, with a strong front-loaded lead sentence and a helpful example at the end. It is somewhat long and repeats the permanence idea more than once, but every sentence carries meaningful, non-redundant detail.

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 state-changing, non-idempotent on-chain write with 7 parameters, the description is complete: it covers behavior, workflow, signature requirements, gas policy, size limits, and includes a full invocation example. The output schema exists and handles return-value documentation, so nothing critical is missing.

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: the example maps body, subject, rating, address, and signature together; it explains the line credential and free-ceiling behavior; and it clarifies that salt/address/signature are required together and that the contract checks the address. This materially helps an agent construct a valid call.

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 uses a specific verb and resource: 'Leave a note about this service' and 'Writes a note on chain, permanently.' It names concrete use cases (review, bug, warning to other agents) and is clearly distinct from sibling tools 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?

The description explicitly provides workflow guidance: 'Read first with notes_read; sign first with notes_sign to be its author.' It also clarifies the consequence of posting unsigned (zero address), which tells agents when signing is needed. It does not explicitly say 'use notes_read instead for reading,' but the sibling references are sufficient.

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

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

Beyond the readOnlyHint and idempotentHint annotations, it discloses rich behavioral details: replayed verbatim notes are deduplicated, every note carries its Base transaction, author is null until claimed, settlement is null or the wallet's record, and subjects tallies note topics. This goes well beyond the structured annotations.

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 efficient: it front-loads the core purpose, then explains output behavior, filtering semantics, the write alternative, and a short example. Every sentence adds meaningful information without filler.

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 read-only notes tool with an output schema and strong annotations, the description covers behavior, filters, defaults, credential handling, and the sibling write tool. Nothing needed to invoke it correctly is missing.

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%, and the schema already documents limit defaults and max, since polling behavior, address wallet form, subject filtering, and the line credential semantics. The description restates most of this, adding little new parameter meaning 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 states a specific verb and resource: it reads notes other agents left about this service, newest first and unfiltered, including negative notes against us. It also differentiates from siblings by explicitly saying it is read-only and pointing to notes_post for writing.

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 usage context: the tool is read-only and free, notes_post is the alternative for writing, and each filter is tied to a use case such as filtering by topic, author, or polling with since. The example also demonstrates a minimal valid call.

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

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

Annotations already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful nuance beyond those flags: the signature is domain-bound and worthless elsewhere, salt enables repeat signing of identical notes, and unsigned notes publish as anonymous. No contradiction with annotations.

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 and front-loaded with the core purpose and required signing workflow before touching parameter details. The three short paragraphs are dense but free of filler, and the example 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?

This is complete for a read-only signing helper: the description supplies the workflow, downstream tool, parameter behavior, domain-binding caveat, anonymous fallback, and an example. With an output schema declared and annotations present, an agent has everything needed to call and use it correctly.

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 covers all five parameters with individual descriptions, so the baseline is 3. The description adds value by explaining that body, subject, and rating are exactly what notes_post will consume, that salt makes repeated signing possible, and by providing a concrete JSON example.

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 'The exact EIP-712 typed data to sign for a note,' which clearly identifies the tool as producing signing data rather than publishing a note. It distinguishes itself from sibling notes_post by explicitly routing the signed result to notes_post.

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 a concrete workflow: sign the returned typed_data with eth_signTypedData_v4тные and pass it with the note to notes_post. It also explains the optional unsigned path for anonymous publishing, giving the agent clear context for when signing is needed; it stops short of explicitly naming exclusions among siblings.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond these: the tool is free, capped per hour, requires no wallet, defaults to base and eth_blockNumber, and explains the semantic limitation that a matching result proves data authenticity but not operator identity. This is substantial behavioral disclosure.

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 yet information-dense. It front-loads the core purpose, then provides usage constraints, an explicit alternative, and a working example. Every sentence contributes either to understanding, safe invocation, or correct tool selection, with no wasted words.

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 purpose, safety profile, defaults, limits, alternative routing, and interpretation caveats. Given the rich input schema and output schema, nothing essential is missing for an agent to invoke this tool correctly and understand what the result means.

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 all three parameters including defaults and allowed values. The description reinforces this by stating chain defaults to base and method to eth_blockNumber, and gives a concrete example, but it doesn't add meaning 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 states a specific purpose: verifying that a node is real by sending a read-only sample call that can be compared against other sources. It clearly distinguishes itself from call_rpc, and the verb 'checks' plus the resource 'the node' make the action concrete and unambiguous.

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 explicit guidance on when to use this tool: for free, capped, read-only sample checks. It also states the exact condition to use the alternative instead — 'For any other method, or with no cap, call_rpc.' This leaves no ambiguity about tool selection.

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