EVM MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_block and get_latest_block, and between get_contract_abi and read_contract/write_contract's ABI fetching. The descriptions help clarify, but an agent might occasionally hesitate between these pairs.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun or verb_noun_noun pattern throughout, such as get_balance, transfer_erc20, and sign_message. There are no deviations in style, making them predictable and easy to parse.
Tool Count3/5
With 25 tools, the count is on the high side for an MCP server, bordering on heavy. While the domain (EVM interactions) is broad, this many tools could overwhelm agents or lead to redundancy, though it covers many use cases.
Completeness5/5
The tool set provides comprehensive coverage for EVM operations, including token transfers, contract interactions, network queries, and wallet management. It supports full workflows from reading to writing, with no obvious gaps in the domain.
Average 4/5 across 25 of 25 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the specific lookup mechanism ('by block number or hash') which provides useful context beyond annotations, but doesn't describe rate limits, authentication needs, or what 'block details' actually includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with good annotations and full schema coverage, the description is minimally adequate. However, without an output schema, the description doesn't explain what 'block details' includes (transactions, timestamps, gas used, etc.), leaving the agent uncertain about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description mentions 'block number or hash' which aligns with blockIdentifier, and implies network selection, but adds no additional semantic context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('block details'), specifying it works 'by block number or hash'. It distinguishes from sibling 'get_latest_block' by requiring a specific identifier, but doesn't explicitly mention this distinction in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_latest_block' or 'get_transaction'. It doesn't mention prerequisites, error conditions, or typical use cases for retrieving block details versus other blockchain data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key behavioral traits: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable query. The description adds no behavioral context beyond this, such as rate limits, error conditions, or return format details. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, front-loading the core purpose ('Get ERC1155 token balance for an address'). It efficiently communicates the essential action without redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with rich annotations (readOnlyHint, idempotentHint) and full schema coverage, the description is minimally adequate. However, without an output schema, it doesn't explain return values (e.g., balance format, error responses), and it lacks usage context compared to siblings. This leaves gaps in fully guiding the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all parameters (e.g., contractAddress, tokenId, address, network). The description adds no additional semantic context beyond the schema, such as explaining ERC1155-specific nuances or format requirements. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('ERC1155 token balance for an address'), making the purpose immediately understandable. It distinguishes from siblings like 'get_balance' (likely for native tokens) and 'get_token_balance' (likely for ERC20 tokens) by specifying ERC1155, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_balance' or 'get_token_balance'. It doesn't mention prerequisites, such as needing a valid contract address or network, or specify use cases like checking NFT holdings. This leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the agent knows this is a safe, read-only operation that may query external data. The description adds no behavioral context beyond what annotations provide - no information about rate limits, network availability, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single clear sentence that states exactly what the tool does with zero wasted words. It's perfectly front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with good annotations and full schema coverage, the description is minimally adequate. However, without an output schema, the description doesn't explain what 'latest block' data will be returned (block number, timestamp, transactions, etc.), leaving a gap in understanding the tool's complete behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the single optional 'network' parameter. The description adds no parameter information beyond what's in the schema, so it meets but doesn't exceed the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('latest block from the network'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_block', which likely retrieves specific blocks by number/hash rather than the latest one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_block' and 'get_chain_info' available, there's no indication of when this specific 'latest block' retrieval is preferred over other block-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description doesn't need to repeat these. It adds minimal context by specifying the lookup mechanism ('by transaction hash'), but doesn't elaborate on rate limits, error handling, or response format, which could be helpful given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Get transaction details by transaction hash') contributes directly to understanding the tool's function, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations provide safety and idempotency info, and the schema fully covers parameters, the description is adequate for a read-only lookup tool. However, with no output schema and multiple similar sibling tools (e.g., get_transaction_receipt), it could benefit from more context about return values or differentiation to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents both parameters (txHash and network). The description mentions 'by transaction hash' which aligns with the txHash parameter but adds no additional semantic meaning beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get transaction details') and resource ('by transaction hash'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'get_transaction_receipt' or 'get_block', which would require a more specific distinction to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_transaction_receipt' or 'get_block' from the sibling list. It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds context about using the configured wallet, which clarifies authentication needs beyond annotations. It doesn't mention rate limits or specific destructive consequences, but aligns with annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: first states purpose and scope, second clarifies the wallet mechanism. Front-loaded with essential information, no redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with no output schema, the description is reasonably complete—it covers what the tool does and the wallet context. However, it lacks details on return values (e.g., transaction hash) or error cases, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples for 'network' beyond the default). Baseline 3 is appropriate since the schema fully covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Transfer native tokens') and resource (ETH, MATIC, etc.), with the specific mechanism 'to an address' and 'Uses the configured wallet.' It distinguishes from sibling tools like transfer_erc20 by specifying native tokens, but doesn't explicitly contrast with other tools beyond that implied difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for transferring native tokens (vs. ERC20 tokens via transfer_erc20), but doesn't explicitly state when to use this tool versus alternatives like write_contract for more complex transfers or get_balance for checking balances. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide key behavioral hints (destructiveHint: true, idempotentHint: false, readOnlyHint: false), covering safety and idempotency. The description adds minimal context ('Uses the configured wallet'), which hints at authentication needs but doesn't elaborate on rate limits, error handling, or transaction specifics. It doesn't contradict annotations, so a baseline score is appropriate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and essential context. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive transfer operation), rich annotations, and 100% schema coverage, the description is adequate but minimal. It lacks details on output (no schema provided), error cases, or network defaults beyond schema hints. For a high-stakes tool, more context on behavior or results would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the input schema (e.g., tokenAddress as contract address, amount in token units). The description adds no additional parameter semantics beyond the schema, so it meets the baseline for high coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Transfer ERC20 tokens') and resource ('to an address'), distinguishing it from sibling tools like transfer_native (for native tokens) and approve_token_spending (for approvals). It precisely identifies the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'Uses the configured wallet,' which suggests it's for sending tokens from a pre-configured source. However, it doesn't explicitly state when to use this vs. alternatives like transfer_native or write_contract, nor does it mention prerequisites (e.g., wallet setup, token approvals). The guidance is clear but lacks sibling differentiation and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior, so the description adds minimal value beyond reinforcing the query nature. It does not disclose additional traits like rate limits, authentication needs, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core purpose and efficiently explaining the utility without redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and full schema coverage, the description is mostly complete for a read-only query tool. However, the lack of an output schema means it could benefit from hinting at return values, such as allowance amount or units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no extra meaning beyond implying the tool checks delegated spending, which aligns with but does not expand upon the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check the allowance') and resource ('granted to a spender for a token'), distinguishing it from siblings like get_balance or get_token_balance by focusing on delegated spending permissions rather than ownership balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('how much of a token an address can spend on your behalf'), but does not explicitly mention when not to use it or name specific alternatives among siblings, such as get_balance for ownership checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no additional behavioral context (e.g., rate limits, auth needs, or return format), but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes to clarifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, rich annotations, and 100% schema coverage, the description is mostly complete. However, with no output schema, it could benefit from mentioning the return value format (e.g., balance in wei or ether), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no extra parameter details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('native token balance for an address'), distinguishing it from siblings like get_token_balance (ERC20 tokens) or get_erc1155_balance (NFTs). It explicitly mentions the token types (ETH, MATIC, etc.) to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'native token balance' and listing examples (ETH, MATIC), which helps differentiate it from get_token_balance for ERC20 tokens. However, it does not explicitly state when not to use it or mention alternatives like get_erc1155_balance for NFTs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds useful context by specifying the exact gas price types returned (base fee, standard, fast), which isn't in annotations. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with no wasted words. Every element (verb, resource, data specifics, target) earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter), rich annotations covering safety and scope, and no output schema, the description is mostly complete. It specifies the gas price types returned, but could benefit from mentioning default behavior (e.g., network defaults to Ethereum mainnet, as noted in schema) or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'network' fully documented in the schema. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'current gas prices', specifying the exact data returned (base fee, standard, and fast) and the target (for a network). It distinguishes from siblings like get_block or get_chain_info by focusing specifically on gas price metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when gas prices are needed for a network, but provides no explicit guidance on when to use this tool versus alternatives (e.g., no mention of sibling tools like get_chain_info that might include gas data). It lacks when-not-to-use scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying the scope ('ERC721 NFT' and 'metadata URI'), which isn't in annotations, but doesn't detail rate limits, auth needs, or response 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose without unnecessary words. It earns its place by clearly stating what the tool does in minimal terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 2 required), rich annotations covering safety and behavior, and 100% schema coverage, the description is mostly complete. However, without an output schema, it could benefit from hinting at return values like metadata structure, but the annotations and schema provide sufficient context for a read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description mentions 'ERC721 NFT' and 'metadata URI', which adds context about the resource but doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'information about an ERC721 NFT including metadata URI', which is specific and distinguishes it from sibling tools like get_balance, get_contract_abi, or get_erc1155_balance that target different resources or data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving NFT metadata but provides no explicit guidance on when to use this tool versus alternatives like read_contract for custom queries or get_erc1155_balance for other token standards. It lacks when-not scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds no further behavioral context (e.g., rate limits, authentication needs, or return format), but it does not contradict annotations, so it meets the lower bar with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, rich annotations (covering safety and idempotency), and full schema coverage, the description is mostly complete. However, the lack of an output schema means the return value (e.g., balance format) is undocumented, leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for address, tokenAddress, and network parameters. The description adds no additional meaning beyond the schema (e.g., format examples or edge cases), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('ERC20 token balance for an address'), distinguishing it from siblings like get_balance (likely for native tokens) or get_erc1155_balance (for different token standards). It precisely identifies the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ERC20 token balances, but does not explicitly state when to use this tool versus alternatives like get_balance (for native tokens) or get_allowance (for spending approvals). No guidance on prerequisites or exclusions is provided, leaving the context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds no behavioral context beyond what annotations declare (e.g., no rate limits, error conditions, or performance traits). With annotations doing the heavy lifting, the description meets the baseline but adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Lookup the ENS name for an Ethereum address') and adds clarifying context ('reverse resolution') without redundancy. Every word earns its place, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple lookup), rich annotations (covering safety and idempotency), and high schema coverage, the description is mostly complete. However, the lack of an output schema means the description could benefit from hinting at return values (e.g., ENS name or null). It's adequate but has a minor gap in output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('address' and 'network') fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides (e.g., no format examples for 'address' or default values beyond schema's note). Baseline score of 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Lookup the ENS name') and resource ('for an Ethereum address'), with the parenthetical 'reverse resolution' distinguishing it from the sibling 'resolve_ens_name' tool (which presumably does forward resolution from name to address). This precise verb+resource pairing and explicit sibling differentiation earns the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'reverse resolution,' which helps differentiate from 'resolve_ens_name.' However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when you have an address vs. a name) or any prerequisites. The context is clear but not comprehensive enough for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about network behavior ('ENS resolution works best on Ethereum mainnet') in the schema, which is useful for understanding performance characteristics, though it doesn't detail rate limits or specific 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that states the tool's purpose without any fluff or redundancy. It's front-loaded and efficiently communicates the core functionality, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations cover safety and idempotency, and the schema fully documents parameters, the description is reasonably complete for a read-only query tool. However, with no output schema, it doesn't explain return values (e.g., address format or error responses), leaving a minor gap in full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters (ensName and network). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('resolve') and target resource ('ENS name to an Ethereum address'), distinguishing it from sibling tools like 'lookup_ens_address' (which might be the inverse operation) and other Ethereum query tools. It precisely communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ENS resolution but doesn't explicitly state when to use this tool versus alternatives like 'lookup_ens_address' or other address-related tools. No guidance is provided on prerequisites, error conditions, or specific scenarios where this tool is preferred over others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation, the description clarifies that this is a prerequisite for DeFi interactions and mentions the ability to revoke approval (using '0' amount). It doesn't cover rate limits or authentication needs, but provides practical deployment context that annotations lack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the core function, the second provides usage context. There's no wasted language, and the most critical information (what the tool does) appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with good annotations and complete schema coverage but no output schema, the description provides adequate context about the tool's purpose and usage. It could be more complete by mentioning what happens after approval (e.g., transaction submission, gas costs, or typical next steps), but covers the essential why and when of using this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema, though it does reinforce the purpose of the 'amount' parameter by mentioning revocation capability. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Approve a spender to spend tokens on your behalf') and identifies the resource (tokens). It distinguishes this from sibling tools like 'transfer_erc20' or 'write_contract' by focusing specifically on token spending authorization rather than transfers or general contract interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Required before interacting with DEXes, lending protocols, etc.'), giving practical examples. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools, such as using 'get_allowance' to check existing approvals first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, open-world, idempotent, and non-destructive traits, so the description doesn't need to repeat these. It adds value by specifying the exact information returned (chain ID, block number, RPC endpoint), which isn't in annotations, providing useful context for the agent about output content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key outputs. Every word contributes essential information without redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema), rich annotations, and clear purpose, the description is mostly complete. It could slightly improve by mentioning the default network more explicitly, but it adequately covers the tool's function and output scope for the agent's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'network' well-documented in the schema. The description doesn't add further parameter details beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get information about') and resource ('an EVM network'), listing the exact data returned (chain ID, current block number, RPC endpoint). It distinguishes from siblings like 'get_supported_networks' (which lists networks) and 'get_block' (which gets block details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving network metadata, with context from the parameter description suggesting it's for querying specific networks. However, it doesn't explicitly state when to use this versus alternatives like 'get_supported_networks' for listing available networks or 'get_block' for detailed block data, though the purpose differentiation helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context by specifying it returns 'all supported' networks, which clarifies the scope beyond what annotations indicate, though it doesn't detail output format 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with no wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is complete enough for basic use. It specifies what is retrieved ('all supported EVM networks'), but could benefit from mentioning the return format (e.g., list of network names or IDs) to enhance clarity, though annotations help cover behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not need to add parameter details, and it appropriately focuses on the tool's purpose without redundancy, earning a baseline score for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of all supported EVM networks' clearly states the action ('Get a list') and resource ('all supported EVM networks'). It distinguishes from siblings like get_chain_info or get_block by specifying the scope is about network support rather than chain metadata or block data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to know which EVM networks are supported, but does not explicitly state when to use this tool versus alternatives like get_chain_info or provide exclusions. It offers basic context but lacks detailed guidance on specific scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it reveals this is a polling operation (not a one-time check) and specifies it waits until confirmation is achieved. This goes beyond what annotations provide about safety characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two clear sentences that front-load the core purpose. Every word earns its place: first sentence states what it does, second sentence explains how it works. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polling tool with good annotations and full parameter documentation, the description provides adequate context about its behavior. However, without an output schema, it doesn't describe what the tool returns (e.g., receipt data, confirmation status, error conditions), leaving some uncertainty about the result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all parameters are well-documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions (txHash, confirmations with default, network with default). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Wait for a transaction to be confirmed') and mechanism ('Polls the network until confirmation'), distinguishing it from siblings like get_transaction (which retrieves transaction data without waiting) or get_transaction_receipt (which gets confirmation status without polling).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (after submitting a transaction, when you need to wait for confirmation), but doesn't explicitly state when NOT to use it or name specific alternatives like get_transaction_receipt for checking status without waiting. It provides clear intent but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 agent knows this is a safe, repeatable read operation. The description adds valuable context beyond annotations: the API key requirement, network support (30+ EVM networks), and the verification constraint. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each earning its place: purpose, usage context, prerequisites, and scope. Front-loaded with the core action, no wasted words, and structured logically from what to why to constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with good annotations and full schema coverage, the description provides excellent contextual completeness: purpose, usage guidelines, prerequisites, and scope. The only minor gap is lack of output details (no output schema), but the description implies ABI return, which is reasonable for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description doesn't add specific parameter semantics beyond what the schema provides, but it reinforces the contractAddress focus and network flexibility. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('fetch') and resource ('contract's full ABI'), specifies the source ('from Etherscan/block explorers'), and distinguishes it from siblings by focusing on ABI retrieval rather than balances, transactions, or contract interactions. It's specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('to understand verified contracts before interacting') and provides context about prerequisites ('Requires ETHERSCAN_API_KEY') and limitations ('Works best with verified contracts on block explorers'). It clearly differentiates this read-only tool from write operations like write_contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond what annotations provide. While annotations indicate read-only, open-world, idempotent, and non-destructive behavior, the description clarifies the specific purpose ('check if a transaction has been confirmed') and what data is returned ('confirmation status, gas used, logs'). This helps the agent understand the tool's functional scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first defines what the tool does, and the second provides usage guidance. There's no wasted language, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) and full parameter documentation in the schema, the description provides adequate context. However, without an output schema, the description could benefit from more detail about the return format, though the mention of specific data elements ('confirmation status, gas used, logs') partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents both parameters (txHash and network). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation without providing additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get transaction receipt') and resource ('transaction'), with explicit details about what information is retrieved ('confirmation status, gas used, logs'). It distinguishes from sibling tools like 'get_transaction' by focusing on receipt-specific data rather than transaction details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to check if a transaction has been confirmed.' This clearly differentiates it from alternatives like 'get_transaction' (which might show pending transactions) and 'wait_for_transaction' (which actively waits for confirmation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the performance benefit ('reduces latency and RPC usage'), mentions the underlying implementation ('Uses the Multicall3 contract'), and notes network compatibility ('deployed on all major networks'). While annotations cover safety (readOnlyHint, idempotentHint), the description provides practical implementation details that help the agent understand when this optimization 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: the first sentence states the core functionality, the second explains benefits, and the third provides implementation context and use cases. Every sentence adds value with zero wasted words, and the structure moves from general to specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (readOnlyHint, idempotentHint) and comprehensive schema coverage, the description provides excellent contextual completeness. It explains the tool's optimization purpose, implementation details, and ideal use cases. The only minor gap is lack of output format explanation (no output schema exists), but the annotations sufficiently indicate safe read behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters thoroughly. The description doesn't add specific parameter semantics beyond what's in the schema, but it contextually explains the purpose of batching calls, which helps understand the 'calls' parameter's role. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('batch multiple contract read calls') and resources ('single RPC request'), distinguishing it from siblings like read_contract (single call) and write_contract (write operations). It explicitly mentions it's for read operations only, which differentiates it from write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'when querying multiple functions' and for specific use cases like 'portfolio analysis, price aggregation, and querying multiple contract states efficiently.' It implicitly distinguishes from read_contract (single calls) and write_contract (write operations) by focusing on batch read optimization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: automatic ABI fetching with fallback mechanisms, API key requirement, and network defaults. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first states core purpose, second explains ABI fetching behavior, third provides usage guidance. Front-loaded with essential information, appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description is mostly complete. It explains the tool's behavior, usage context, and prerequisites. The main gap is lack of output format details (no output schema), but annotations provide safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal semantic context (e.g., 'falls back to common functions'), but doesn't significantly enhance understanding beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('call read-only functions', 'query contract state and data') and distinguishes it from siblings by emphasizing its read-only nature for smart contracts, unlike write_contract or transfer tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('to query contract state and data') and distinguishes it from alternatives by specifying it's for read-only functions, unlike write_contract which is for write operations. Also mentions prerequisites (ETHERSCAN_API_KEY for auto-fetching).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false, but the description adds valuable context: it explains the signature's verification scope ('on-chain or off-chain') and mentions the wallet configuration dependency. However, it doesn't detail potential side effects like gas costs or security implications, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by use cases and verification details in two efficient sentences. Every phrase adds value without redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (signing operation with cryptographic implications), no output schema, and rich annotations, the description is mostly complete. It covers purpose, usage, and verification but lacks details on error cases or response format, which could enhance completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'message' fully documented in the schema. The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Sign an arbitrary message') and resource ('using the configured wallet'), distinguishing it from sibling tools like sign_typed_data (which handles structured data) and other read/write operations. It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three use cases: 'authentication (SIWE), meta-transactions, and off-chain signatures,' providing clear guidance on when to use this tool. It also implicitly distinguishes it from sign_typed_data by focusing on arbitrary messages rather than structured data, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies the signature follows EIP-712 standard, mentions use cases, and clarifies the wallet is 'configured' (implying setup requirements). Annotations cover idempotency (true) and non-destructive nature (false), but the description provides practical application context that helps the agent understand when this tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences. The first sentence states the core purpose, and the second sentence provides essential context about the standard and use cases. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cryptographic signing tool with good annotations and full schema coverage, the description provides excellent context about use cases and the EIP-712 standard. The main gap is lack of output information (no output schema), but the description compensates well by explaining what the tool produces ('signature follows the EIP-712 standard').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, so it meets the baseline expectation without providing additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Sign structured data'), the standard used ('EIP-712'), and the resource ('using the configured wallet'). It distinguishes this tool from sibling tools like 'sign_message' by specifying it's for structured data following a particular standard rather than plain messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists multiple use cases ('gasless transactions, meta-transactions, permit signatures, and protocol-specific signatures'), providing clear guidance on when to use this tool. It differentiates from 'sign_message' by specifying EIP-712 structured data signing rather than general message signing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it discloses the automatic ABI fetching capability (with ETHERSCAN_API_KEY requirement), wallet configuration requirements, and the focus on verified contracts. While annotations already indicate destructiveHint=true and readOnlyHint=false, the description provides practical implementation details that help the agent understand execution requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: first states core functionality, second explains ABI auto-fetching, third specifies prerequisites. Each sentence adds distinct value with zero redundancy. The information is front-loaded with the primary purpose stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex destructive tool with no output schema, the description provides good context about requirements (wallet, API key), behavior (ABI auto-fetching), and scope (verified contracts, write functions). It could be more complete by mentioning transaction confirmation or gas handling, but covers the essential operational context given the annotations already indicate destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description mentions ABI auto-fetching (related to 'abiJson') and wallet requirements (implied for all operations), but doesn't add significant parameter-specific semantics beyond what the schema provides. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Execute state-changing functions', 'call any write function') and resources ('on a smart contract'). It distinguishes from sibling tools like 'read_contract' by emphasizing write operations and from 'approve_token_spending' by being a general-purpose contract interaction tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to call any write function on verified contracts' establishes the primary use case. It also mentions prerequisites ('Requires wallet to be configured') and when not to use alternatives (implied by distinguishing from read operations). The sibling tool list shows clear alternatives like 'read_contract' for non-state-changing calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent operation. The description adds useful context by specifying that it retrieves the 'configured' wallet address, implying it returns the currently active wallet without modification. It doesn't contradict annotations but provides additional behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and followed by usage guidance. Every word earns its place without redundancy, making it highly efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with rich annotations (read-only, non-destructive, idempotent) and no output schema, the description is complete enough. It clearly states what the tool does and when to use it. A minor deduction because it doesn't specify the return format (e.g., string address), but annotations cover safety aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, but it implicitly clarifies that no inputs are required to get the configured wallet address. This aligns perfectly with the schema, earning a baseline score with slight bonus for contextual clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the address') and resource ('configured wallet'), distinguishing it from sibling tools that perform different operations like transfers, approvals, or balance checks. It precisely defines what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'to verify which wallet is active.' This provides clear context for its purpose, distinguishing it from alternatives like get_balance or get_transaction that serve different verification or information needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![evm-mcp-server MCP server](https://glama.ai/mcp/servers/chulanpro5/evm-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/chulanpro5/evm-mcp-server)

Score Badge

Copy to your README.md:

[![evm-mcp-server MCP server](https://glama.ai/mcp/servers/chulanpro5/evm-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/chulanpro5/evm-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chulanpro5/evm-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server