Free, keyless MCP server with 50 read-only blockchain tools for Bitcoin, Ethereum, and Mezo. No installation, no API key required -- just add the URL to your MCP client and start querying balances, transactions, blocks, ENS names, ERC-20 tokens, smart contracts, and more. Runs on Cloudflare's global edge network via Streamable HTTP. All tools are strictly read-only and stateless.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 46 of 46 tools scored.
Every tool is clearly distinguished by a network prefix (btc, btc_testnet, eth, mezo, mezo_testnet) and a unique operation (get_balance, get_block, get_transaction, etc.). There is no overlap between tools; even similar operations like get_balance and get_token_balance are explicitly separated for different asset types.
Tool names follow a consistent pattern of network prefix followed by a verb_noun operation (e.g., btc_get_balance, mezo_get_token_info). Minor deviations like eth_gas_price instead of eth_get_gas_price and eth_estimate_gas do not disrupt the overall predictable structure.
With 46 tools, the server feels heavy and overwhelming. While each tool covers a specific network and operation, the count far exceeds the typical well-scoped range of 3-15 tools, even considering the multi-chain nature of the server.
The server provides a solid read-only surface for Bitcoin and EVM chains (balance, blocks, transactions, logs, token info, fees). However, it lacks any transaction creation or broadcasting capabilities, and there is no eth_call for arbitrary contract calls, leaving notable gaps for common blockchain workflows.
btc_get_balanceAGet confirmed and unconfirmed balance for a Bitcoin address on Bitcoin mainnet. Returns balance in satoshis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds valuable behavioral context by specifying that both confirmed and unconfirmed balances are returned and that the unit is satoshis, which is beyond what annotations provide.
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 a single, dense sentence that immediately conveys the action, resource, network, and return unit. There is no fluff or redundant information; every word 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 simple one-parameter read-only tool with annotations and no output schema, the description is complete. It tells the agent what balance is returned (confirmed/unconfirmed), in what unit (satoshis), and on which network (mainnet). No additional context is necessary for correct invocation.
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 already has a detailed description for the 'address' parameter, listing supported address types (P2PKH, P2SH, P2WPKH, P2WSH, P2TR), giving 100% schema coverage. The description only says 'for a Bitcoin address' and does not add further meaning, so the baseline of 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?
The description clearly states a specific verb ('Get') and resource ('confirmed and unconfirmed balance for a Bitcoin address on Bitcoin mainnet'). It also distinguishes from the testnet sibling by explicitly saying 'mainnet', making the tool's scope 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 provides clear context that this is for Bitcoin mainnet, which implicitly tells the agent to use the testnet sibling for testnet addresses. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_get_blockAGet block header data by height on Bitcoin mainnet. Returns parsed header with hash, version, previous block hash, merkle root, timestamp, bits, and nonce.
| Name | Required | Description | Default |
|---|---|---|---|
| height | Yes | Block height |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is established. The description adds the return field list, but doesn't disclose operational details like error behavior or rate limits.
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?
Single sentence, front-loaded with the core action, and includes concise enumeration of return fields without unnecessary wording.
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 tool's simplicity (one param, no output schema), the description covers purpose, usage context, and return values adequately. It could mention potential errors, but that's not essential.
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 provides full parameter description for 'height' as 'Block height'. The description only adds 'by height' which is minimally informative, so it doesn't substantially enhance 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 uses a specific verb 'Get' and identifies the resource as 'block header data by height on Bitcoin mainnet'. It also enumerates return fields, distinguishing it from sibling tools like btc_testnet_get_block and eth_get_block.
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 clearly specifies 'Bitcoin mainnet' as the context, which implies not to use it for testnet or other chains, but it doesn't explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_get_fee_estimateAGet fee rate estimate on Bitcoin mainnet for a target number of blocks. Returns estimated fee in BTC/kB and sat/byte. Use target=1 for next-block, target=6 for ~1 hour. Returns -1 if no estimate available.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Target number of blocks for confirmation (default: 6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to repeat safety. It adds valuable behavior beyond annotations: 'Returns estimated fee in BTC/kB and sat/byte' and 'Returns -1 if no estimate available.' This gives the agent clear expectations for output and error handling.
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 compact, front-loaded sentences. The first sentence states the purpose, the second gives output units, and the third covers usage examples and error behavior. Every word earns its place with no redundancy or 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 simple tool with one optional parameter and strong annotations, this description is complete. It covers purpose, output format, error condition, and parameter interpretation. There is no output schema, but the description explicitly states what is returned, so the agent has full information to invoke and interpret 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?
The schema covers target's meaning (blocks for confirmation) at 100% coverage, so baseline is 3. The description enhances this with practical guidance: 'Use target=1 for next-block, target=6 for ~1 hour.' This adds real-world conversion beyond the schema's dry definition, justifying a 4.
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 the tool's function: 'Get fee rate estimate on Bitcoin mainnet for a target number of blocks.' It specifies the resource (Bitcoin mainnet), the action (get estimate), and the key input (target blocks). It distinguishes from sibling tools by explicitly noting 'mainnet' and focusing on fee estimation, which is unique among the listed btc_* 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?
Provides concrete usage context: 'Use target=1 for next-block, target=6 for ~1 hour.' This tells the agent when to use specific parameter values. While it doesn't explicitly contrast with alternatives like btc_testnet_get_fee_estimate, the 'mainnet' qualifier implies chain selection, and the tool name itself disambiguates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_get_historyAGet transaction history for a Bitcoin address on Bitcoin mainnet. Returns list of transactions with heights and tx hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a useful return-format detail ('list of transactions with heights and tx hashes') but does not disclose pagination, ordering, or confirmation status. This is acceptable but not rich.
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 a single, front-loaded sentence that clearly states the tool's purpose and return value. Every word earns its place; no waste or redundancy.
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 simple one-parameter, read-only tool with no output schema, the description adequately communicates the return structure (list of transactions with heights and hashes). It does not fully detail fields like amounts or statuses, but given the minimal complexity and good annotations, it is sufficiently 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?
The schema has 100% coverage for the single 'address' parameter, including a description of supported address types. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 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 clearly states the verb ('Get'), the resource ('transaction history for a Bitcoin address'), and the network scope ('Bitcoin mainnet'). It distinguishes itself from sibling tools like btc_testnet_get_history (testnet alternative) and btc_get_transaction (single transaction vs. history).
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?
Clear context is provided: the tool is for Bitcoin mainnet address history, implying it should not be used for testnet (where btc_testnet_get_history exists). However, it does not explicitly exclude any alternatives or specify when to prefer it over other Bitcoin getters beyond the network scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_get_mempool_infoAGet mempool fee histogram on Bitcoin mainnet. Returns array of [fee_rate, cumulative_vsize] pairs showing the distribution of transactions in the mempool by fee rate (sat/vB).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by specifying the exact return shape ([fee_rate, cumulative_vsize] pairs) and unit (sat/vB), which is behavior beyond the annotations. It does not note any limitations or edge cases, but for a simple read-only tool this is adequate.
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 concise sentences with no filler. The purpose is front-loaded, and the return format explanation earns its place. Ideal length for this tool.
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 tool has no parameters and no output schema, the description fully explains what the tool returns and how to interpret it. The mainnet scope is clear, and the return format is sufficiently detailed for an agent to use correctly. No significant gaps.
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 zero parameters, so there is no parameter information to add. The baseline for zero-param tools is 4, and the description appropriately focuses on the return value rather than parameters.
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 ('Get') and resource ('mempool fee histogram') and clearly scopes to 'Bitcoin mainnet', distinguishing it from the testnet sibling btc_testnet_get_mempool_info. It also explains the return format and units, making the purpose 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 clearly indicates this is for the mainnet mempool fee histogram, which sets context. However, it does not explicitly mention when not to use it or mention alternatives like btc_get_fee_estimate, which could be confused for fee-related data. The context is clear but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_get_transactionAGet full transaction details by txid on Bitcoin mainnet. Returns verbose transaction data including inputs, outputs, confirmations, and block hash.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Transaction ID (64 hex characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate readOnlyHint=true, the description adds value by detailing return contents ('inputs, outputs, confirmations, and block hash') and reinforcing the mainnet scope. It does not contradict annotations and provides useful behavioral context beyond the structured metadata.
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 concise sentences front-loaded with the primary action and scope, followed by return details. No redundant information or fluff.
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 simple single-parameter read-only lookup with no output schema, the description sufficiently covers purpose, scope, and return content. It is complete enough for an agent to select and use 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?
Schema coverage for txid is 100% with a full description. The tool description adds no new parameter semantics beyond mentioning 'by txid.' Baseline 3 is appropriate since the schema already fully documents the parameter.
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 the tool's function: 'Get full transaction details by txid on Bitcoin mainnet.' It identifies the specific verb (Get), resource (transaction), input (txid), and network scope (mainnet). This distinguishes it from sibling tools like btc_testnet_get_transaction and other chain-specific lookup 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?
The description implies usage context via 'on Bitcoin mainnet,' suggesting it's for mainnet transactions. However, it does not explicitly state when not to use it or name alternatives (e.g., testnet variant). Guidance is present but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_get_utxosAGet unspent transaction outputs (UTXOs) for a Bitcoin address on Bitcoin mainnet. Returns list of unspent outputs with tx hash, position, height, and value in satoshis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds specific return fields (tx hash, position, height, value in satoshis). This adds useful context beyond the basic read-only declaration, but does not disclose potential edge cases, ordering, or pagination.
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 concise sentences, front-loaded with the verb and resource, with no wasted words. It includes the necessary return format and network context efficiently.
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 simple read-only tool with one parameter, the description covers purpose, network, and return format. Since there is no output schema, explicitly listing the return fields compensates well. It is complete for the 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 schema already documents the single 'address' parameter with a detailed description of supported address types, giving 100% coverage. The description does not add additional parameter semantics 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 clearly states the operation ('Get'), the resource ('unspent transaction outputs for a Bitcoin address'), and the network ('mainnet'). It distinguishes from siblings like btc_testnet_get_utxos and other Bitcoin data 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?
The description specifies that it operates on Bitcoin mainnet, implying that for testnet use the sibling btc_testnet_get_utxos. However, it does not explicitly name alternatives or state when not to use, so it falls short of explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_balanceAGet confirmed and unconfirmed balance for a Bitcoin address on Bitcoin testnet3. Returns balance in satoshis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds useful context: it returns both confirmed and unconfirmed balances, and the unit is satoshis. This goes beyond the structured annotations and clarifies the tool's output.
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 a single, focused sentence. It starts with the action and includes the network, balance type, and return unit with no wasteful 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?
For a simple get-balance tool, the description covers the essential aspects: network, balance types, and return unit. With annotations for read-only and open world, and a well-documented single parameter, no additional context is necessary.
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% for the single 'address' parameter, which already lists accepted types (P2PKH, P2SH, etc.). The description provides no additional parameter semantics, fitting the baseline of 3 for complete schema coverage.
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 the tool's function: get confirmed and unconfirmed balance for a Bitcoin address on Bitcoin testnet3. It uses specific verbs and resource, and the mention of testnet3 distinguishes it from mainnet siblings like btc_get_balance.
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 context by specifying 'Bitcoin testnet3', implying use for testnet addresses. It does not explicitly list exclusions or alternatives, but the network context is sufficient for a simple get-balance tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_blockAGet block header data by height on Bitcoin testnet3. Returns parsed header with hash, version, previous block hash, merkle root, timestamp, bits, and nonce.
| Name | Required | Description | Default |
|---|---|---|---|
| height | Yes | Block height |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds value by detailing the parsed header fields returned (hash, version, previous block hash, merkle root, timestamp, bits, nonce). It does not mention error cases or rate limits, but the read-only nature and return shape are well covered.
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 a single, well-structured sentence that front-loads the purpose and lists the output fields efficiently. Every word serves a purpose, with no redundancy or fluff.
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 a simple one-parameter read tool with no output schema, and the description fully covers what is returned. It lists all key fields and specifies the network, making it adequate for an agent to select and invoke correctly without additional context.
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 only parameter 'height' is fully described in the schema, and the description reinforces that height is the input for fetching block header data. Since schema coverage is 100%, the description adds minimal extra semantic value 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 clearly states the tool gets block header data by height on Bitcoin testnet3, listing specific return fields. It distinguishes itself from siblings like btc_get_block (mainnet) by explicitly naming the testnet network.
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 implies usage for Bitcoin testnet3 by height but does not explicitly state when to use this tool over alternatives like btc_get_block for mainnet. No exclusions or alternative tool names are mentioned, so guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_fee_estimateAGet fee rate estimate on Bitcoin testnet3 for a target number of blocks. Returns estimated fee in BTC/kB and sat/byte. Use target=1 for next-block, target=6 for ~1 hour. Returns -1 if no estimate available.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Target number of blocks for confirmation (default: 6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, so the bar is lower. The description adds valuable behavioral context by stating return units (BTC/kB and sat/byte) and the -1 sentinel when no estimate is available, which goes beyond the structured metadata.
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 concise sentences, each earning its place: function, return format, and edge-case behavior. No wasted words, information is front-loaded, 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?
Given the tool's simplicity (one optional parameter, no output schema), the description is complete: it covers input usage, output units, and error indication. The annotations handle safety context, leaving no critical gaps.
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 for the only parameter 'target' is 100%, but the description enhances it by mapping target values to real-world timeframes (next-block, ~1 hour), making the parameter more actionable than 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 clearly identifies the tool's function with a specific verb and resource: 'Get fee rate estimate on Bitcoin testnet3 for a target number of blocks.' It differentiates from the sibling btc_get_fee_estimate by explicitly naming testnet3, removing ambiguity.
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?
Provides concrete guidance on parameter values ('Use target=1 for next-block, target=6 for ~1 hour'), which helps the agent select appropriate inputs. While it doesn't explicitly contrast with mainnet alternatives, the testnet3 designation in both name and description implies the correct context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_historyAGet transaction history for a Bitcoin address on Bitcoin testnet3. Returns list of transactions with heights and tx hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds behavioral transparency beyond annotations by specifying the return shape ('list of transactions with heights and tx hashes'), which is valuable since there is no output schema. It does not mention any potential limitations (e.g., only confirmed transactions), but it adds meaningful context.
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 sentences long, with the first sentence stating the primary purpose and network, and the second sentence detailing the return value. Every word earns its place; there is no redundant or extraneous 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?
For a simple, single-parameter read-only tool with full schema coverage and readOnly/openWorld annotations, the description covers the essential pieces: what it does, the network, and what it returns. Given no output schema, the description fulfills the need to explain the return shape. It could add minor details (e.g., whether results are confirmed only), but it is still highly useful.
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% for the single parameter 'address', which is already well-documented with a description of accepted Bitcoin address types and length constraints. The tool description does not add additional parameter semantics beyond what the schema provides, so the baseline of 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?
The description clearly states the action ('Get transaction history'), the target resource ('Bitcoin address'), and the network ('Bitcoin testnet3'), which distinguishes it from the sibling tool btc_get_history (implied mainnet). This is a specific verb+resource+scope combination that leaves no ambiguity.
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 names the testnet3 environment, making the intended use case (testnet transactions) obvious. While it does not explicitly recommend against using mainnet tools or name btc_get_history as an alternative, the network qualification provides clear contextual guidance for tool selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_mempool_infoAGet mempool fee histogram on Bitcoin testnet3. Returns array of [fee_rate, cumulative_vsize] pairs showing the distribution of transactions in the mempool by fee rate (sat/vB).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return structure (array of [fee_rate, cumulative_vsize] pairs) which is valuable but not extensive. It does not contradict 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?
Two concise sentences with no filler. The first sentence states the action and network, the second details the return format. Every word 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 simple read-only tool with no parameters and no output schema, the description sufficiently explains the purpose and return values. It does not need to discuss prerequisites or side effects.
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, so the schema covers 100% of parameters. The baseline for 0 params is 4, and the description adds no parameter-specific meaning because there are none.
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 'Get mempool fee histogram on Bitcoin testnet3', providing a specific verb and resource, and distinguishes from the mainnet sibling by specifying testnet3. The return format is also described, making the purpose 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 clear context by naming Bitcoin testnet3, which implies its use for testnet mempool queries, but it does not explicitly mention alternatives like btc_get_mempool_info or btc_testnet_get_fee_estimate. Since context is clear without exclusions, this is a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_transactionAGet full transaction details by txid on Bitcoin testnet3. Returns verbose transaction data including inputs, outputs, confirmations, and block hash.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Transaction ID (64 hex characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and openness. The description adds return content details (inputs, outputs, confirmations, block hash) but no additional behavioral caveats such as handling of unconfirmed transactions or error conditions. This adds some value but does not go beyond what is expected.
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?
Single sentence, front-loaded with the verb and object, no filler or redundant details. Every word 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 simple 1-parameter read-only tool with annotations and no output schema, the description is adequate. It states the network, what it returns, and includes enough detail for an agent to understand its function. No critical gaps for this complexity level.
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%: the txid parameter is fully described with pattern and description. The description only says 'by txid', which adds no new meaning beyond the schema. Baseline 3 is appropriate since 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?
Description clearly states 'Get full transaction details by txid on Bitcoin testnet3' with a specific verb, resource (transaction), and network (testnet3). This distinguishes it from the mainnet btc_get_transaction and other testnet tools like btc_testnet_get_balance.
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 context is clear: use for fetching transactions on Bitcoin testnet3. However, it does not explicitly name the alternative btc_get_transaction for mainnet or state when not to use this tool. No exclusions, but implied by the name and network reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_testnet_get_utxosAGet unspent transaction outputs (UTXOs) for a Bitcoin address on Bitcoin testnet3. Returns list of unspent outputs with tx hash, position, height, and value in satoshis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds behavioral context by specifying the return payload ('Returns list of unspent outputs with tx hash, position, height, and value in satoshis'). It does not mention rate limits or errors, but given the simple read-only nature, this is sufficient. 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 two sentences, front-loaded with the core purpose and followed by the return format. Every word earns its place, with no redundant information. It is concise and well-structured.
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 simple read-only tool with one parameter and no output schema, the description covers the essential purpose, network, and return fields. It does not specify whether unconfirmed UTXOs are included, which could be a meaningful gap, but overall it is sufficiently complete for a straightforward query tool.
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% (the 'address' parameter is fully described with its allowed formats). The description does not add significant parameter-level detail beyond what the schema already states. The network context (testnet3) is useful but is more about tool purpose than the parameter's semantics.
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 the tool's function: 'Get unspent transaction outputs (UTXOs) for a Bitcoin address on Bitcoin testnet3.' It uses a specific verb ('Get'), identifies the resource (UTXOs), and distinguishes from the mainnet sibling by specifying 'testnet3'. It also mentions the return fields, adding precision.
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 clearly scopes the tool to Bitcoin testnet3, making it evident when this tool is appropriate (for testnet addresses). However, it does not explicitly name alternatives like 'btc_get_utxos' for mainnet usage, so it lacks explicit exclusions or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_estimate_gasAEstimate gas required for a transaction on Ethereum mainnet. Returns gas estimate as hex string.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination address | |
| data | No | ABI-encoded call data | |
| from | No | Sender address | |
| value | No | Value to send in wei (hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the return format and mainnet scope, but does not disclose potential failure conditions (e.g., transaction reverting) or additional behavioral nuances.
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 a single sentence, front-loaded with the core action and return type, with zero wasted words. It is appropriately sized for the tool's simplicity.
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 tool's moderate complexity and lack of an output schema, the description adequately covers the purpose and return format. It could mention use cases relative to other gas-related tools, but the annotations and schema compensate for missing details.
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 provides 100% parameter description coverage, so the baseline is 3. The description does not add any extra semantics beyond what the schema already documents for the four parameters.
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 the specific verb 'Estimate gas' and the resource 'transaction on Ethereum mainnet', which clearly distinguishes it from sibling tools like eth_gas_price. It also mentions the return format as a hex string, adding clarity.
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 implies when to use this tool: whenever gas for a transaction needs to be estimated. It does not explicitly list alternatives or exclusions, but the context is clear enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_gas_priceAGet current gas price on Ethereum mainnet in wei (hex string). Use to estimate transaction costs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value beyond annotations by disclosing the output format (wei hex string) and network scope. It does not describe rate limits or error behavior, but for a simple read-only getter this is sufficient.
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 sentences, with the first sentence stating the core action and the second providing a use case. Every word earns its place, no fluff or redundancy.
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 simple tool with zero parameters, good annotations, and no output schema, the description is complete: it states what is returned (gas price in wei as hex string), the network, and a typical use case. There is no missing information that would prevent correct invocation.
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 no parameters, and the schema is empty with 100% coverage trivially. The description adds no parameter-specific info because none exist, and the baseline for zero-parameter tools is 4. The output format described compensates for the lack of an output 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 uses a specific verb ('Get') and resource ('current gas price on Ethereum mainnet') with output format ('wei (hex string)'), clearly distinguishing it from siblings like mezo_gas_price (different network) and eth_estimate_gas (estimates gas for a transaction, not the current price). It precisely states what the 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?
The description provides a clear use case ('Use to estimate transaction costs') and specifies the network (Ethereum mainnet), which helps select it over alternatives like mezo_gas_price. However, it does not explicitly mention when not to use it (e.g., for other networks) or contrast with eth_estimate_gas, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_abiAFetch a verified contract's ABI from Sourcify by address. Returns the full ABI array and match type ('full' or 'partial'). Returns match_type 'none' for unverified contracts. Defaults to Ethereum mainnet (chain_id 1).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Contract address | |
| chain_id | No | EVM chain ID (default: 1 for Ethereum mainnet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds value by explaining the return behavior for verified vs unverified contracts (match_type 'full'/'partial'/'none') and the default chain behavior, which goes beyond 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 three concise sentences, front-loaded with the core purpose. Every sentence provides useful information: what it fetches, what it returns, and default behavior. No filler or redundancy.
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?
Despite no output schema, the description explains the return value (ABI array and match type) and handles the edge case of unverified contracts. It also notes the default chain_id, making the tool self-contained for a simple read operation.
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 both parameters. The description reiterates the chain_id default (already in the schema) but doesn't add deeper semantics like address format requirements or how the parameters interact. 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?
The description clearly states the action ('Fetch a verified contract's ABI'), the resource ('from Sourcify by address'), and the return value (ABI array and match type). It also distinguishes this tool from siblings by specifying the source and purpose, which is unique among the listed 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?
The description provides clear context for when to use the tool (fetching ABIs for verified contracts) and mentions the default chain_id, implying usage on Ethereum mainnet unless specified. It doesn't explicitly name alternatives or exclusions, but the sibling list shows this is the only ABI-fetching tool, so the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_balanceAGet native token balance for an address on Ethereum mainnet. Returns balance in wei (hex and decimal) and in ether.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing the return format: 'Returns balance in wei (hex and decimal) and in ether.' This is a behavioral detail not present in the readOnlyHint or openWorldHint annotations. It also clarifies that the balance is for the native token, avoiding ambiguity. No contradictions 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 a single, well-structured sentence that leads with the action and resource, then specifies the return format. Every word earns its place—no wasted information or redundancy.
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 simple read-only balance query with a single parameter, no output schema, and annotations indicating read-only and open-world behavior, the description is fully adequate. It states the network, asset type, input nature, and output units, making the tool's behavior complete for an agent to select and invoke it.
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 schema description coverage, the description compensates by identifying the address as being 'on Ethereum mainnet' for native token balance. It adds network context beyond the schema's generic '^0x.*' pattern. The single parameter is straightforward, and the description sufficiently implies its purpose, though it doesn't elaborate on address formatting 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 clearly states the action: 'Get native token balance for an address on Ethereum mainnet.' It specifies the resource (native token), the network (Ethereum mainnet), and the target (address). This distinguishes it from sibling tools like btc_get_balance and mezo_get_balance, and from eth_get_token_balance by explicitly saying 'native token.'
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 implies usage context: use this for native ETH balance on Ethereum mainnet. It differentiates from token balances via 'native token' and from other networks via 'Ethereum mainnet.' However, it does not explicitly mention alternatives or when not to use it, such as for testnets or ERC-20 tokens, so it falls short of full guideline coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_blockAGet block data by number or tag on Ethereum mainnet. Use hex block number (e.g. "0x1") or "latest". Returns full block object with transaction hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds return shape ('full block object with transaction hashes') and parameter usage, which is useful context beyond annotations. No contradictions.
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, each with a distinct purpose: what it does, how to specify the block, and what it returns. No redundant 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?
For a single-parameter read-only tool with good schema coverage, the description covers purpose, usage, and return format adequately. It lacks only error behavior, which is typically not critical for this type of RPC.
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 schema covers the parameter fully, and the description adds an example ('0x1') but omits 'earliest' and 'pending' tags, which are in the schema. Since schema coverage is 100%, the description adds marginal value.
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 the tool retrieves block data on Ethereum mainnet by number or tag, and notes the return format, distinguishing it from other chain-specific or testnet block 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 provides clear context (use hex block number or 'latest') and implies the mainnet scope, but does not explicitly contrast with sibling tools like eth_get_transaction or other chain block getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_codeAGet bytecode at an address on Ethereum mainnet. Returns "0x" for EOAs (wallets), non-empty hex for contracts. Use to determine if an address is a contract or EOA, and to retrieve deployed bytecode.
| Name | Required | Description | Default |
|---|---|---|---|
| block | No | Block to query (default: "latest") | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important return behavior: 'Returns "0x" for EOAs (wallets), non-empty hex for contracts.' This adds valuable context about what the tool returns and how to interpret it, which is not present in the schema or 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 two sentences with no unnecessary words. It front-loads the main purpose ('Get bytecode at an address on Ethereum mainnet') and immediately provides return semantics and use case, earning its space.
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 simple read-only tool with annotations indicating safety and an open world, the description is complete. It explains the return values, the network scope, and when to use it, making it sufficient for an agent to invoke correctly without needing an output 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?
The schema already documents the 'block' parameter with a default value, and the 'address' parameter has a pattern. The description mentions 'at an address' but does not elaborate on the address format or the meaning of the block parameter. With 50% schema coverage, the description adds only minimal semantic value 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 clearly states the tool gets bytecode at an address on Ethereum mainnet, with a specific verb and resource. It distinguishes from siblings by specifying 'Ethereum mainnet' and by explaining the return format for EOAs vs contracts, which differentiates it from other eth_* tools like eth_get_balance.
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?
Describes an explicit use case: 'Use to determine if an address is a contract or EOA, and to retrieve deployed bytecode.' This provides clear context for when to use the tool, though it does not explicitly mention alternatives or exclusions. The use case is specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_logsAGet event logs matching a filter on Ethereum mainnet. Requires at least fromBlock and toBlock. Optionally filter by contract address and topics.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | Array of topic filters. Each element is a topic hash, null for wildcard, or an array of topic hashes for OR matching. | |
| address | No | Contract address to filter logs | |
| toBlock | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") | |
| fromBlock | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the requirement of fromBlock/toBlock and optional filters, which is useful, but it does not disclose return format or potential response size. OpenWorldHint is present but not elaborated.
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 sentences, front-loaded with the main purpose, no filler words. Every sentence contributes meaningful 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?
For a read-only log query with comprehensive schema descriptions and safety annotations, the description covers the essential usage. The absence of output schema documentation is a minor gap given the tool's conventional Ethereum behavior and sibling context.
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% with all parameters documented. The description merely restates required vs optional parameters without adding deeper meaning beyond the schema, so 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?
The description uses the specific verb 'get' with the resource 'event logs' and explicitly states 'Ethereum mainnet', clearly distinguishing it from sibling tools like mezo_get_logs. It also mentions filtering capabilities.
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 states the required parameters ('Requires at least fromBlock and toBlock') and optional filters (address/topics), giving some usage context. However, it does not explicitly contrast with alternatives or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_token_balanceAGet ERC-20 token balance for a wallet address on Ethereum mainnet. Returns raw balance, formatted balance with decimals, and token symbol. Calls balanceOf, decimals, and symbol on the token contract.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address | |
| wallet | Yes | Wallet address to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral detail: it discloses the exact contract calls (balanceOf, decimals, symbol) and the return format (raw, formatted, symbol). This context helps the agent anticipate that the token must implement these methods and that duplicate calls may occur, going beyond the annotation's basic safety declaration.
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 three concise sentences, front-loaded with the core purpose, followed by return values and underlying contract calls. Every sentence adds value with no redundancy or fluff, making it easy to parse quickly.
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 simple read-only tool with no output schema, the description is complete: it covers the network (Ethereum mainnet), asset type (ERC-20), the two parameters, the return values, and the underlying contract interactions. No critical context is missing for correct use.
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% with both parameters well-defined ('ERC-20 token contract address' and 'Wallet address to check balance for'). The description reinforces this but does not add significant new meaning beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
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 the tool's purpose: 'Get ERC-20 token balance for a wallet address on Ethereum mainnet.' This specific verb+resource+scope immediately distinguishes it from similar tools like eth_get_balance (native ETH) and mezo_get_token_balance (different chain). It also lists what it returns, reinforcing the purpose.
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 context by specifying Ethereum mainnet and ERC-20 tokens, which implies it is not for native ETH or testnets. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection. A 4 is appropriate for clear context without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_token_infoAGet ERC-20 token metadata for a token address on Ethereum mainnet. Returns name, symbol, decimals, and total supply (raw and formatted). Degrades gracefully — any individual call failure returns null for that field.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses graceful degradation behavior: any individual field call failure returns null for that field. It also clarifies the output includes raw and formatted total supply, adding meaningful behavioral context.
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 sentences, front-loaded with the core purpose, and every word earns its place. It clearly states what the tool does, what it returns, and its failure behavior without unnecessary elaboration.
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?
With no output schema, the description fully explains the return values (name, symbol, decimals, total supply) and the failure mode. For a simple one-parameter tool with a clear purpose and network scope, this is complete and self-sufficient.
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% with the token parameter described as 'ERC-20 token contract address' and a 0x pattern. The description adds minimal extra parameter meaning, mainly reinforcing the Ethereum mainnet context. Since the schema already documents the parameter well, the baseline of 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?
The description clearly states the tool gets ERC-20 token metadata for a token address, specifying the exact resource (token metadata) and network (Ethereum mainnet). It distinguishes from siblings like eth_get_token_balance and mezo_get_token_info by explicitly scoping to metadata and Ethereum mainnet.
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 context: it is for Ethereum mainnet and returns token metadata. It does not explicitly name alternatives or exclusion criteria, but the network and purpose are stated, making it clear when this tool is appropriate relative to testnet or other-network siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_transactionAGet transaction details by hash on Ethereum mainnet. Returns full transaction object including from, to, value, input data, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (32 bytes, hex-encoded with 0x prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld hints, so the description carries a lower burden. It adds return-content details (from, to, value, input data, status), but the inclusion of 'status' is inaccurate for a standard Ethereum transaction object, which undermines trust in the 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 two sentences, front-loaded with the action and network, and contains no filler. Every word contributes to explaining the tool's purpose.
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 one-parameter read-only tool with a full schema and annotation safety profile, the description provides a reasonable overview. It lacks explicit error behavior (e.g., null if not found) and contains a possible inaccuracy ('status'), so it is not fully 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?
The schema fully covers the single 'hash' parameter with pattern and description, so the description adds no additional parameter semantics beyond what is already structured. Per the baseline for high schema coverage, a score of 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?
The description clearly states a specific verb ('Get'), resource ('transaction details'), and scope ('Ethereum mainnet'), distinguishing it from sibling tools like btc_get_transaction and eth_get_transaction_receipt. The phrase 'by hash' precisely identifies the lookup method.
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 implies use for fetching transaction data on Ethereum mainnet but does not explicitly mention alternatives or exclusions, such as when to use eth_get_transaction_receipt instead. The network scope is stated, but no 'when not to use' guidance is provided despite many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_transaction_receiptAGet transaction receipt by hash on Ethereum mainnet. Returns status (0x1=success, 0x0=fail), gasUsed, contractAddress (for contract deployments), and event logs.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (32 bytes, hex-encoded with 0x prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description's additional context about returned fields (status encoding, contractAddress only for deployments) is useful but doesn't disclose potential edge cases like null receipts for pending transactions. The description adds moderate value beyond 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?
Two concise sentences that front-load the action and resource, followed by a compact list of key return fields. Every word earns its place with no redundancy or 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 simple one-parameter read-only tool, the description plus schema covers the essential purpose, return values, and parameter format. It doesn't mention caveats like pending transactions or null results, but these are minor omissions given the tool's simplicity and the annotations' safety profile.
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 schema fully describes the hash parameter with pattern and description, providing complete coverage. The tool description says 'by hash' but doesn't add new semantic details beyond the schema, so the baseline score of 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?
The description clearly states the tool gets a transaction receipt by hash on Ethereum mainnet, listing specific receipt fields like status, gasUsed, contractAddress, and event logs. This distinguishes it from sibling tools such as eth_get_transaction, which returns transaction details rather than receipt-specific information.
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 implies usage when receipt data is needed (e.g., transaction status, gas used, logs). However, it doesn't explicitly state when not to use it or mention alternatives like eth_get_transaction or eth_get_logs, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_lookup_addressAReverse-resolve an Ethereum address to its primary ENS name. Returns null if no primary ENS name is set for the address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address to reverse-resolve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and open-world, and the description adds valuable behavioral details: it returns null if no primary ENS name is set, and it specifically returns the 'primary' name, implying multiple names may exist but only the primary is returned. This goes beyond the annotation hints.
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 clear sentences with no unnecessary words. It front-loads the main action and result, making it easy for an agent to quickly understand the tool's purpose and return behavior.
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 simple tool with one parameter and no output schema, the description adequately explains the input and the return value (primary ENS name or null). It does not mention error cases, but given the simplicity and schema validation, this is acceptable. It's slightly less complete because it doesn't note what happens for an invalid address.
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 full coverage (100%) with a description for the 'address' parameter and a pattern. The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 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?
The description uses a specific verb ('Reverse-resolve') and clearly states the resource ('Ethereum address') and the target ('primary ENS name'). It distinguishes from the sibling tool eth_resolve_ens, which likely does forward resolution, by explicitly saying 'reverse-resolve'.
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 implies usage by indicating it performs reverse resolution, but it does not explicitly state when to use it versus alternatives like eth_resolve_ens, nor does it mention any exclusions or prerequisites. The distinction is implied but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_lookup_selectorALook up a 4-byte function or error selector against 4byte.directory. Returns matching function/error signatures. Useful for identifying unknown calldata selectors or decoding custom errors.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | 4-byte selector (0x-prefixed, e.g. 0x70a08231) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds concrete context by naming the external source (4byte.directory) and indicating the return content ('matching function/error signatures'). This goes beyond the annotations without contradicting 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 two sentences, front-loaded with the action, and every sentence contributes value. No fluff or redundancy.
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 read-only lookup with no output schema, the description covers the purpose, the external source, and the return type. It does not detail the exact output shape or no-match behavior, but the tool 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?
Schema description coverage is 100%, so the parameter is fully documented in the schema. The description only reiterates the concept of a 4-byte selector without adding new meaning, so the baseline score of 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?
The description clearly states the action ('Look up'), the resource ('4-byte function or error selector'), and the target ('against 4byte.directory'). It also distinguishes itself from sibling tools like eth_lookup_address (addresses) and eth_get_abi (ABI) by focusing specifically on selector signature lookup.
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: 'Useful for identifying unknown calldata selectors or decoding custom errors.' It does not explicitly name alternatives or exclusions, but the use case is unmistakable, and sibling tools are different in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_resolve_ensAResolve an ENS name to its Ethereum address. Returns null if the name is not registered or has no address record. Example: 'vitalik.eth' → '0xd8dA6BF26964aF9D68eC99A6d99030B4ec93B700'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ENS name to resolve (e.g. 'vitalik.eth') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only (readOnlyHint=true) and open-world (openWorldHint=true). The description adds valuable behavioral context by stating that null is returned for unregistered names or missing address records, and provides a concrete example. This goes beyond what annotations provide.
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 sentences: the first explains the action and return behavior, the second gives a concrete example. It is front-loaded, concise, and every sentence earns its place with no redundancy.
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 simple one-parameter tool with no output schema, this description is nearly complete. It covers the core action, the null return condition, and an example output. Minor gaps include no mention of ENS subdomain support or address checksumming, but these are not critical for typical use.
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%: the only parameter 'name' already has a clear description and example. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 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 clearly states the tool resolves an ENS name to an Ethereum address, using a specific verb and resource. It does not explicitly distinguish from the sibling tool eth_lookup_address (likely reverse lookup), so it misses the top score for sibling differentiation.
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 usage context is implied: use this when you have an ENS name and need its address. However, there is no explicit guidance on when not to use it or mention of alternative tools like eth_lookup_address for reverse resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_gas_priceAGet current gas price on Mezo in wei (hex string). Use to estimate transaction costs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context about the output format (wei hex string) and the purpose (estimating transaction costs), which goes beyond the annotations without contradicting 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?
Two concise sentences with no filler. The action and purpose are front-loaded, making it immediately clear what the tool does. Every word 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 simple, parameterless, read-only tool, the description is complete. It states what is returned (gas price in wei hex string) and why to use it. No output schema exists, so the description adequately covers return details.
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, and the schema coverage is 100%. The description correctly avoids mentioning parameters. Per rubric, 0 parameters earns a baseline of 4, and the description adds return format context which is useful.
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 the action ('Get'), the resource ('current gas price on Mezo'), and the format ('in wei (hex string)'). It distinguishes from siblings by specifying 'Mezo' versus testnet or other networks.
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 a clear use case ('Use to estimate transaction costs') which implies when to use the tool. However, it does not explicitly mention alternatives like mezo_testnet_gas_price or eth_gas_price, leaving the differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_balanceAGet native token balance for an address on Mezo. Returns balance in wei (hex and decimal) and in ether.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint annotations already declaring the read-only and open-world nature, the description adds value by disclosing the return units (wei hex/decimal and ether). It does not mention edge cases or errors, but the annotations cover the safety profile and the added return format context is 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?
The description is a single, front-loaded sentence that clearly states the action, target, and return format. Every word contributes meaning, with no filler or redundancy.
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 simple read-only tool with one parameter and no output schema, the description covers the essential purpose and return format. It does not discuss error handling or invalid addresses, but given the low complexity and the presence of annotations, this is sufficient and well-rounded.
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 a single 'address' parameter with only a regex pattern and no description, and schema description coverage is 0%. The description only says 'for an address' without adding any semantic detail (e.g., format expectations, network specifics, or examples), so it fails to compensate for the schema's lack of detail.
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 the tool gets the native token balance for an address on Mezo, with a specific verb and resource. It also specifies the return format in wei (hex and decimal) and ether, distinguishing it from sibling tools like mezo_get_token_balance and btc_get_balance.
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 context: it is for native token balances on Mezo, implying usage for MEZO native assets rather than token contracts or other chains. However, it does not explicitly name alternatives or exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_blockAGet block data by number or tag on Mezo. Use hex block number (e.g. "0x1") or "latest". Returns full block object with transaction hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds beyond this by specifying the return format ('full block object with transaction hashes'), which describes the output behavior without contradicting 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 two sentences with no redundant words. It front-loads the purpose and then provides a concise usage example, effectively earning its place without extra fluff.
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 simple read-only tool with a single parameter and no output schema, the description covers the key aspects: purpose, parameter format, and return type. It is complete enough for an agent to invoke correctly, though it does not cover potential edge cases (e.g., invalid block number) which are not essential here.
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 already provides 100% coverage for the 'block' parameter, detailing hex format and valid tags. The description repeats part of this ('Use hex block number or latest') without adding new semantic information beyond what the schema states, so it meets the baseline for high schema coverage.
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 the action ('Get block data'), the resource ('block data'), and the scope ('on Mezo'). It also specifies the input format (hex block number or 'latest') and the return type ('full block object with transaction hashes'), which distinguishes it from chain-specific siblings like eth_get_block or btc_get_block.
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 phrase 'on Mezo' clearly situates the tool within the Mezo chain, providing context for when to use it over other chain-specific tools. However, it does not explicitly mention alternatives or exclusions (e.g., 'for Ethereum use eth_get_block'), so it lacks an explicit when-not statement but still offers clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_codeAGet bytecode at an address on Mezo. Returns "0x" for EOAs (wallets), non-empty hex for contracts. Use to determine if an address is a contract or EOA, and to retrieve deployed bytecode.
| Name | Required | Description | Default |
|---|---|---|---|
| block | No | Block to query (default: "latest") | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals concrete return behavior: 'Returns "0x" for EOAs (wallets), non-empty hex for contracts.' This is crucial for interpreting results and is not present in the schema or 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 two sentences, front-loaded with the core purpose, followed by return semantics and usage. Every sentence earns its place with no redundant wording.
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 primary purpose, return interpretation, and a key use case, which is sufficient for a simple read-only tool with no output schema. It omits the block parameter context and doesn't distinguish from testnet variants, but those are minor gaps given sibling names.
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 50% (only block has a description; address only has a pattern). The description adds no details about the block parameter or address format, relying entirely on the schema's pattern for address and description for 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 clearly states the action (Get), the resource (bytecode at an address), and the network (Mezo), and explains the return semantics ('0x' for EOAs, non-empty hex for contracts). This distinguishes it from siblings like eth_get_code (Ethereum) and testnet variants.
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 provides a use case: 'Use to determine if an address is a contract or EOA, and to retrieve deployed bytecode.' However, it does not explicitly mention alternative tools for other networks (e.g., eth_get_code or mezo_testnet_get_code), relying on the network name in the tool name to imply scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_logsAGet event logs matching a filter on Mezo. Requires at least fromBlock and toBlock. Optionally filter by contract address and topics.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | Array of topic filters. Each element is a topic hash, null for wildcard, or an array of topic hashes for OR matching. | |
| address | No | Contract address to filter logs | |
| toBlock | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") | |
| fromBlock | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the requirement of at least fromBlock and toBlock, but this is also evident from the schema. It does not disclose additional behavioral traits such as return format, pagination, or limits, though these are less critical given the read-only annotation. No contradiction exists.
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 extremely concise, consisting of two sentences that front-load the core purpose and then state requirements. Every word earns its place, with no redundancy or 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 tool's moderate complexity (4 parameters, no output schema), the description covers the essential purpose and parameter requirements, but it does not explain what the tool returns (e.g., an array of log objects) or any edge cases. Since there is no output schema, the description could have provided more context about the return value, making this adequate but not 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 description coverage is 100%, so the schema fully documents all four parameters. The description merely reiterates the requirement of fromBlock/toBlock and the optionality of address/topics, adding no extra meaning beyond the schema. Therefore the baseline score of 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?
The description clearly states the tool's purpose: 'Get event logs matching a filter on Mezo.' It identifies the specific resource (Mezo event logs) and the action (get), distinguishing it from sibling tools like eth_get_logs or mezo_get_block. The mention of optional filters adds further clarity.
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 implies usage by stating the required parameters (fromBlock and toBlock) and optional filters, but it does not provide explicit guidance on when to choose this tool over alternatives like eth_get_logs or the testnet variant. No alternative tools are mentioned, so usage context is only partially conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_token_balanceAGet ERC-20 token balance for a wallet address on Mezo. Returns raw balance, formatted balance with decimals, and token symbol. Calls balanceOf, decimals, and symbol on the token contract.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address | |
| wallet | Yes | Wallet address to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation, and the description adds valuable detail: it calls balanceOf, decimals, and symbol on the token contract, and returns raw plus formatted balance and symbol. This context is not present in the annotations and informs the agent about the underlying contract interactions.
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 sentences, front-loaded with the primary purpose, then efficiently summarizes return values and contract calls. Every word earns its place; no fluff or repetition of schema fields.
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?
Although there is no output schema, the description fully specifies the return values (raw balance, formatted balance, token symbol). Given the tool's simplicity, two well-defined parameters, and strong annotations, this description is complete for an agent to successfully invoke the tool.
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 100% of parameters with clear descriptions for 'token' and 'wallet'. The description does not add additional parameter semantics beyond what the schema already provides, so a baseline score of 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?
The description states a specific verb 'Get', a clear resource 'ERC-20 token balance', and the network 'Mezo'. It distinguishes itself from siblings like eth_get_token_balance (by explicitly mentioning Mezo) and mezo_get_balance (which likely handles native balance).
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 clearly indicates the tool is for ERC-20 token balances on Mezo, providing context for when to use it. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to choose this over similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_token_infoAGet ERC-20 token metadata for a token address on Mezo. Returns name, symbol, decimals, and total supply (raw and formatted). Degrades gracefully — any individual call failure returns null for that field.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses a key behavioral trait: 'Degrades gracefully — any individual call failure returns null for that field.' This is important context for handling partial data and is not captured by 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 two sentences, front-loaded with the primary purpose, followed by return details and failure behavior. Every sentence contributes value with no redundancy.
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 simplicity of the tool (one parameter, no output schema), the description sufficiently covers the return fields and failure behavior. It lists the specific metadata returned and how partial failures are handled, which is adequate for this low-complexity tool.
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 already provides a 100% description for the single 'token' parameter ('ERC-20 token contract address'), and the pattern enforces the 0x prefix. The description adds no new semantic meaning beyond the schema, so a baseline of 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?
The description clearly states the verb (Get), resource (ERC-20 token metadata), and scope (a token address on Mezo). It also enumerates the returned fields (name, symbol, decimals, total supply), which distinguishes it from siblings like eth_get_token_info (Ethereum) and mezo_testnet_get_token_info (testnet).
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 context: use this when you need token metadata for an ERC-20 on Mezo mainnet. However, it does not explicitly mention alternatives or exclusions, such as using mezo_get_token_balance for balances or mezo_testnet_get_token_info for testnet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_transactionAGet transaction details by hash on Mezo. Returns full transaction object including from, to, value, input data, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (32 bytes, hex-encoded with 0x prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds value by specifying the output shape (full transaction object including from, to, value, input data, and status), but it does not disclose error behavior, rate limits, or confirmation requirements beyond these fields. This is consistent with annotations and provides moderate extra context.
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 a single sentence that front-loads the core function and then lists key return fields. Every word is informative and there is no fluff or redundancy. It is concise and well-structured.
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 simple with one parameter and minimal annotations, and the description outlines what to expect in the response. It does not explain potential error conditions or whether the hash must be for a Mezo transaction specifically, but for a straightforward read-only lookup the given context is largely sufficient. The absence of an output schema makes the listed return fields valuable.
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 documents the single parameter 'hash' with a description and pattern, providing 100% coverage. The description does not add additional parameter semantics beyond what the schema offers, so a baseline score of 3 is appropriate given the high schema coverage.
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 the tool's function: 'Get transaction details by hash on Mezo.' It specifies the resource (transactions) and action (get), and distinguishes itself from sibling tools by naming the Mezo chain and listing the returned fields (from, to, value, input data, status). This differentiates it from similar tools like btc_get_transaction and mezo_get_transaction_receipt.
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 implies when to use the tool (when you need transaction details by hash), but it does not explicitly state alternatives or exclusions. For example, it does not mention that transaction receipts are handled by a separate tool, nor does it clarify if this is only for Mezo mainnet vs. testnet. The usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_get_transaction_receiptAGet transaction receipt by hash on Mezo. Returns status (0x1=success, 0x0=fail), gasUsed, contractAddress (for contract deployments), and event logs.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (32 bytes, hex-encoded with 0x prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful behavioral context by listing return fields and explaining status code semantics (0x1=success, 0x0=fail), which helps the agent interpret results beyond what annotations provide.
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 sentences, front-loaded with the primary purpose, followed by a compact list of return fields. No fluff or repetition, making it highly efficient.
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 read-only lookup, the description covers the essential return fields (status, gasUsed, contractAddress, logs) despite lacking an output schema. It is adequate for common use, though it does not detail nested log structures or error behavior.
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% coverage with a clear description for the hash parameter (type, pattern, and meaning). The tool description adds no additional parameter semantics beyond referencing 'by hash', so it does not exceed the baseline of 3.
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?
Description clearly states 'Get transaction receipt by hash on Mezo' – a specific verb (get), resource (transaction receipt), and scope (by hash on Mezo). It distinguishes from siblings like mezo_get_transaction (transaction vs receipt) and eth_get_transaction_receipt (different chain).
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 context that this is for Mezo chain and receipt lookup only, which implicitly differentiates it from alternatives like mezo_get_transaction or eth_get_transaction_receipt. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_gas_priceAGet current gas price on Mezo testnet in wei (hex string). Use to estimate transaction costs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral context by stating the output is 'in wei (hex string)' and that it is the 'current' gas price, which goes beyond 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 only two sentences, with the primary purpose and output format in the first sentence and a use case in the second. It is front-loaded and contains no unnecessary 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?
For a simple read-only, zero-parameter tool, the description covers the return format (wei hex string), the target network (Mezo testnet), and the intended use (estimating transaction costs). No output schema exists, but the description is sufficiently 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?
There are zero parameters, so schema coverage is trivially 100%. The description implies no inputs are needed, which is correct. No parameter explanations are necessary, so the baseline of 4 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 clearly identifies the tool as 'Get current gas price on Mezo testnet' with a specific verb and resource, and it specifies the output format as 'wei (hex string)'. This distinguishes it from sibling tools like mezo_gas_price (mainnet) and eth_gas_price.
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 a clear usage context: 'Use to estimate transaction costs.' However, it does not explicitly mention alternatives or exclusions (e.g., using mezo_gas_price for mainnet), so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_balanceAGet native token balance for an address on Mezo testnet. Returns balance in wei (hex and decimal) and in ether.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by specifying the return format (wei hex/decimal and ether) and clarifying native token, which is beyond what annotations provide. No contradiction.
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?
A single, front-loaded sentence conveying all essential information with no filler or unnecessary 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 simple one-parameter read-only tool with no output schema, the description covers purpose, network, and return format. Annotations handle safety. The only minor gap is no explicit pointer to mainnet or token balance alternatives, but the name suffices.
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 0%, and the description only restates 'address' without explaining its format or network specifics beyond the regex pattern. It adds minimal meaning over the schema's name and pattern.
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 the action (get), resource (native token balance), and network (Mezo testnet), effectively distinguishing it from sibling tools like mezo_get_balance (mainnet) and mezo_testnet_get_token_balance (token vs native).
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 context is implied by the network and native token specification, but the description does not explicitly mention alternatives or when not to use this tool. It relies on the name and sibling list for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_blockAGet block data by number or tag on Mezo testnet. Use hex block number (e.g. "0x1") or "latest". Returns full block object with transaction hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the return format (full block object with transaction hashes), providing useful behavioral context without contradicting 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?
Two concise sentences with no redundant information. The description directly states purpose, input format, and output, making it efficient and well-structured.
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 simple one-parameter tool with no output schema, the description is complete: it specifies the input format, return content, and scope. No essential information 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?
The schema description fully covers the 'block' parameter with hex and tag options and examples. The description adds little beyond the schema, so a baseline score of 3 is appropriate given the high schema coverage.
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 the tool retrieves block data by number or tag on Mezo testnet, with a specific verb and resource. It distinguishes from siblings like mezo_get_block (likely mainnet) and btc_* tools by naming the network and scope.
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?
Provides input format guidance (hex or 'latest') and context that it is for Mezo testnet. However, it does not explicitly mention when to use this over mezo_get_block or other siblings, though the name implies the testnet scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_codeAGet bytecode at an address on Mezo testnet. Returns "0x" for EOAs (wallets), non-empty hex for contracts. Use to determine if an address is a contract or EOA, and to retrieve deployed bytecode.
| Name | Required | Description | Default |
|---|---|---|---|
| block | No | Block to query (default: "latest") | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint. Description adds valuable context: returns '0x' for EOAs, non-empty hex for contracts, which helps interpret the response. This goes beyond annotation 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?
Two sentences, no waste, front-loaded action.
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?
With no output schema, the description explains return values and use case. Covers both parameters contextually, and read-only nature is in annotations. Sufficient for this simple tool.
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 covers block with description but address lacks description. Tool description clarifies the address argument via context, but doesn't elaborate on block semantics. Coverage at 50% is borderline; description partially compensates.
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?
Clear verb+resource: 'Get bytecode at an address on Mezo testnet.' Explicitly distinguishes from siblings by specifying testnet and explaining return semantics for EOAs vs contracts.
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?
States 'Use to determine if an address is a contract or EOA' which gives clear context. Does not explicitly mention alternatives like mezo_get_code, but network specificity provides implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_logsAGet event logs matching a filter on Mezo testnet. Requires at least fromBlock and toBlock. Optionally filter by contract address and topics.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | Array of topic filters. Each element is a topic hash, null for wildcard, or an array of topic hashes for OR matching. | |
| address | No | Contract address to filter logs | |
| toBlock | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") | |
| fromBlock | Yes | Block number as hex (e.g. "0x1") or tag ("latest", "earliest", "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already conveys that this is a safe read operation, and the description does not contradict it. However, the description adds little behavioral detail beyond the annotations and schema, such as pagination, ordering, or return format, so it only meets the baseline for annotated tools.
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 three short sentences, immediately states the main purpose, and includes only necessary usage constraints. Every sentence adds value with no redundancy or fluff.
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 core operation, required and optional parameters, and the target network, which is sufficient given the tool's moderate complexity and rich schema. It does not explicitly describe the return format, but the name and purpose make that predictable, so a small gap remains.
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 descriptions cover 100% of the parameters, so the baseline is 3. The description reinforces which parameters are required vs optional but adds no new meaning beyond what the schema already states.
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 the specific verb 'Get' with a clear resource ('event logs') and scope ('on Mezo testnet'), distinguishing it from siblings like eth_get_logs and mezo_get_logs. It also mentions filtering by contract address and topics, giving a precise purpose.
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 clearly states that fromBlock and toBlock are required and that other parameters are optional, providing contextual usage guidance. It implies Mezo testnet usage but does not explicitly name alternatives or provide when-not conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_token_balanceAGet ERC-20 token balance for a wallet address on Mezo testnet. Returns raw balance, formatted balance with decimals, and token symbol. Calls balanceOf, decimals, and symbol on the token contract.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address | |
| wallet | Yes | Wallet address to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context by listing the on-chain calls (balanceOf, decimals, symbol) and the return format. It does not contradict annotations and provides useful detail beyond the structured fields.
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 concise sentences. It front-loads the primary purpose and then lists the return values and implementation calls, with no redundant or unnecessary 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?
For a simple read-only tool with two parameters and no output schema, the description is fairly complete: it states the network, the resource, the return values, and the contract calls. It lacks explicit error handling or edge-case details, but the annotations and simplicity reduce the burden.
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 slight context by explaining that the token address is used to call decimals and symbol, and that a wallet address is for checking balance, but this largely mirrors the schema without significant new insight.
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 the tool gets an ERC-20 token balance for a wallet on Mezo testnet, using a specific verb and resource. It distinguishes from siblings by specifying the network in both the name and description, and details the return values, making the purpose 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 provides clear context for when to use this tool (Mezo testnet ERC-20 token balance) and mentions the specific contract calls. However, it does not explicitly name alternatives for when not to use it, such as mainnet or other chains, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_token_infoAGet ERC-20 token metadata for a token address on Mezo testnet. Returns name, symbol, decimals, and total supply (raw and formatted). Degrades gracefully — any individual call failure returns null for that field.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint and openWorldHint annotations: it discloses the specific return fields and the graceful degradation behavior where individual field failures return null. This is particularly useful because it sets expectations for partial failures, which is not evident from annotations alone.
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 concise sentences, front-loaded with the primary purpose, followed by return data and a key behavioral note about graceful degradation. Every word adds value, with no fluff or repetition.
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 simple single-parameter read-only tool, the description is complete: it states the input, the output fields, and the edge-case behavior (per-field null on failure). Without an output schema, listing the return fields is essential and adequately covers expected results. The network specificity also addresses the testnet context.
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%, with the sole parameter 'token' clearly described as 'ERC-20 token contract address'. The description merely echoes this by saying 'token address' but adds no new semantic detail; it relies on the schema for parameter meaning.
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 the action ('Get ERC-20 token metadata') and the specific resource ('a token address on Mezo testnet'), and it distinguishes from siblings by specifying the network and token standard. It also lists the exact return fields (name, symbol, decimals, total supply), leaving no ambiguity about the tool's function.
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 implies usage context by targeting 'Mezo testnet' and ERC-20 tokens, but it does not explicitly state when to prefer this tool over alternatives like mezo_get_token_info or eth_get_token_info. There are no exclusions or alternative recommendations, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_transactionAGet transaction details by hash on Mezo testnet. Returns full transaction object including from, to, value, input data, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (32 bytes, hex-encoded with 0x prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to cover safety. It adds return-field details (from, to, value, input data, status) but does not disclose edge-case behaviors like not-found handling or transaction state nuances.
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?
One sentence with front-loaded purpose, followed by return-value details. Every word earns its place—no fluff or redundancy.
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 low complexity (one parameter), annotations for read-only, and no output schema, the description provides enough context by listing key return fields. It doesn't cover error cases, but for a simple lookup tool this is acceptable.
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 single 'hash' parameter is fully described in the schema with type, pattern, and explanation. The description adds no extra parameter semantics, so 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?
The description clearly states the verb 'Get' and resource 'transaction details by hash', and specifies the network 'Mezo testnet'. This distinguishes it from sibling tools for other networks (btc, eth, mezo mainnet).
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 network context 'on Mezo testnet' is clear, but there is no explicit mention of when to use this versus alternatives like mezo_get_transaction_receipt. The context is unambiguous enough for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mezo_testnet_get_transaction_receiptAGet transaction receipt by hash on Mezo testnet. Returns status (0x1=success, 0x0=fail), gasUsed, contractAddress (for contract deployments), and event logs.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (32 bytes, hex-encoded with 0x prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses return fields (status, gasUsed, contractAddress, event logs) and explains status values (0x1=success, 0x0=fail). This adds useful behavioral context that is not in the schema or 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 a single, front-loaded sentence that efficiently states the purpose and key return information without unnecessary 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?
Given the simple tool (one parameter, no output schema), the description covers the action and key return fields. It does not mention edge cases like missing receipts, but the annotations and schema provide adequate context for a straightforward read-only lookup.
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 already provides thorough documentation for the 'hash' parameter (32 bytes, hex-encoded with 0x prefix). The description only says 'by hash', adding no additional semantic detail, so it meets the baseline but does not elevate beyond it.
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 the tool's function: 'Get transaction receipt by hash on Mezo testnet.' It identifies the specific verb, resource, and network, which distinguishes it from sibling tools like mezo_get_transaction or eth_get_transaction_receipt.
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 context ('on Mezo testnet') but does not explicitly mention when to use this instead of alternatives or provide exclusions. It implies usage for fetching receipts on Mezo testnet but lacks explicit guidance about alternatives like mainnet equivalents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
