tenzro-ethereum
Server Details
Ethereum tools over MCP: Chainlink feeds, ENS, ERC-8004 agents, EAS attestations, transactions.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.9/5 across 17 of 17 tools scored. Lowest: 3.2/5.
Each tool targets a distinct operation (call, encode, estimate, balance, block, ENS, etc.) without overlap. Even similar-sounding tools like eth_get_balance and eth_get_token_balance are clearly separated by native vs. ERC-20, and eth_lookup_ens vs. eth_resolve_ens handle opposite directions.
All tools use the 'eth_' prefix and snake_case with a verb-noun structure (e.g., eth_call_contract, eth_get_balance, eth_register_agent_8004). No mixing of conventions; naming is predictable and uniform.
With 17 tools, the set covers a broad range of Ethereum operations without being bloated. It's slightly high but still well-scoped for a comprehensive blockchain server.
The tools cover core read and write operations (balances, transactions, gas, ENS, agent registry) but lack direct support for contract deployment, event logs, or transaction signing (which is outsourced). Minor gaps exist, but the main workflows are supported.
Available Tools
17 toolseth_call_contractAInspect
Execute a read-only eth_call against a smart contract. Params: to (contract address), data (hex-encoded calldata), block (default 'latest'). Returns the raw hex result. Use eth_encode_function to build calldata from a function signature and arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Contract address (hex, with or without 0x prefix) | |
| data | Yes | Hex-encoded calldata (with or without 0x prefix) | |
| block | No | Block parameter ('latest', 'earliest', 'pending', or hex block number). Default: 'latest' |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly states the call is read-only and returns raw hex data. However, it omits potential error behaviors, rate limits, or authorization requirements, which are important for an AI agent to use the tool safely.
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 concise with two sentences, no filler, and the key information is front-loaded. It efficiently communicates the purpose, parameters, return, and a usage 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?
The description covers the core functionality, parameters, return type, and a related tool for calldata building. Given the presence of an output schema (assumed from context), it is reasonably complete for a simple read-only call, though it could mention that the call does not cost gas.
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 description reiterates the parameter names, hex encoding, and default block value. While helpful, it adds little beyond the schema's descriptions. The pointer to eth_encode_function adds context but does not deeply explain parameter 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 executes a read-only eth_call and specifies the contract address and calldata. It differentiates from siblings by mentioning eth_encode_function for building calldata, but does not explicitly distinguish from other eth_call-based tools like eth_estimate_gas.
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 recommends using eth_encode_function to build calldata, providing a useful workflow hint. However, it lacks explicit guidance on when to use this tool vs alternatives such as eth_estimate_gas or eth_get_balance, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_encode_functionAInspect
ABI-encode a function call. Computes the 4-byte selector from the canonical function signature via Keccak-256, then left-pads each argument to 32 bytes. Returns the complete hex-encoded calldata ready for eth_call or a transaction. Example: function_sig='transfer(address,uint256)', args=['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xde0b6b3a7640000'].
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | Arguments as JSON array of hex-encoded values (each will be left-padded to 32 bytes). E.g. ['0xRecipientAddress', '0xde0b6b3a7640000'] | |
| function_sig | Yes | Canonical function signature (e.g. 'transfer(address,uint256)', 'approve(address,uint256)', 'balanceOf(address)') |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It transparently explains the encoding algorithm: computing the 4-byte selector via Keccak-256 and left-padding arguments. However, it does not address error cases (e.g., invalid function signature) or performance characteristics.
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 concise (three sentences) and front-loaded with the core purpose. Every sentence adds value without redundancy. The structure flows logically from statement to example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description need not detail return values. It sufficiently covers what the tool does and the input requirements, making it complete for its intended 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%, but the description adds meaningful context: it explains that function_sig is a 'canonical function signature' and that args are hex-encoded and will be left-padded. The example further clarifies the expected 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 clearly states the tool's purpose: ABI-encode a function call. It specifies the verb 'encode', the resource 'function call', and details the process (selector computation, left-padding). It distinguishes from sibling tools like eth_call_contract and eth_send_raw_transaction by focusing solely on encoding, not execution.
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 preparing calldata for eth_call or a transaction but does not explicitly state when to use this tool versus alternatives (e.g., when calldata is already encoded). There is no guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_estimate_gasBInspect
Estimate gas required for a transaction via eth_estimateGas. Params: to (required), from/data/value (optional). Returns estimated gas in decimal and hex.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient/contract address (hex, with or without 0x prefix) | |
| data | No | Hex-encoded calldata (with or without 0x prefix) | |
| from | No | Sender address (hex, with or without 0x prefix) | |
| value | No | Value in wei (hex string, e.g. '0xde0b6b3a7640000' for 1 ETH) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool returns an estimated gas amount but does not disclose behavioral traits such as that it is a read-only RPC call, potential side effects, required permissions, or rate limits. This is minimal 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 extremely concise with only two sentences. The first sentence states the purpose and the second lists parameters and return value. No words are wasted, and it is 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?
Given the tool's simplicity, the description covers the essential aspects: purpose, required/optional parameters, and return format. It does not mention error cases or the fact that value must be in wei hex, but the schema already handles that. Overall, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all four parameters already in the schema. The description condenses the parameter list but adds no new meaning beyond what the schema provides. Hence, 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 'Estimate gas required for a transaction via eth_estimateGas.' It identifies the specific verb (estimate) and resource (gas for a transaction). However, it does not explicitly differentiate from sibling tools like eth_get_gas_price, which also deals with gas, but the purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a simple list of parameters but offers no guidance on when to use this tool versus alternatives like eth_call_contract or eth_send_raw_transaction. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_attestationAInspect
Query an attestation from Ethereum Attestation Service (EAS) by UID. Posts a GraphQL query to the EAS indexer at easscan.org. Returns attester, recipient, schema, data, timestamp, revocation status, and decoded data when available.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Attestation UID (bytes32 hex, with or without 0x prefix) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states it posts a GraphQL query to easscan.org and returns specific fields, but does not disclose potential behaviors like network latency, error responses, 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?
Two sentences pack the essential information: what it does, how it works (GraphQL), and what it returns. No fluff, but could be slightly more 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?
Given the single parameter and presence of an output schema, the description adequately explains the tool's core function. However, it omits details like behavior on missing UID or handling of optional parameters.
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 the single parameter 'uid' with 100% description. The tool description adds no extra meaning beyond 'by UID', so it meets the baseline without adding 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 specifies the verb 'query' and the resource 'attestation', and distinguishes it from sibling tools like eth_get_transaction or eth_get_balance by focusing on EAS attestations.
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 does not provide explicit when-to-use or alternatives. It mentions querying by UID but lacks guidance on when this tool is preferred over others, such as searching or listing attestations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_balanceAInspect
Get the ETH balance of an address via eth_getBalance. Returns balance in wei, Gwei, and ETH.
| Name | Required | Description | Default |
|---|---|---|---|
| block | No | Block parameter ('latest', 'earliest', 'pending', or hex block number). Default: 'latest' | |
| address | Yes | Ethereum address (hex, with or without 0x prefix) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read operation without side effects, but does not disclose potential errors, rate limits, or authentication needs. The return format is stated, which adds basic transparency.
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, efficient sentence that conveys the purpose and return format with no extraneous words. Front-loaded with key 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?
Given the simple tool with 2 parameters, 100% schema coverage, and an output schema, the description adequately covers the core functionality and return format. It could mention the optional block parameter, but the schema already handles that.
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 adequately described in the schema. The description does not add additional meaning beyond what the schema provides, 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 the resource 'ETH balance of an address', and specifies the output in three units (wei, Gwei, ETH). It distinguishes from sibling tools like eth_get_token_balance by focusing on native ETH 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?
No guidance on when to use this tool versus alternatives like eth_get_token_balance, nor any prerequisites or restrictions. The description purely states functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_blockAInspect
Get block by number via eth_getBlockByNumber. Params: block_number (hex or 'latest'), full_transactions (bool, default false). Returns block header, transactions, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| block_number | No | Block number as hex string (e.g. '0x10d4f') or tag ('latest', 'earliest', 'pending'). Default: 'latest' | |
| full_transactions | No | If true, return full transaction objects instead of just hashes. Default: false |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose read-only nature, potential side effects, or restrictions. With no annotations, the description should provide more 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?
Two concise sentences with key information front-loaded. No redundancy 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?
With output schema present, high-level return description suffices. Lacks usage guidance but parameters are fully specified. Adequate for a simple get 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?
Input schema has 100% coverage of parameters. The description repeats parameter names and defaults without adding new semantics. Baseline 3 is appropriate as schema carries the load.
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?
Clearly states the action 'Get block by number' and the resource 'block'. Specifies it returns block header, transactions, and metadata, distinguishing it from sibling tools that retrieve transactions 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 explicit guidance on when to use this tool versus alternatives like eth_get_transaction or eth_call_contract. The purpose is implied but not compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_fee_historyAInspect
Get fee history for recent blocks via eth_feeHistory. Returns base fees per gas, gas used ratios, and reward percentiles for EIP-1559 gas estimation.
| Name | Required | Description | Default |
|---|---|---|---|
| block_count | No | Number of blocks to return (default '5') | |
| newest_block | No | Newest block ('latest' by default, or hex block number) | |
| reward_percentiles | No | Reward percentiles as JSON array of floats (e.g. [25.0, 50.0, 75.0]) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It discloses the return data (base fees, gas used ratios, reward percentiles) and that it calls eth_feeHistory, but does not mention read-only nature, rate limits, or other behavioral traits. The output schema likely covers the return structure, so the description adds moderate 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, front-loaded with the main action, and includes key return fields. It is efficient and easy to read, though it could be slightly optimized by merging sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (covering return values) and 100% schema coverage for parameters, the description adequately covers the tool's purpose and key behavioral aspects. It does not explain when to use vs siblings, but for a straightforward read tool, 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?
Schema description coverage is 100% (all parameters documented in schema). The description does not add extra meaning to parameters beyond what the schema provides (e.g., block_count default, newest_block format, reward_percentiles array). Baseline score of 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'fee history for recent blocks', and specifies what is returned (base fees, gas used ratios, reward percentiles) for EIP-1559 gas estimation. It distinguishes itself from sibling tools like eth_get_gas_price and eth_get_block by focusing on fee history data.
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 EIP-1559 gas estimation and recent blocks, but does not explicitly state when to use this tool vs alternatives (e.g., eth_get_gas_price for current gas price). No when-not or alternative tool guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_gas_priceAInspect
Get the current gas price from the Ethereum network via eth_gasPrice JSON-RPC. Returns the gas price in wei, Gwei, and hex.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation but does not explicitly state it is read-only, idempotent, or free of side effects. This is sufficient for a simple getter but lacks explicit safety guarantees.
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 concise sentence that is front-loaded with the purpose and includes key details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and output with an output schema present. It could mention its read-only nature more explicitly, but given the simplicity, it is nearly 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 tool has zero parameters, so schema coverage is 100% trivially. The description adds no parameter information because none exist. Baseline for 0 params is 4, and this is satisfied.
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 current gas price from Ethereum via a specific JSON-RPC method and specifies the return values in wei, Gwei, and hex. It distinguishes from siblings like eth_estimate_gas and eth_get_price by focusing on 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?
No guidance on when to use this tool versus alternatives. It does not mention scenarios where other tools like eth_estimate_gas or eth_get_fee_history might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_priceAInspect
Get token price from a Chainlink AggregatorV3Interface data feed via eth_call to latestRoundData(). Default feed: ETH/USD on mainnet (0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419). Returns price with 8 decimal precision, round ID, and update timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | Chain ID — 1 for mainnet (default), 8453 for Base, 42161 for Arbitrum. Selects the dRPC chain-specific URL for the feed read. | |
| feed_address | No | Chainlink AggregatorV3Interface data feed address (default: ETH/USD 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description details internal mechanism (eth_call to latestRoundData), default feed, return format (8 decimals, round ID, timestamps). Lacks explicit statement of read-only nature, but 'Get' implies it.
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 action and mechanism, no redundant words. Efficiently conveys key 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?
Given output schema exists, description covers essentials but lacks usage guidelines, error handling, or prerequisites. Adequate but not comprehensive for a tool with many siblings.
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 100% provides baseline 3. Description adds default feed address and chain ID mapping (1 for mainnet, etc.), enhancing parameter understanding beyond 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?
Description clearly states 'Get token price from a Chainlink AggregatorV3Interface data feed', with specific verb and resource. Distinguishes from siblings like eth_call_contract by focusing on price oracles.
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 explicit guidance on when to use vs alternatives like eth_call_contract. Implies usage only through description of functionality, but no when-not or preference statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_token_balanceAInspect
Get ERC-20 token balance for an address via eth_call to balanceOf(address). Params: token_address (ERC-20 contract), owner_address. Returns raw balance (caller must divide by 10^decimals for human-readable amount).
| Name | Required | Description | Default |
|---|---|---|---|
| owner_address | Yes | Owner address to check balance for (hex, with or without 0x prefix) | |
| token_address | Yes | ERC-20 token contract address (hex, with or without 0x prefix) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the underlying eth_call, the raw uint256 return, and the need to divide by decimals. This is sufficient for a read-only operation.
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: first states purpose and method, second lists parameters and return handling. 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?
The tool is simple with two parameters and an output schema (implied by context). The description covers the essential behavior and return conversion, though it could mention potential errors (e.g., 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?
Schema coverage is 100% with clear descriptions, but the description adds context (ERC-20 contract, eth_call, return format) that goes beyond the schema, providing meaningful guidance for usage.
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 retrieves an ERC-20 token balance using eth_call to balanceOf(address), distinguishing it from siblings like eth_get_balance (native ETH) and eth_call_contract (generic calls).
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 ERC-20 tokens by specifying the token contract and balanceOf method, but does not explicitly state when to avoid using this tool (e.g., for native ETH or non-standard tokens).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_transactionAInspect
Get transaction details by hash via eth_getTransactionByHash. Returns sender, recipient, value, gas, input data, block number, and nonce.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash (hex, with or without 0x prefix) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the tool as returning transaction data but does not disclose potential errors, rate limits, or idempotency. For a read-only operation this is minimally sufficient but not comprehensive.
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 that front-loads purpose and lists returned fields. Efficient but could be structured as a bullet list for clarity. Minimal waste.
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 interface (1 parameter, no nested objects, output schema implied) and high schema coverage, the description adequately covers what is needed. The listed return fields provide sufficient context, though no output schema is shown.
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% for the single parameter tx_hash, with a clear description in the schema. The tool description adds the underlying method name but no additional semantics beyond schema. 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 transaction details by hash, specifies the underlying eth_getTransactionByHash method, and lists the returned fields (sender, recipient, value, gas, etc.). This distinctly differentiates it from sibling tools like 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 implies usage for fetching transaction details, but no explicit guidance on when to use it versus alternatives (e.g., eth_get_transaction_receipt for receipt data) is provided. Context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_get_transaction_receiptAInspect
Get transaction receipt by hash via eth_getTransactionReceipt. Returns status (0x0=failure, 0x1=success), gas used, logs, contract address (if deployment), and block info.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash (hex, with or without 0x prefix) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return values (status, gas used, logs, etc.), which is useful. However, it does not mention error cases (e.g., invalid hash) or any prerequisites, but for a simple read operation, 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?
The description is a single, clear sentence that front-loads the purpose and lists key return info. 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?
Given the tool has one parameter and an output schema exists, the description fully explains what the tool does and what it returns. It is complete 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 coverage is 100% as the only parameter (tx_hash) is described in the schema. The description does not add significant meaning beyond 'by hash', 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 tool gets a transaction receipt by hash, lists the returned fields (status, gas used, logs, contract address, block info), and implicitly distinguishes from sibling eth_get_transaction which would return transaction details.
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 indicates the tool is used to get a transaction receipt via hash, providing clear context. However, it does not explicitly mention when not to use it or provide alternative sibling tools, though the distinction from eth_get_transaction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_lookup_agent_8004AInspect
Look up an AI agent in the ERC-8004 Agent Registry by agent ID (uint256) or owner address. Builds the calldata for getAgent(uint256) or getAgentsByOwner(address) that can be used with eth_call_contract against a deployed ERC-8004 registry.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id_or_address | Yes | Agent ID (uint256 hex) or owner address (hex) to look up |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explicitly states it builds calldata (not executing), implying it is a read-only operation. Could be clearer about non-destructive nature, but 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 sentences, clear and efficient. Every word serves a 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?
Single parameter, output schema exists (not shown but context indicates true). Description adequately covers input and purpose; output format not detailed but schema fills gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond schema by explaining the two underlying functions (getAgent and getAgentsByOwner) based on input type. Schema already has description of the parameter, so baseline 3; gains a point for context.
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 looks up an AI agent by ID or address and builds calldata. It distinguishes from sibling tools like eth_call_contract (execution) and eth_encode_function (generic encoding).
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?
Implicitly indicates usage with eth_call_contract, but lacks explicit guidance on when to use vs alternatives like eth_encode_function or direct eth_call. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_lookup_ensAInspect
Reverse-lookup an Ethereum address to its ENS name via the Universal Resolver on-chain. Constructs .addr.reverse and calls resolve(). Falls back to OnchainKit ENS API. Params: address (hex).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address to reverse-lookup (hex, with or without 0x prefix) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the mechanism (constructs .addr.reverse, calls resolve(), with fallback) but does not disclose read-only nature, permissions, failure modes, or rate limits. With no annotations provided, more behavioral context would be beneficial.
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 sentences, front-loaded with the main action, no redundancy. Every sentence adds value.
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 single parameter with full schema coverage and presence of an output schema, the description adequately explains the tool's operation. Missing details like error handling or rate limits, but not critical for basic usage.
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 already describes the 'address' parameter as hex with or without 0x prefix. The description repeats 'Params: address (hex)' adding minimal new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a reverse-lookup of an Ethereum address to its ENS name, specifying the on-chain mechanism via Universal Resolver. This distinguishes it from siblings like eth_resolve_ens which presumably does forward resolution.
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 reverse lookups, but does not explicitly state when to use this tool versus alternatives such as eth_resolve_ens or when to avoid it (e.g., addresses without ENS). The purpose is clear enough from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_register_agent_8004AInspect
Build transaction data for registering an AI agent via ERC-8004 Agent Registry. ERC-8004 defines an on-chain registry for autonomous AI agents with capabilities, metadata URI, and owner tracking. Returns the ABI-encoded function selector and parameter breakdown for registerAgent(string,string[],string). The caller must sign and submit the transaction to the registry contract.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | Human-readable agent name | |
| capabilities | Yes | List of capability strings (e.g. ['nlp', 'code-generation', 'web-search']) | |
| metadata_uri | Yes | IPFS or HTTPS URI pointing to full agent metadata JSON |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It clarifies the tool builds transaction data (not submitting), which is a key safety signal. However, it does not disclose potential errors, what happens if agent already exists, or that it is a write operation requiring gas.
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 concise with two main sentences plus a call to action. It is front-loaded with the purpose and context, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers return type and the next steps for the caller. It could mention the registry contract address, but overall 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?
Schema coverage is 100%, and the description adds the function signature and standard context but does not provide significant extra meaning beyond the existing parameter 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 clearly states it builds transaction data for registering an AI agent via ERC-8004, specifying the function and parameters. It distinguishes this from sibling tools like eth_lookup_agent_8004 by focusing on registration.
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 the caller must sign and submit the transaction, but does not explicitly differentiate when to use this vs other tools, nor does it mention prerequisites like gas costs or registry contract address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_resolve_ensBInspect
Resolve an ENS name to an Ethereum address. Tries the ENS Universal Resolver on-chain via eth_call (resolve(bytes,bytes) at 0xc0497E381f536Be9ce14B0dD3817cBcAe57d2F62). Falls back to the OnchainKit ENS API as a secondary source. Params: name (e.g. 'vitalik.eth').
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ENS name to resolve (e.g. 'vitalik.eth') |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the on-chain call via eth_call and fallback to OnchainKit API, offering some behavioral insight. However, it does not state whether the operation is read-only, expected behavior on failure (e.g., invalid name), or any side effects.
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: the first clearly states the purpose, and the second adds relevant implementation details and parameter format. 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 tool with one parameter and an output schema, the description is largely complete. It explains how resolution works and the fallback mechanism. Missing are error scenarios and confirmation of return format (though output schema likely handles this).
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 a clear description for the 'name' parameter. The description repeats this example ('vitalik.eth') but adds no additional 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?
Description clearly states 'Resolve an ENS name to an Ethereum address', specifying verb, resource, and outcome. It provides implementation details (on-chain call with fallback API) that differentiate it from siblings like eth_lookup_ens, but the exact distinction is not explicit.
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 on when to use this tool versus alternatives such as eth_lookup_ens. The description does not provide when/when-not conditions or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eth_send_raw_transactionAInspect
Broadcast a pre-signed Ethereum transaction via eth_sendRawTransaction. Params: raw_tx (hex-encoded RLP-signed transaction, with or without 0x prefix). Returns the resulting transaction hash as plain text. Use eth_encode_function + eth_estimate_gas + an external signer (or tenzro_signTransaction with chain_id matching the target EVM chain) to build the raw_tx.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_tx | Yes | Signed RLP-encoded transaction as hex (0x-prefixed). Build with the tenzro_signTransaction helper or any EIP-1559/legacy signer. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Underlying response payload verbatim. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the broadcast action and return type but does not detail side effects like irreversibility or failure modes. Still adds meaningful behavioral context beyond basic function.
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 wasted words, front-loaded with core purpose and essential details.
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 (single param, output schema present), description covers purpose, parameter construction, and return value fully. It is complete for a well-understood blockchain 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 coverage is 100%, but description adds clarity by specifying 'hex-encoded RLP-signed transaction, with or without 0x prefix' and guiding how to construct it, exceeding schema explanation.
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?
Clearly states 'Broadcast a pre-signed Ethereum transaction via eth_sendRawTransaction' and mentions return value. Distinct from sibling tools like eth_call_contract and eth_estimate_gas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the prerequisite steps (eth_encode_function + eth_estimate_gas + signer) and how to obtain raw_tx. Does not explicitly exclude cases but provides good context for appropriate use.
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.
Discussions
No comments yet. Be the first to start the discussion!