Safety-first EVM and Bitcoin RPC tools for balances, contracts, blocks, and transactions
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 3.9/5 across 18 of 18 tools scored.
Each tool is clearly scoped to a specific chain (btc_ vs evm_) and action (broadcast, decode, estimate, get, call, read). There is no overlap or ambiguity between tools, and even similar-sounding operations like evm_call, evm_readContract, and evm_estimateTransaction are distinct in their purpose and input requirements.
All tools follow a consistent snake_case pattern with chain prefix (btc_ or evm_) followed by a descriptive verb and noun (e.g., btc_getBlock, evm_getLogs). The naming is uniform across both chains, making it predictable and easy to navigate.
At 18 tools, the server sits in the 16-25 range which is considered heavy per the rubric. While the count is justifiable given the dual-chain scope, it could be trimmed or grouped further. It doesn't feel overwhelming, but it's above the typical well-scoped range.
The server covers the essential read and write operations for both Bitcoin and EVM chains, including balances, blocks, transactions, gas estimation, contract reads, and transaction broadcasting. No critical gaps are apparent for a chain RPC server, and all common workflows are supported.
btc_broadcastTransactionBValidate and broadcast an already-signed Bitcoin transaction. Disabled unless ALLOW_BITCOIN_BROADCAST=true; never signs or stores keys.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmation | Yes | ||
| rawTransaction | Yes | ||
| expectedNetwork | Yes | ||
| maxFeeRateBtcPerKvB | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, but the description adds unique context: the tool is disabled unless an environment variable is set, and it never signs or stores keys. These are valuable behavioral details not in annotations, though it doesn't cover return values or error cases.
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 contain only essential details with no fluff. The key constraint (env var) and safety note (no key storage) are front-loaded, but the structure could be slightly improved by separating the prerequisite from the main function.
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 safety-critical nature (broadcasting real transactions) and the lack of output schema or parameter descriptions, the description is insufficient. It doesn't mention the confirmation requirement, network specificity, fee cap, or what the tool returns. The agent would need to infer too much from the schema alone.
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 does not explain any of the four parameters. It only hints that rawTransaction is the signed transaction, but doesn't clarify expectedNetwork, confirmation, or maxFeeRateBtcPerKvB. The description completely fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (broadcast) and resource (Bitcoin transaction), and clarifies it handles already-signed transactions. Sibling tools like decode and estimate are clearly distinct, as is the EVM broadcast sibling. The purpose is unambiguous and easily distinguishable.
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 prerequisite (ALLOW_BITCOIN_BROADCAST=true) and the core use case, but doesn't explicitly state when to avoid this tool or mention alternatives like evm_broadcastTransaction. The context is clear but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_decodeRawTransactionADecode a serialized Bitcoin transaction without broadcasting it.
| Name | Required | Description | Default |
|---|---|---|---|
| rawTransaction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the 'without broadcasting' detail but does not mention invalid-input behavior or return format. 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 a single, front-loaded sentence with no wasted words. It states the action, the resource, and the key constraint 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 decode operation with one parameter and strong annotations, the description is adequate. It does not describe the return value, but the tool name and 'decode' strongly imply a decoded transaction object, and no output schema is provided.
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%, so the description must compensate. It identifies the input as a 'serialized Bitcoin transaction', which maps to the rawTransaction parameter and adds some meaning beyond the property name. However, it does not explicitly describe the hex encoding or validation requirements, though the schema pattern covers the hex format.
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 'Decode' and a specific resource 'serialized Bitcoin transaction', and explicitly notes it does not broadcast. This clearly distinguishes it from sibling tools like btc_broadcastTransaction and btc_getTransaction.
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 'without broadcasting it' implies the tool is for inspecting or validating a transaction before submission, which gives useful context. It does not explicitly name alternatives or state when not to use it, but the contrast with broadcast is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_estimateFeeAEstimate a Bitcoin fee rate for confirmation within a target number of blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | conservative | |
| confirmationTarget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, fully covering the safety profile. The description adds minimal behavioral detail beyond the purpose (e.g., no mention of return units, error handling, or rate limits). With annotations doing the heavy lifting, a score of 3 is appropriate—it doesn't contradict but also doesn't enrich.
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 that avoids any filler. It concisely communicates the core action and the key input, earning full marks for efficiency.
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 good annotations, the description is adequate but leaves out the return format (e.g., sat/vB) and the impact of 'mode' on the estimate. Since no output schema exists, the description could have provided more detail on what the agent can expect, but the tool's simplicity and schema coverage balance this 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 0%, so the description must compensate. It explains 'target number of blocks' matching confirmationTarget, but provides no explanation of the 'mode' parameter (economical vs. conservative) or its default behavior. The schema itself lists enum values and ranges, but the semantic distinction is left undefined. This partial coverage warrants a middle score.
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 estimates a Bitcoin fee rate based on a confirmation target, which is distinct from other Bitcoin tools (broadcast, decode, balance) and EVM tools. The verb 'estimate' plus the resource 'Bitcoin fee rate' and the scope 'confirmation within a target number of blocks' make 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 that this is for estimating fees for a specific confirmation target, but it does not explicitly state when to use it over alternatives (e.g., evm_estimateTransaction) or mention any exclusions. The context is sufficient for typical use, but explicit alternative guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_getAddressBalanceAScan the Bitcoin UTXO set for an address and return its confirmed spendable outputs. This is not address history and shared RPC nodes may reject concurrent scans.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds meaningful behavioral context: it iterates over the UTXO set, only returns confirmed spendable outputs, and may fail on shared RPC nodes under concurrency.
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 core action and resource, followed by a useful limitation. No redundant or filler content.
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 strong annotations, the description covers purpose, scope, and failure modes. It does not explicitly describe the return format, but the tool name and 'confirmed spendable outputs' imply a balance-like result.
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 sole parameter 'address' is described only as an address in the Bitcoin UTXO context, which adds some meaning beyond the generic schema pattern. However, it does not clarify accepted address formats (e.g., bech32, base58), leaving some ambiguity.
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 ('Scan the Bitcoin UTXO set') and the target resource (an address), returning confirmed spendable outputs. It also explicitly distinguishes itself from address history, avoiding confusion with related tools like btc_getTransaction.
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 practical guidance by noting this is not address history and warns that shared RPC nodes may reject concurrent scans. While it does not explicitly name alternative tools, these caveats help the agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_getBlockARead a Bitcoin block by height or hash with selectable verbosity.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | ||
| verbosity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scoping detail of height/hash and selectable verbosity, but it does not explain what verbosity levels produce, response shape, or any other behavioral implications.
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 entire description is one efficient sentence that is front-loaded with the action and resource. No filler or redundant restatement is present.
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 read tool with strong annotations, but there is no output schema and verbosity levels are not explained. The description is enough to identify the tool and basic parameters, but incomplete for understanding the meaningful difference between verbosity values or what the response will contain.
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%, so the description must compensate. It does clarify that 'block' means a block height or hash and that 'verbosity' is selectable, which goes slightly beyond the raw schema. However, it does not explain what each verbosity level (0-3) means or how it affects the returned block data.
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 ('Read') and clearly names the resource ('a Bitcoin block') with the two primary lookup modes ('by height or hash') and the optional verbosity parameter. It also distinguishes this from sibling tools like btc_getTransaction and evm_getBlock by scoping it to Bitcoin block retrieval.
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 no explicit when-to-use guidance and does not mention alternatives such as btc_getTransaction, btc_getTxOut, or evm_getBlock. Usage context is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_getBlockchainInfoAReturn Bitcoin network, chain height, sync, and pruning information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already provide safety and idempotency information. The description adds context about what specific information is returned (network, chain height, sync, pruning), which is valuable beyond the annotations. It does not mention potential delays or caching, but with strong annotations, 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 a single sentence with no fluff, front-loaded with the key verb 'Return' and the resource 'Bitcoin network'. It is optimally concise, covering the essential points without wasting any words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has zero parameters and no output schema, but its purpose is simple—retrieve network info. Annotations comprehensively declare safety (readOnly, idempotent, non-destructive). The description clearly lists the information categories (network, height, sync, pruning), which is complete for an agent to invoke it appropriately. No additional details are needed.
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 this dimension is trivially satisfied. The schema coverage is 100% (no params to describe), and the description explains what the tool returns, which is the only relevant semantic. The baseline for 0 params is 4, and there is no reason to lower 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 uses specific verbs and resources: 'Return Bitcoin network, chain height, sync, and pruning information.' It clearly identifies the tool as retrieving blockchain info for the Bitcoin network, distinguishing it from siblings like evm_getChainInfo and btc_getBlock. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving general network status (height, sync, pruning) but does not explicitly state when to use this over siblings like btc_getBlock or evm_getChainInfo. It provides no exclusions or alternative recommendations, which is acceptable given the simplicity but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_getTransactionARead a raw Bitcoin transaction by txid. A block hash can make confirmed transaction lookup more reliable.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | ||
| blockHash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds a useful behavioral detail: providing a block hash improves reliability for confirmed transactions. 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?
Two concise, front-loaded sentences with no unnecessary words. Every phrase contributes to understanding the tool's action and a useful tip.
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 tool with rich annotations and schema, the description covers the core functionality and a reliability hint. It doesn't describe the return format or error handling, but given no output schema and the tool's simplicity, this is adequate.
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 0%, so the description must compensate. It explains that txid is the identifier and blockHash is optional, adding that blockHash improves reliability. This adds semantic value beyond the schema's patterns but remains minimal.
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 'Read a raw Bitcoin transaction by txid' – a specific verb, resource, and identifier. This distinguishes it from siblings like btc_getTxOut (which returns a transaction output) and evm_getTransaction (EVM-specific).
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 context that a block hash can make confirmed transaction lookup more reliable, implying when to use the optional parameter. However, it does not explicitly mention alternatives or when not to use this tool, so it's clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btc_getTxOutARead an unspent Bitcoin transaction output. Returns null when the output is spent or unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | ||
| vout | Yes | ||
| includeMempool | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent hints, so the bar is lower. The description adds valuable behavior context by stating that null is returned when the output is spent or unknown, which is not conveyed by 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 with no wasted words. It communicates the primary action and key return behavior 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?
The description covers the essential return behavior (null for spent/unknown) and clarifies the scope (unspent outputs). It lacks detail on the includeMempool parameter, but given the simple tool and existing annotations, it is largely 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 0%, and the description does not compensate by explaining any of the three parameters (txid, vout, includeMempool). The description adds no meaning beyond the schema's structural constraints.
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 reads an unspent Bitcoin transaction output, with a specific verb and resource. It distinguishes itself from siblings like btc_getTransaction (which reads entire transactions) by focusing on outputs and noting null returns for spent/unknown outputs.
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 checking unspent outputs but lacks explicit guidance on when to use this tool versus alternatives such as btc_getTransaction or btc_getAddressBalance. No exclusion criteria or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_broadcastTransactionAPreflight and broadcast an already-signed EVM transaction. Disabled unless ALLOW_EVM_BROADCAST=true; never signs or stores keys.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmation | Yes | ||
| rawTransaction | Yes | ||
| expectedChainId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations: it states the tool is disabled unless a specific environment variable is set, and it explicitly says 'never signs or stores keys.' This is valuable because the annotations already indicate destructiveHint=true and readOnlyHint=false, but the description clarifies the safety aspect regarding key handling. 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?
The description is two sentences, front-loaded with the main purpose, and includes a critical usage condition and a safety note. Every sentence earns its place; no 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?
Given the tool's complexity (broadcasting a real transaction) and the lack of an output schema, the description covers the essential points: what it does, the preflight aspect, the environment variable gate, and the key-handling safety. It could have mentioned that the transaction must be signed and that broadcasting is irreversible, but the destructiveHint annotation already covers irreversibility. Overall, it's fairly complete for a tool with this schema richness.
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 0% description coverage, so the description must compensate. The description does not explain the parameters (rawTransaction, expectedChainId, confirmation) beyond what the schema provides. The confirmation parameter's const value is self-explanatory, but the description could have added context about expectedChainId's purpose (e.g., to prevent replay attacks). Since the schema already defines the parameters with types and constraints, the description adds minimal value here.
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: 'Preflight and broadcast an already-signed EVM transaction.' It uses a specific verb ('broadcast') and resource ('already-signed EVM transaction'), and distinguishes it from siblings like evm_call and evm_estimateTransaction by focusing on broadcasting a signed transaction.
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 mentions a critical usage condition: 'Disabled unless ALLOW_EVM_BROADCAST=true.' This tells the agent when the tool is available. However, it does not explicitly state when to use this tool versus alternatives like evm_estimateTransaction for preflight, though the purpose implies it. It also doesn't mention that the transaction must be signed, which is implied by 'already-signed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_callARun a read-only eth_call with pre-encoded calldata. This never submits a transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| data | No | 0x | |
| from | No | ||
| block | No | ||
| valueWei | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint: false. The description repeats and reinforces the read-only/non-submitting behavior without adding notable behavioral detail such as state implications, permission requirements, or edge-case side effects. There is 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?
Two short sentences clearly communicate the action and its read-only nature. Every sentence serves a purpose, and the most important information is front-loaded. No filler or redundant restatement of the schema is present.
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 a standard eth_call, but there are five parameters and no output or explanatory text on return format or block/valueWei semantics. The phrase 'pre-encoded calldata' and read-only framing cover the basics, but the description stops short of fully clarifying inputs and call semantics for an agent choosing or invoking 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?
Schema description coverage is 0%, so the description must compensate for explaining parameter meaning. It only reveals that calldata is 'pre-encoded,' which relates to data but leaves to, from, block, and valueWei unexplained. The schema property names carry most of the semantic load, and the description adds minimal lift.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Run a read-only eth_call with pre-encoded calldata.' It clearly distinguishes itself from broadcasting or estimating tools by noting it never submits a transaction, and the 'pre-encoded calldata' phrasing differentiates it from the ABI-aware evm_readContract sibling.
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 makes the core use case clear: use this when you need a read-only eth_call with raw calldata and must not submit a transaction. It does not explicitly name alternatives or exclusion conditions, but its read-only/no-transaction framing gives enough directional guidance without being misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_estimateTransactionBEstimate gas for an unsigned EVM transaction. Values are accepted as decimal or hex quantities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safe read-only nature is covered. The description adds that it accepts decimal or hex quantities, which is a meaningful behavioral detail beyond annotations. However, it doesn't cover what happens with invalid inputs or if any network calls are made, but given the strong annotation coverage, this is acceptable.
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, highly efficient, and provides essential information without redundancy. It is front-loaded with the action and includes the key detail about quantity formats. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description is relatively complete. However, it doesn't specify what the output looks like (estimated gas value format) or any prerequisites like chain context. Given the simplicity, it's adequate but could mention that it's per-chain or that the transaction must be unsigned.
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 zero parameters, so the description's note about decimal or hex quantities provides the only parameter-related semantics. Since there are no parameters, the description accurately reflects likely inputs. The baseline for 0 params is 4, and the description adds clarity about value formats.
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 estimates gas for an unsigned EVM transaction, which is a specific action. It distinguishes from sibling tools like evm_call or evm_getTransaction, though it doesn't explicitly name alternatives. The purpose is clear and distinct.
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?
There is no guidance on when to use this tool versus alternatives. The description implies it's for estimation before broadcasting, but it doesn't state when-not-to-use or mention sibling tools. Context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_getBlockARead an EVM block by number, tag, or block hash.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | ||
| includeTransactions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds input scoping (number/tag/hash) but does not disclose return format, error behavior, or the effect of includeTransactions.
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 with no filler or redundant information. Every word contributes to 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?
The tool is simple and annotations are rich, but the description omits includeTransactions semantics and does not enumerate possible block tags. This is a clear gap for a tool with only two parameters and no 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?
With 0% schema description coverage, the description explains the block parameter as accepting number, tag, or hash, which adds meaning to the schema's anyOf. However, it does not describe includeTransactions, leaving one parameter semantically under-specified.
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 'Read' with the resource 'EVM block' and explicitly lists the accepted identifiers ('by number, tag, or block hash'). This clearly distinguishes it from sibling tools like evm_getBlockNumber and evm_getTransaction.
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 the tool is for reading block data but does not explicitly state when to prefer it over alternatives such as evm_getBlockNumber or evm_getTransaction. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_getBlockNumberAReturn the latest EVM block number from the configured endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds only that it reads from the configured endpoint and returns the latest number, which is useful but limited; it does not mention return format or endpoint-specific behavior. There is 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 a single, direct, front-loaded sentence with no filler. It communicates exactly what the tool does and where the value originates.
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 zero-parameter, read-only getter with a straightforward result. The sentence 'Return the latest EVM block number from the configured endpoint' is sufficient for an agent to select and invoke it correctly, especially given the rich annotations and empty 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 input schema has zero parameters, so there is nothing meaningful for the description to explain about parameters. The baseline for a zero-parameter tool is 4, and the description correctly adds no unnecessary parameter text.
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 ('Return') and a precise resource ('latest EVM block number') from the configured endpoint. It also distinguishes itself from siblings like evm_getBlock, which fetches block data rather than the latest block number.
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 intended usage is implied by 'Return the latest EVM block number': use this when you need the current head of the EVM chain. However, the description does not explicitly say when to prefer it over evm_getBlock or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_getChainInfoAReturn the EVM chain ID and upstream client version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive, and the description adds the specific return content (chain ID and client version), which is valuable beyond the annotations. No additional behavioral traits are disclosed, but the description is adequate for a simple read-only call.
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 is concise and front-loaded, with no wasted words. It fully conveys the tool's purpose without 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 tool with no parameters, no output schema, and comprehensive annotations, the description is complete enough. It clearly specifies what the tool returns, and the simplicity of the tool does not require 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 tool has zero parameters, so the schema trivially covers all parameters. The description correctly avoids mentioning parameters, and the baseline for 0 params is 4, indicating no need for further elaboration.
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 returns EVM chain ID and upstream client version, which is specific and distinguishes it from sibling tools that handle transactions, blocks, or balances.
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?
No guidance is provided on when to use this tool versus alternatives. It simply states the function without any context about typical use cases or exclusions, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_getLogsARead EVM event logs using an address/topics filter and bounded block range.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the constraint of a 'bounded block range' as a behavioral requirement, but does not describe return format, pagination, or error behavior.
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 main verb and resource, with no redundant words. It effectively communicates the essential 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 read-only log query tool with no output schema, the description provides adequate context on scope and constraints. It doesn't mention the return format, but the annotations and simple nature of the tool reduce the need for extensive detail.
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 the description carries the full burden. It names the key dimensions of the query (address, topics, block range) which aligns with the tool's purpose, but does not provide actual parameter names or types, leaving a gap for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with the resource 'EVM event logs' and specifies the filtering criteria ('address/topics filter and bounded block range'), clearly distinguishing it from sibling tools like evm_getBlock or evm_getTransaction.
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 retrieving event logs and specifies the filtering mechanism, providing sufficient context for when to use it. However, it does not explicitly exclude alternatives or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_getNativeBalanceARead an address native-token balance at an EVM block without requiring a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| block | No | Block number or latest, earliest, pending, safe, or finalized | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the behavioral detail that no wallet is required, which goes beyond annotations by clarifying access requirements. No contradictions found.
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 with no redundant or extraneous text. Every word contributes to explaining the tool's core function and key characteristic (no wallet needed).
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 (2 params, no output schema) and strong annotations, the description is adequately complete. It states the purpose clearly and adds the wallet requirement. It does not specify the return format, but the absence of an output schema and the simplicity of the read make this 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 50%: only 'block' has a description, while 'address' has none. The description mentions 'at an EVM block' which implicitly references the block parameter, but it does not explain the format or options for block values beyond what the schema already states. It adds no meaningful parameter 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 action ('Read'), the resource ('address native-token balance'), and the context ('at an EVM block'). It distinguishes itself from siblings like evm_call or evm_readContract by focusing specifically on native token balance, making its 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 phrase 'without requiring a wallet' provides clear context that this is a public read, implying no authentication is needed. However, it does not explicitly name alternative tools for cases where a contract balance or other EVM data is needed, so it lacks 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.
evm_getTransactionARead an EVM transaction and its receipt by transaction hash.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety and side-effect profile. The description adds the output composition (transaction and receipt) but no deeper behavioral traits like error handling or auth requirements. With strong annotations, the description does not need to duplicate them, so a 3 is appropriate.
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, concise sentence with no redundancy. It front-loads the action ('Read') and resource, and 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?
The tool is simple: one parameter, no output schema, and strong annotations. The description fully explains what the tool does and what it returns (transaction and receipt). It is complete enough for an agent to invoke it correctly given a valid hash.
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 0%; the description does not explicitly describe the 'hash' parameter semantics beyond the schema's regex pattern. Although it says 'by transaction hash', it does not clarify that the hash is a 32-byte EVM transaction hash or provide any additional context. With zero coverage, the description should compensate, but it barely does.
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 reads an EVM transaction and its receipt by transaction hash, using a specific verb (Read) and resource. It distinguishes from siblings like evm_getBlock (blocks) and evm_getLogs (logs) by explicitly targeting transactions.
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: when you have a transaction hash and need both the transaction and receipt. It does not explicitly state alternatives or exclusions, but the context is clear from the verb and resource. This is 'clear context, no exclusions' per the rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evm_readContractAEncode, execute, and decode a read-only smart-contract function using a supplied JSON ABI.
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | JSON ABI entries needed for this function | |
| args | No | ||
| block | No | ||
| address | Yes | ||
| functionName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and open-world behavior. The description adds value by explaining the full encode-execute-decode workflow, which informs the agent that input encoding and output decoding are handled automatically. However, it does not disclose error handling or return format.
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, no fluff, front-loads the main purpose with strong verb and object.
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 is too terse for a tool with 5 parameters and no output schema. It does not explain what the decoded result looks like, how block parameter affects execution, or potential revert/error behavior, leaving the agent under-informed.
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 only one described parameter (abi), with 20% coverage. The description references ABI but provides no details about address, functionName, args, or block semantics, failing to compensate for the schema gaps.
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 it encodes, executes, and decodes a read-only smart-contract function using a JSON ABI. The 'read-only' modifier precisely defines the operation, distinguishing it from transaction broadcast or state-changing 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 for read-only contract calls with ABI decoding but does not explicitly compare to sibling tools like evm_call or evm_broadcastTransaction. No exclusions or alternative recommendations are provided.
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!
Sign in to create a connector for this server.