EVM MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear distinctions for most operations, but there are notable overlaps that could cause confusion. For example, get_token_balance and get_erc20_balance appear to serve the same purpose, and transfer_erc20 and transfer_token are redundant. However, descriptions help clarify specific use cases, such as differentiating between ERC20, ERC721, and ERC1155 token types.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., get_balance, transfer_erc20, read_contract), making them predictable and readable. Minor deviations exist, such as check_nft_ownership and is_contract, which use different verb styles but still fit the overall naming convention without causing significant confusion.
Tool Count3/5
With 28 tools, the count feels heavy for an EVM server, as many tools could be consolidated or generalized. While the domain is broad, the high number may overwhelm agents and lead to inefficiency. A more streamlined set of 15-20 tools would better balance coverage and usability.
Completeness4/5
The tool surface provides comprehensive coverage for EVM operations, including token interactions, contract reads/writes, and blockchain queries. Minor gaps exist, such as missing tools for advanced DeFi operations or event listening, but core workflows like transfers, balances, and contract interactions are well-covered, allowing agents to handle most common tasks effectively.
Average 3.4/5 across 28 of 28 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 6 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on November 26, 2025
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: whether it makes network calls, requires authentication, has rate limits, returns specific error types, or provides gas estimates in gwei/wei. For a tool that likely queries blockchain networks, this is a significant gap in transparency.
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 at 7 words. It's front-loaded with the core purpose and contains zero wasted words. Every word earns its place by clearly communicating the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of gas estimation (involving blockchain networks, transaction simulation, and unit conversions), the description is insufficient. With no annotations and no output schema, the description should provide more context about what the estimate represents (gas units, gwei/wei), typical use cases, and limitations. For a tool with 4 parameters and likely network dependencies, this is incomplete.
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 already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 tool's purpose: estimating gas cost for a transaction. It uses a specific verb ('estimate') and resource ('gas cost'), making it immediately understandable. However, it doesn't differentiate from potential sibling tools like 'write_contract' or 'transfer_eth' that might also involve gas estimation, keeping it from a perfect score.
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. It doesn't mention whether this should be used before executing transactions (like 'transfer_eth' or 'write_contract'), or how it relates to other gas-related operations. There's no explicit when/when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but lacks behavioral details: it doesn't specify if this is a read-only operation (implied by 'Get'), error handling (e.g., invalid block numbers), performance traits, or rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the tool returns (e.g., block data structure), error conditions, or dependencies like network connectivity. For a tool that likely returns complex blockchain data, this lack of context is a significant shortfall.
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 minimal value beyond the schema, as it only mentions 'block number' without elaborating on format or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate with additional insights.
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 ('a block'), specifying it's fetched by block number. It distinguishes from siblings like 'get_latest_block' by indicating retrieval via specific number rather than latest. However, it doesn't explicitly differentiate from other block-related tools (none in siblings), so it's not fully sibling-aware.
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., network availability), exclusions, or comparisons to siblings like 'get_latest_block' for real-time data. The description is purely functional without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions, rate limits, network behavior, or response format. For a read operation with no annotation coverage, this is a significant gap in transparency.
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's front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain operations and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, network defaults, or return values, which are crucial for an agent to use this tool effectively in 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 descriptions for all parameters in the input schema. The description adds no additional semantic context beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 the resource 'ERC20 token balance of an Ethereum address', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_token_balance' or 'get_token_balance_erc20', which likely serve overlapping functions, leaving some ambiguity about differentiation.
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 siblings like 'get_token_balance' and 'get_token_balance_erc20' present, there's no indication of differences in scope, token types, or use cases, leaving the agent without explicit or implied context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning whether it's read-only, requires authentication, has rate limits, or what the output format might be (e.g., block object details). This is inadequate for a tool that likely returns critical blockchain data.
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 front-loaded and wastes no space, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the tool returns (e.g., block hash, timestamp, transactions) or behavioral aspects like error handling, which are crucial for an EVM block query tool in a server with many blockchain-related siblings.
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?
The input schema has 100% description coverage, with the 'network' parameter clearly documented. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 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') and resource ('latest block from the EVM'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_block_by_number', which could retrieve blocks by specific numbers 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. For example, it doesn't mention using 'get_block_by_number' for historical blocks or 'get_chain_info' for broader network data, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires network access, has rate limits, returns cached or real-time data, or what format the balance is returned in. The description is minimal and lacks important operational context.
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 purpose without any wasted words. It's appropriately sized for a straightforward tool and gets directly to the point with clear subject-verb-object structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the balance is returned in (wei, ether, decimal), whether it supports ENS resolution for both addresses, error conditions, or how it differs from the similar 'get_erc20_balance' sibling. The minimal description leaves too many operational questions unanswered.
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 already fully documents all three parameters. The description doesn't add any additional meaning beyond what's in the schema descriptions - it doesn't explain parameter relationships, default behaviors, or provide examples of valid inputs beyond what the schema already specifies.
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 the resource 'balance of an ERC20 token for an address', making the purpose immediately understandable. It distinguishes from general 'get_balance' by specifying ERC20 tokens, but doesn't explicitly differentiate from the sibling 'get_erc20_balance' tool which appears to serve a similar function.
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_erc20_balance' or 'get_balance'. It doesn't mention prerequisites, error conditions, or when this specific tool is preferred over similar siblings in the toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe what a transaction receipt contains, whether it's a read-only operation (implied but not explicit), error conditions (e.g., invalid hash), rate limits, or authentication needs. For a tool with zero annotation coverage, this is insufficient.
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 with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple lookup tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a blockchain transaction receipt tool with no annotations and no output schema), the description is incomplete. It doesn't explain what a receipt includes (e.g., status, gas used), potential errors, or return format. For a tool that likely returns structured data, this leaves significant gaps in understanding its behavior and output.
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?
The description mentions 'by its hash', which aligns with the 'txHash' parameter in the schema. However, with 100% schema description coverage, the schema already documents both parameters ('txHash' and 'network') clearly. The description adds minimal value beyond the schema, meeting the baseline of 3 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 tool's purpose: 'Get a transaction receipt by its hash' specifies the verb ('Get'), resource ('transaction receipt'), and key identifier ('by its hash'). It distinguishes from sibling tools like 'get_transaction' (which likely returns transaction details rather than receipt) and 'get_block_by_number' (different resource). However, it doesn't explicitly differentiate from all siblings, keeping it at 4 rather than 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. It doesn't mention when this is appropriate (e.g., for confirming transaction completion) versus when to use 'get_transaction' or other siblings, nor does it specify prerequisites or exclusions. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits: this is a write/mutation operation (implied by 'transfer'), requires signing with a private key (hinted in schema but not in description), has security implications (private key handling), or potential transaction costs (gas fees).
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?
Extremely concise single sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial transaction tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after transfer (success/failure states), return values, error conditions, or security considerations, leaving significant gaps for agent understanding.
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%, providing detailed parameter documentation. The description adds no additional parameter semantics beyond what's in the schema, 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.
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') and resource ('ERC20 tokens'), specifying the destination ('to another address'). It distinguishes from siblings like 'transfer_eth' or 'transfer_nft' by specifying ERC20 tokens, but doesn't explicitly differentiate from 'transfer_token' which might be similar.
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?
No guidance on when to use this tool versus alternatives like 'transfer_eth' or 'transfer_token'. The description lacks context about prerequisites (e.g., needing a private key) or exclusions, leaving the agent to infer usage from parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral information. It states the action but doesn't disclose critical traits: that this is a write operation requiring private key, that it will incur gas fees, that it's irreversible once confirmed, or what the return value contains. The schema's security note about private key handling is helpful but not in the description itself.
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?
Extremely concise single sentence with zero wasted words. The description is front-loaded with the core action and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after invocation (transaction hash returned? wait for confirmation?), doesn't mention gas estimation needs, and provides no context about blockchain transaction characteristics. The schema covers parameters well, but the description lacks crucial behavioral 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 the schema fully documents all 5 parameters. The description adds no additional parameter information beyond what's already in the schema descriptions. Baseline 3 is appropriate when schema does all the parameter documentation work.
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') and resource ('ERC20 tokens'), specifying the destination ('to an address'). It distinguishes from siblings like transfer_eth (native currency) and transfer_erc1155 (different token standard), but doesn't explicitly differentiate from transfer_erc20 which appears to be a duplicate tool.
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?
No guidance on when to use this tool versus alternatives like transfer_eth or transfer_erc1155. The description doesn't mention prerequisites (e.g., needing token approval via approve_token_spending) or context for selecting this over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires network access, has rate limits, returns cached data, or what format the balance comes in (e.g., raw wei vs formatted). For a blockchain query tool, this leaves significant behavioral questions unanswered.
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 purpose without unnecessary words. It's appropriately sized for a straightforward query tool and gets directly to the point.
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 good schema coverage but no output schema, the description is minimally adequate. It states what the tool does but lacks important context about return format, network dependencies, and differentiation from similar sibling tools. The absence of annotations means the description should do more to explain behavioral characteristics.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline score of 3 reflects adequate coverage through the schema alone.
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 ('ERC20 token balance for an address'), making the purpose immediately understandable. It distinguishes from generic 'get_balance' and 'get_token_balance' siblings by specifying ERC20 tokens, though it doesn't explicitly differentiate from the similar 'get_erc20_balance' sibling tool.
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_erc20_balance' (which appears to serve a similar function) or 'get_token_balance' (which might handle different token types). There's no mention of prerequisites, error conditions, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get a list' implies a read-only operation, it doesn't specify whether this requires authentication, what format the list returns, whether it's cached or real-time, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 - a single sentence that communicates the essential purpose without any wasted words. It's front-loaded with the core action and resource. Every word earns its place, making this an excellent example of efficient documentation.
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-only tool with zero parameters and no output schema, the description provides the minimum viable information. However, without annotations or output schema, it should ideally specify what format the list returns (e.g., array of network names/IDs) or typical use cases. The description is adequate but leaves room for improvement regarding the return value.
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% (since there are no parameters to describe). The description appropriately doesn't waste space discussing nonexistent parameters. A baseline of 4 is appropriate for zero-parameter tools where the schema fully covers the parameter space.
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 ('list of supported EVM networks'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get_chain_info', but the specificity of 'supported EVM networks' provides reasonable distinction. The description avoids tautology by not just repeating the tool name.
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_chain_info' or other network-related tools. There's no mention of prerequisites, typical use cases, or when this tool would be preferred over other methods of obtaining network information. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool's purpose but lacks details on performance (e.g., rate limits, latency), error handling (e.g., invalid inputs), or output format (e.g., boolean, detailed response). This leaves gaps in understanding how the tool behaves beyond its 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core purpose without unnecessary words. It efficiently communicates the tool's function, making it easy to parse and understand immediately, with no wasted verbiage.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on usage context, behavioral traits, or output, leaving the agent to infer these from the schema alone. For a tool with no annotations or output schema, more completeness would be beneficial.
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 already documents all parameters thoroughly. The description adds no additional semantic context beyond implying the parameters are used for ownership verification. It doesn't clarify interactions between parameters or provide examples beyond what's in the schema, 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.
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 if an address owns') and resource ('a specific NFT'), distinguishing it from sibling tools like 'get_nft_balance' (which checks quantity) or 'get_nft_info' (which retrieves metadata). It precisely defines the tool's function without redundancy.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'get_nft_balance' for checking all NFTs owned by an address or 'resolve_ens' for address resolution, nor does it specify prerequisites like network connectivity. The description only states what it does, not when to choose it.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is used 'only for address derivation and is not stored' (via the schema description), which adds useful context about security and data handling. However, it lacks details on error handling, performance, or output format, leaving gaps in behavioral understanding.
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 front-loaded with the core action and resource, making it easy to parse quickly. Every part of the description earns its place by conveying 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?
Given the tool's low complexity (one parameter, no output schema) and the schema's high coverage, the description is minimally adequate. It covers the basic purpose but lacks context on output (e.g., address format) and error scenarios. With no annotations, it could benefit from more behavioral details 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?
The input schema has 100% description coverage, with the parameter 'privateKey' well-documented in the schema itself. The description does not add any additional meaning beyond what the schema provides, such as examples or edge cases. This meets the baseline for high schema coverage but does not enhance parameter understanding.
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 the target ('EVM address derived from a private key'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from its siblings, such as 'resolve_ens' (which also deals with addresses), though the focus on private key derivation is inherently distinct.
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. For example, it does not mention scenarios like key derivation for wallet setup or address verification, nor does it contrast with tools like 'resolve_ens' for address resolution. This leaves usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about response format, error handling, rate limits, authentication requirements, or whether it's read-only (though implied by 'Get'). For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 immediately communicates the core purpose. There's no wasted language or unnecessary elaboration. 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?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it doesn't explain what information is returned (no output schema exists), and with no annotations, it misses behavioral context. For a tool that presumably returns structured network data, the description should at least hint at 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?
The schema description coverage is 100%, with the single parameter 'network' fully documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('information about an EVM network'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'get_supported_networks' (which lists networks) and 'get_block_by_number' (which retrieves blockchain data). However, it doesn't specify what type of information is returned (e.g., chain ID, native currency, RPC URLs), which prevents a perfect score.
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 network information is needed, but provides no explicit guidance on when to choose this tool over alternatives like 'get_supported_networks' or when network details are required for other operations. The context is clear but lacks specific when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does at a high level. It doesn't disclose critical behavioral traits like transaction costs, gas requirements, confirmation times, error conditions, or what happens on failure. The description mentions ERC1155 characteristics but not tool-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences. The first sentence states the core purpose, and the second provides helpful context about ERC1155. No wasted words, though it could be slightly more front-loaded with critical behavioral information given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex transaction tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, gas implications, or security considerations beyond what's in parameter descriptions. The ERC1155 context is helpful but doesn't compensate for missing behavioral transparency.
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 already documents all parameters thoroughly. The description adds no additional parameter information beyond what's in the schema descriptions. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
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 ('Transfer') and resource ('ERC1155 tokens to another address'), with additional context about ERC1155 being a multi-token standard. It distinguishes from sibling tools like transfer_erc20, transfer_eth, and transfer_nft by specifying the exact token standard.
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 context through the ERC1155 explanation, but doesn't explicitly state when to use this tool versus alternatives like transfer_erc20 or transfer_nft. No explicit exclusions or prerequisites are mentioned, though the parameter descriptions provide some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it explains ERC1155's multi-token nature (balance can be >1), it doesn't describe the tool's behavior: whether it's a read-only query, what permissions are needed, potential rate limits, error conditions, or what format the balance returns. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two clear sentences. The first sentence states the core purpose, and the second adds important context about ERC1155's multi-token nature. There's no wasted language, and the information is front-loaded. It could potentially be slightly more structured but is efficient overall.
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 no annotations and no output schema, the description provides basic purpose and ERC1155 context but lacks behavioral details needed for complete understanding. It covers what the tool does but not how it behaves, what it returns, or potential limitations. For a tool with rich parameter schema but no other structured data, the description is minimally adequate but has clear gaps.
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 already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions ERC1155 context generally but doesn't provide additional semantic details about parameter usage, constraints, or relationships. Baseline 3 is appropriate when schema does complete documentation.
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 balance'), resource ('ERC1155 token ID'), and target ('owned by an address'). It distinguishes from siblings like 'get_nft_balance' by specifying ERC1155 tokens and explaining their multi-token nature. The explanation about ERC1155 allowing multiple tokens of the same ID provides important differentiation.
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 context by specifying ERC1155 tokens, but doesn't explicitly state when to use this tool versus alternatives like 'get_nft_balance', 'get_erc20_balance', or 'get_token_balance'. It mentions ERC1155's unique multi-token capability, which hints at usage scenarios, but lacks explicit guidance on tool selection among the many balance-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool does (retrieves a metadata URI) but doesn't disclose behavioral traits like whether it's a read-only operation, potential rate limits, error conditions, or what happens if the token doesn't exist. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that each add value. The first sentence states the core purpose, and the second explains what the URI typically contains. There's no wasted text, though it could be slightly more front-loaded with usage guidance.
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 3 parameters with full schema coverage but no annotations and no output schema, the description is minimally adequate. It explains the purpose and typical output format, but doesn't address behavioral aspects or provide usage guidance relative to siblings. For a read operation with good schema documentation, it meets basic needs but has clear gaps.
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 already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 metadata URI') and resource ('for an ERC1155 token'), and distinguishes it from siblings by specifying it's for the ERC1155 standard (unlike get_nft_info or get_token_info which might handle other token types). It also explains what the URI typically contains, adding useful context.
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 by mentioning the ERC1155 standard and typical URI content, but doesn't explicitly state when to use this tool versus alternatives like get_nft_info or get_token_info. It provides some context but lacks clear guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states what the tool does, it lacks important behavioral details: it doesn't specify what happens with invalid addresses, whether ENS resolution is performed internally, what the return format looks like (boolean, object with details), or any rate limits/authentication requirements. For a tool with zero annotation coverage, this represents significant gaps.
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 immediately communicates the core purpose without any fluff or redundant information. It's appropriately sized for a straightforward classification 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more complete context. It doesn't explain what the tool returns (crucial for a classification tool), doesn't mention error handling, and provides minimal behavioral transparency. For a tool with 2 parameters and no structured output documentation, the description is insufficiently 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?
The schema description coverage is 100%, with both parameters well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions (address format examples, network defaults). This meets the baseline of 3 for high schema coverage situations 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 ('Check if') and the target resource ('an address is a smart contract or an externally owned account'), using precise terminology that distinguishes it from sibling tools like get_balance or resolve_ens. It directly communicates the binary classification purpose 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 when needing to determine address type, but provides no explicit guidance on when to use this tool versus alternatives like resolve_ens (which handles ENS resolution) or check_nft_ownership (which checks NFT status). There's no mention of prerequisites, error conditions, or typical use cases beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits like error handling (e.g., for invalid names), performance characteristics, rate limits, authentication needs, or what happens on different networks. 'Resolve' suggests a lookup operation, but details are missing.
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 zero wasted words. Every word earns its place by directly contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values (e.g., address format, null for unresolved names), error conditions, or network dependencies hinted in the schema. For a lookup tool with potential complexity across networks, more context is needed.
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 both parameters. The description adds no additional meaning beyond what's in the schema (e.g., no examples of resolution outcomes or network-specific behaviors). Baseline 3 is appropriate as the schema handles parameter documentation.
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'), using precise terminology. It directly distinguishes this tool from all sibling tools, which involve token operations, transfers, contract interactions, or blockchain data queries rather than ENS resolution.
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 context (converting ENS names to addresses) but provides no explicit guidance on when to use this tool versus alternatives. There are no sibling tools for ENS resolution, so differentiation isn't needed, but it doesn't mention prerequisites like network availability or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not behavioral traits like transaction finality, gas handling, error conditions, or what happens on failure. It mentions 'SECURITY' in the schema but not in the description itself.
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?
Single sentence with zero waste, front-loading the core purpose. Every word earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk transaction tool with no annotations and no output schema, the description is inadequate. It lacks critical behavioral context like gas estimation, transaction confirmation, error handling, or security warnings beyond what's buried in schema parameter descriptions.
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 additional parameter semantics beyond what's in the schema, meeting the baseline for high 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 ('transfer') and resource ('native tokens (ETH, MATIC, etc.)') with destination ('to an address'). It distinguishes from siblings like transfer_erc20, transfer_nft, and transfer_token by specifying native tokens only.
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, but doesn't explicitly state when to use this vs. alternatives like transfer_erc20 or transfer_token. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool retrieves balances but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or response format. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 key information ('Get the native token balance') without any wasted words. It's appropriately sized for the tool's simplicity and gets straight to the point.
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 low complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose but lacks details on behavioral aspects like return values or error cases. Without annotations or output schema, the description should do more to compensate, but it's minimally viable for a simple read 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%, so the schema fully documents the parameters (address and network). The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 action ('Get') and resource ('native token balance for an address'), specifying it's for native tokens like ETH or MATIC. It distinguishes from siblings like get_erc20_balance or get_nft_balance by focusing on native tokens, making the purpose specific and well-differentiated.
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 checking native token balances, but doesn't explicitly state when to use this tool versus alternatives like get_erc20_balance or get_token_balance. It provides some context by mentioning token types, but lacks explicit guidance on exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the return type ('count of NFTs') but doesn't disclose behavioral traits like error conditions, rate limits, authentication needs, or whether it's a read-only operation (though implied by 'Get'). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 sentences, front-loaded with core purpose, zero waste. First sentence states what it does, second clarifies what it returns vs. doesn't. Every sentence earns its place by adding clarity.
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 operation with 3 parameters, 100% schema coverage, and no output schema, the description is adequate but incomplete. It lacks output format details (e.g., integer count, error responses) and behavioral context (e.g., network defaults, error handling). With no annotations, it should do more to compensate.
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 fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples not in schema). Baseline 3 is appropriate when 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 the total number of NFTs owned'), the resource ('by an address from a specific collection'), and distinguishes from siblings by specifying 'returns the count of NFTs, not individual token IDs' (differentiating from tools like get_nft_info or check_nft_ownership that might return different 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 context through 'from a specific collection' and clarifies what it returns vs. doesn't return, but doesn't explicitly state when to use this tool vs. alternatives like get_erc1155_balance or check_nft_ownership. No explicit 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.
Behavior2/5
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 mentions what information is retrieved (collection name, symbol, token URI, owner) but does not disclose behavioral traits such as rate limits, error handling, data freshness, or whether it requires authentication. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 and lists key data points. There is zero waste, and every word earns its place by clarifying the scope and output without redundancy.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and output data types, but lacks details on behavioral aspects and does not compensate for the missing output schema, leaving the agent unsure of the exact 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%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain parameter interactions or provide examples not in the schema). 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 ('Get detailed information') and resource ('specific NFT (ERC721 token)'), specifying the exact type of token. It distinguishes from siblings like get_nft_balance (which checks ownership quantity) or get_erc1155_token_uri (which handles a different token standard), making the purpose specific and differentiated.
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 querying NFT metadata and ownership, but does not explicitly state when to use this tool versus alternatives like get_token_info (for general tokens) or check_nft_ownership (for ownership verification). It provides some context but lacks explicit guidance on exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what data is included (sender, recipient, value, data) without disclosing behavioral aspects like error handling, rate limits, authentication requirements, or whether this is a read-only operation. It provides basic output content but misses critical operational context.
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 directly convey purpose and scope without any wasted words. It's front-loaded with the core functionality and efficiently lists included data points.
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 operation with 100% schema coverage but no annotations or output schema, the description adequately covers purpose and output content but lacks behavioral transparency and usage differentiation. It's minimally viable but has clear gaps in operational 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 the schema already fully documents both parameters (network and txHash). The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score 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 detailed information') and resource ('about a specific transaction by its hash'), with explicit differentiation from siblings like get_transaction_receipt (which focuses on receipt data) and get_block_by_number (which focuses on blocks). It precisely identifies the tool's scope.
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 transaction details are needed, but provides no explicit guidance on when to use this tool versus alternatives like get_transaction_receipt (for receipt-specific data) or get_latest_block (for block context). It lacks when-not-to-use instructions or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves 'comprehensive information' but does not specify response format, potential rate limits, authentication needs, or error conditions. For a read operation with no annotation coverage, this leaves significant behavioral gaps.
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 two sentences: the first states the purpose and key data points, the second provides usage context. Every sentence adds value with zero waste, making it appropriately sized and front-loaded.
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 no annotations and no output schema, the description adequately covers the tool's purpose and basic usage but lacks details on behavioral traits (e.g., response format, error handling) and does not explain return values. For a read tool with 2 parameters, it is minimally viable but has clear gaps 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%, so the schema already fully documents both parameters (network and tokenAddress). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when 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 comprehensive information') and resource ('ERC20 token'), listing key data points like name, symbol, decimals, total supply, and metadata. It distinguishes from siblings by focusing on token metadata analysis rather than balances (e.g., get_token_balance) or transfers (e.g., transfer_erc20).
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 ('to analyze any token on EVM chains'), but does not explicitly state when not to use it or name alternatives. It implies usage for metadata retrieval rather than balance checking or transaction operations, though no explicit exclusions are given.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes key behavioral traits: it's a write operation (implied by 'Transfer'), requires authentication ('private key of the current owner'), and involves transaction signing. It also mentions security context about private key handling. However, it doesn't cover potential failure modes, gas requirements, or confirmation times.
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 that each earn their place. The first sentence states the core purpose, and the second adds crucial behavioral context about authentication requirements. There's zero wasted language or 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 write operation with no annotations and no output schema, the description provides good coverage of the essential context: what the tool does, authentication requirements, and security considerations. However, it doesn't mention what happens on success/failure, return values, or gas/network fee implications, which would be helpful given the complexity of blockchain transactions.
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?
The schema has 100% description coverage, so all parameters are well-documented in the schema itself. The description adds minimal parameter semantics beyond the schema - it mentions the private key requirement but doesn't elaborate on parameter relationships or usage patterns. The baseline score of 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 specific action ('Transfer an NFT'), resource type ('ERC721 token'), and direction ('from one address to another'). It distinguishes this tool from sibling tools like transfer_erc20, transfer_erc1155, and transfer_eth by specifying the NFT/ERC721 token type.
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 about when to use this tool by stating it's for NFT transfers and mentioning the private key requirement. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like transfer_erc1155 for other token types, though the sibling list shows those alternatives exist.
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?
With no annotations provided, the description carries full burden and does well by disclosing critical behavioral traits: it modifies blockchain state, requires gas payment, and needs transaction signing. It also mentions the private key is used only for signing and not stored, addressing security concerns. However, it doesn't cover potential failure modes, transaction confirmation times, or gas estimation 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 perfectly concise with two sentences that each earn their place: the first states the core purpose, and the second covers critical behavioral requirements. It's front-loaded with the main action and wastes no words.
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 state-changing tool with no annotations and no output schema, the description does well by covering the mutation nature, gas requirements, and signing needs. However, it doesn't describe what the tool returns (e.g., transaction hash, receipt) or error conditions, which would be helpful given the absence of an output schema.
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 already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for any gaps because there are none in the schema.
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 ('Write data to a smart contract by calling a state-changing function') and resource ('smart contract'), distinguishing it from sibling tools like 'read_contract' (read-only) and 'estimate_gas' (estimation only). It explicitly mentions blockchain state modification, which is a key differentiator.
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: for state-changing functions that modify blockchain state, require gas payment, and need transaction signing. It implicitly distinguishes from 'read_contract' (no state changes) but doesn't explicitly name alternatives or specify when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the purpose and context but doesn't mention security implications beyond what's in the schema, potential gas costs, transaction finality, or what happens if the approval fails. It does add useful context about DeFi protocol requirements, but lacks comprehensive behavioral details for a sensitive operation.
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 earn their place. The first sentence states the core purpose, and the second provides crucial usage context. There's zero waste or redundancy, and it's front-loaded with 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 sensitive blockchain transaction tool with 5 parameters, no annotations, and no output schema, the description provides adequate purpose and usage context but lacks details about transaction behavior, security warnings beyond the schema, or expected outcomes. It's complete enough for basic understanding but insufficient for comprehensive agent guidance given the tool's complexity and sensitivity.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add specific parameter semantics beyond what's in the schema, but it provides important context about unlimited approval ('Use a very large number for unlimited approval' is in the schema, not description). Baseline would be 3, but the description's DeFi context helps interpret parameter usage, warranting a 4.
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 another address to spend your ERC20 tokens') and distinguishes it from sibling tools by specifying this is for token spending approvals rather than transfers, balances, or other blockchain operations. It explicitly mentions the resource (ERC20 tokens) and verb (approve spending).
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 context: 'This is often required before interacting with DeFi protocols.' This gives clear guidance on when to use this tool versus alternatives like transfer operations or balance checks, and it explains the prerequisite nature of token approvals for DeFi interactions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: that it's a read-only operation ('doesn't modify blockchain state'), has no cost implications ('doesn't require gas'), and has no authentication requirements ('doesn't require signing'). It doesn't mention rate limits or error handling, but covers the most critical aspects for a blockchain read operation.
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 earn their place: the first states the core purpose, the second provides critical behavioral context. There's zero wasted language and it's front-loaded with the most important 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 read-only contract interaction tool with no output schema, the description provides excellent context about what the tool does and its behavioral characteristics. It doesn't describe the return format or error cases, but given the 100% schema coverage and clear behavioral disclosure, it's nearly complete. The lack of output schema means some gaps remain in understanding what data will be returned.
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?
The schema description coverage is 100%, so all parameters are well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, which is acceptable given the comprehensive schema coverage. The baseline score of 3 reflects adequate but not enhanced parameter documentation.
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 ('Read data from a smart contract by calling a view/pure function') and resource ('smart contract'), distinguishing it from sibling tools like write_contract (which modifies state) and other query tools that don't involve contract function calls.
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 ('This doesn't modify blockchain state and doesn't require gas or signing'), providing clear context for choosing it over alternatives like write_contract (which modifies state) or other tools that might require signing or gas.
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/mcpdotdirect/evm-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mcpdotdirect/evm-mcp-server)

Score Badge

Copy to your README.md:

[![evm-mcp-server MCP server](https://glama.ai/mcp/servers/mcpdotdirect/evm-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mcpdotdirect/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/mcpdotdirect/evm-mcp-server'

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