MCP Crypto Wallet EVM

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear resource-action pairs (e.g., network_get_block_number vs. wallet_get_balance), but some overlap exists in provider and wallet operations that could cause confusion, such as provider_get_transaction and wallet_get_transaction_count both dealing with transaction data. Descriptions help clarify, but the boundaries between network, provider, and wallet categories are not always sharp.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with clear prefixes (network_, provider_, wallet_) that group related functions. All names use snake_case uniformly, making them predictable and easy to parse. This consistency aids in understanding the tool set's structure and purpose.
Tool Count3/5
With 35 tools, the count is borderline high for a crypto wallet server, potentially overwhelming for agents. While the domain (EVM wallet operations) is broad, covering network, provider, and wallet functions, the number feels heavy and could be streamlined. It's not extreme, but it approaches the upper limit of reasonable scope.
Completeness5/5
The tool set provides comprehensive coverage for EVM wallet operations, including network interactions, provider queries, wallet creation/management, transaction handling, and signing/verification. All essential CRUD and lifecycle actions are present, with no obvious gaps that would hinder agent workflows in this domain.
Average 2.8/5 across 35 of 35 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Send a transaction' implies a write operation that likely modifies blockchain state, but it fails to describe critical behaviors: whether it requires authentication, has rate limits, returns a transaction hash or receipt, is irreversible, or involves gas costs. The description adds no value beyond the basic implication of sending.
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 extremely concise with just two words, 'Send a transaction', which is front-loaded and wastes no space. While this conciseness contributes to under-specification in other dimensions, it earns full marks for brevity and lack of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sending a blockchain transaction (a write operation with financial implications), no annotations, no output schema, and rich sibling tools, the description is severely incomplete. It does not cover behavioral aspects, usage context, or output expectations, leaving critical gaps for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('transaction' and 'wallet'). The description adds no semantic information beyond what the schema provides (e.g., it doesn't explain transaction structure or wallet formats). However, with high schema coverage, the baseline score is 3, as the schema adequately documents parameters without needing description supplementation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a transaction' is a tautology that merely restates the tool name 'wallet_send_transaction'. It does not specify what type of transaction (e.g., cryptocurrency, blockchain), what resource it acts upon, or distinguish it from siblings like 'wallet_sign_transaction' or 'wallet_call'. This provides minimal actionable information beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a wallet or transaction data), exclusions, or comparisons to sibling tools like 'wallet_call' (for read-only calls) or 'wallet_sign_transaction' (for signing without sending). This leaves the agent with no context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Sign a message' fails to disclose critical traits such as whether this is a read-only or destructive operation, authentication requirements, rate limits, or what the signing process entails (e.g., cryptographic hashing, blockchain interaction). This is inadequate for a tool that likely involves sensitive operations like private key usage.
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 extremely concise with just three words, 'Sign a message', which is front-loaded and wastes no space. While it lacks detail, it is structurally efficient and avoids unnecessary verbosity, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a signing operation (likely involving cryptographic functions and private key handling), the description is severely incomplete. With no annotations, no output schema, and a minimal description that doesn't explain behavior, return values, or error conditions, it fails to provide the necessary context for safe and effective use.
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, clearly documenting both parameters ('message' and 'wallet') with their types and purposes. The description adds no additional semantic context beyond what the schema provides, such as format examples or edge cases, but the schema is comprehensive enough to justify a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sign a message' is a tautology that essentially restates the tool name 'wallet_sign_message' without adding meaningful specificity. It does not clarify what type of signing (e.g., cryptographic, blockchain-based) or distinguish this tool from sibling tools like 'wallet_sign_transaction' or 'wallet_sign_typed_data', leaving the purpose vague beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention sibling tools like 'wallet_verify_message' for verification or differentiate from other signing tools such as 'wallet_sign_transaction', leaving the agent with no 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a mnemonic phrase' implies a write operation that generates new data, but it doesn't disclose critical traits such as whether this is a deterministic or random process, if it requires specific permissions, what the output format is (e.g., a list of words), or any security considerations (e.g., should be stored securely). The description is too vague to inform safe and effective use.
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 extremely concise with a single sentence, 'Create a mnemonic phrase,' which is front-loaded and wastes no words. While under-specified, it efficiently states the core action without redundancy or fluff. Every word earns its place by directly addressing the tool's function, making it structurally sound despite its brevity.
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 wallet-related operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what a mnemonic phrase is, how it's used in the wallet ecosystem, what the tool returns (e.g., a phrase string or object), or behavioral aspects like security implications. For a tool that likely generates sensitive cryptographic data, this minimal description fails to provide adequate context for safe and informed use.
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 clear documentation for both parameters ('length' with enum values and 'locale' as optional). The description adds no parameter semantics beyond what the schema provides—it doesn't explain the significance of length choices (e.g., 12 words for standard security) or locale usage (e.g., language for wordlist). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description misses opportunities to enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a mnemonic phrase' is a tautology that essentially restates the tool name 'wallet_create_mnemonic_phrase' without adding specificity. It doesn't clarify what a mnemonic phrase is used for (e.g., wallet seed generation), how it differs from sibling tools like 'wallet_create_random' (which might create random keys without mnemonics), or what resource it creates. This minimal statement fails to provide meaningful context beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 sibling tools like 'wallet_from_mnemonic' (which uses a mnemonic) or 'wallet_create_random' (which might generate keys differently), nor does it specify prerequisites, use cases (e.g., initial wallet setup), or exclusions. Without any context, users must infer usage from the name alone, which is insufficient for effective tool 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?
No annotations are provided, so the description carries full burden. It mentions 'match a filter' but doesn't disclose behavioral traits such as read-only vs. destructive nature, authentication needs, rate limits, or what happens if no logs match. For a tool with no annotations, this leaves significant gaps in understanding its operation.
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 a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it's overly concise to the point of under-specification, slightly reducing its effectiveness.
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 tool that likely retrieves blockchain event logs (inferred from sibling tools), the description is incomplete. It doesn't explain the return format, error handling, or domain context, leaving the agent with insufficient information for proper use.
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 'filter' parameter and its nested properties (address, fromBlock, toBlock, topics). The description adds no additional meaning beyond implying filtering, which is already covered. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get logs that match a filter' states a clear verb ('Get') and resource ('logs'), but it's vague about what type of logs (e.g., blockchain event logs) and lacks differentiation from sibling tools like provider_get_transaction or provider_get_block. It doesn't specify the domain or context, making it somewhat generic.
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. With siblings like provider_get_transaction and provider_get_block, there's no indication of scenarios where logs are preferred over other data retrieval methods, leaving the agent without usage context.
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 whether this is a read-only operation, whether it modifies state, what authentication is needed, rate limits, or what happens when fields are populated. 'Populate' implies mutation but lacks behavioral details needed for safe invocation.
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 a single clear sentence with zero waste - it's appropriately sized for a simple tool. However, it's not front-loaded with critical context about when to use it, and could benefit from more structure to guide the agent.
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 transaction manipulation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what gets returned, what 'populate' actually means operationally, or how this differs from similar wallet tools. The agent lacks sufficient context to use this tool effectively without trial and error.
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 both parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema - it doesn't explain what 'missing fields' refers to in the transaction object or how the wallet parameter interacts with the environment variable fallback. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Populate a transaction with missing fields' clearly states the verb ('populate') and resource ('transaction'), but it's vague about what 'missing fields' means and doesn't distinguish this tool from sibling wallet tools like wallet_send_transaction or wallet_sign_transaction. It provides basic purpose but lacks specificity about what kind of population occurs.
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. The description doesn't mention prerequisites, when this tool is appropriate versus wallet_send_transaction, or what scenarios require transaction population. Without any usage context, agents must infer from the 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, the description carries full burden but only states the basic operation. It doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'get'), potential errors (e.g., invalid address), rate limits, authentication needs, or what the output looks like (e.g., hex data). This leaves significant gaps for an agent.
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 directly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 for a tool with 3 parameters and blockchain context. It lacks details on return values, error conditions, and operational constraints, which are critical for an agent to use this tool effectively in a provider/wallet environment.
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 parameters (address, blockTag, position). The description adds no additional meaning beyond implying 'storage' relates to 'position' and 'address', which is already clear from parameter names. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the storage at a position for an address' clearly states the action (get) and target (storage), but it's vague about what 'storage' means in this context (e.g., blockchain storage slot, data storage). It distinguishes from siblings like provider_get_balance or provider_get_code by specifying storage retrieval, but lacks specificity about the resource type.
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, such as needing a connected provider or valid blockchain state, nor does it compare to sibling tools like provider_get_logs or wallet_get_balance for related data retrieval.
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 but only states the basic action. It doesn't mention whether this is a read-only operation, if it requires network access, potential error conditions (e.g., invalid hash), or what the receipt contains (e.g., status, gas used). This leaves significant gaps for a tool that interacts with 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 extremely concise—a single, direct sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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 transactions and the lack of annotations or output schema, the description is incomplete. It doesn't explain what a transaction receipt entails (e.g., success/failure status, logs) or behavioral aspects like idempotency or error handling, which are crucial for effective tool use in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'transactionHash' clearly documented in the schema. The description doesn't add any additional meaning beyond what the schema provides (e.g., format examples or constraints), so it meets the baseline for adequate but unenhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a transaction receipt' clearly states the verb ('Get') and resource ('transaction receipt'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'provider_get_transaction' or 'provider_get_logs', leaving ambiguity about what specifically distinguishes this tool from related operations.
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. The description lacks context about prerequisites (e.g., needing a transaction hash from a sent transaction) or comparisons to siblings like 'provider_get_transaction', leaving the agent to infer usage without explicit direction.
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. 'Get the wallet address' implies a read-only operation, but it doesn't specify what happens if the wallet parameter is invalid, whether authentication is needed, or what the output format might be. It mentions the PRIVATE_KEY environment variable fallback in the schema, but the description itself lacks this critical behavioral detail, leaving gaps in understanding how the tool behaves in different scenarios.
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 extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, though this conciseness comes at the cost of completeness in other dimensions.
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 tool's moderate complexity (involving wallet operations with a parameter) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what a 'wallet address' means in this context, what format it returns, or how errors are handled. For a financial/cryptographic tool with potential security implications, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what's already in the schema, which has 100% coverage. The schema fully describes the single optional parameter 'wallet' and its fallback behavior. Since schema coverage is high, the baseline score is 3, as the description doesn't need to compensate but also doesn't add value beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the wallet address' clearly states the action (get) and resource (wallet address), but it's vague about what exactly is being retrieved. It doesn't distinguish from sibling tools like wallet_get_public_key or wallet_get_private_key, which also retrieve wallet-related information. The purpose is understandable but lacks specificity about the type of address being retrieved.
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 sibling tools like wallet_get_public_key (which might return similar information) or explain why one would choose this tool over others. There's no context about prerequisites or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('get'), but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or what format the network information is returned in (e.g., JSON object with fields). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, 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, no output schema, and multiple sibling tools, the description is incomplete. It doesn't clarify what 'network information' includes (e.g., chain ID, network name, RPC URL) or how it differs from other network-related tools, leaving the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but a baseline of 4 is given since it doesn't compensate for any gaps (there are none).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the current network information' clearly states the action (get) and resource (network information), but it's vague about what specific network information is retrieved. It doesn't distinguish from siblings like 'network_get_block_number' or 'provider_get_chain_id', which also provide network-related data.
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. With siblings like 'network_get_block_number' and 'provider_get_chain_id', the description lacks context on whether this tool returns broader network details (e.g., chain ID, name) or something else, leaving the agent to guess.
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 tool estimates gas, implying a read-only, non-destructive operation, but doesn't specify if it's a simulation, if it requires network access, potential rate limits, or error conditions. This leaves significant 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 with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning full marks for structure and brevity.
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 in blockchain contexts, no annotations, and no output schema, the description is incomplete. It doesn't explain what the estimate includes (e.g., base fee, priority fee), how it's calculated, or what the return value looks like, leaving critical context gaps for effective tool use.
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 'transaction' parameter well-documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the transaction fields or their formats. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('estimate') and resource ('gas required for a transaction'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'wallet_populate_transaction' or 'wallet_get_gas_price', which might also involve gas estimation or related operations, so it lacks sibling differentiation for 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 prerequisites, such as needing a transaction object, or contrast it with siblings like 'wallet_get_gas_price' for gas price queries or 'wallet_populate_transaction' for transaction preparation, leaving 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?
No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details: it doesn't mention if this is a read-only operation, potential rate limits, error conditions (e.g., invalid hash), or what the output looks like (e.g., block object structure). For a tool with no annotations, 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 with zero waste. It is front-loaded with the core purpose and uses clear language. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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., block data format), error handling, or behavioral constraints. For a tool that likely returns complex blockchain data, this leaves the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (blockHashOrBlockTag and includeTransactions). The description adds no additional meaning beyond implying the block identifier can be a number or hash, which is already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('a block'), specifying it can be retrieved by 'number or hash'. It distinguishes from some siblings like provider_get_transaction (gets transactions) but doesn't explicitly differentiate from network_get_block_number (which gets only the number, not block details). The purpose is specific but sibling differentiation is incomplete.
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 when to choose this over network_get_block_number (for block details vs. just number) or provider_get_transaction (for transaction details within a block). The description lacks context about use cases or exclusions.
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 'Get the code at an address' but does not clarify what 'code' entails (e.g., smart contract bytecode, script data), whether it's a read-only operation, potential errors, or rate limits. This lack of detail is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence ('Get the code at an address') that is front-loaded and wastes no words. It efficiently communicates the core action without unnecessary elaboration, earning full marks for conciseness.
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, no annotations, and no output schema, the description is incomplete. It lacks details on what 'code' means, expected return values, error conditions, or how it differs from sibling tools, making it inadequate for an agent to use this tool effectively without additional 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 documents both parameters ('address' and 'blockTag') with descriptions. The description does not add any additional meaning beyond what the schema provides, such as format examples or constraints, but the high schema coverage justifies a baseline score of 3.
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 'Get the code at an address' clearly states the verb ('Get') and resource ('code at an address'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'provider_get_storage_at' or 'provider_get_transaction', which might retrieve different data types from addresses, leaving some ambiguity in sibling context.
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 specify if this is for retrieving smart contract bytecode or other code types, nor does it mention any prerequisites or contexts, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 what the tool does but doesn't explain how it behaves—e.g., whether it's read-only, requires network access, handles errors, or returns specific data formats. This leaves significant gaps for an AI agent to understand operational traits.
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 with zero wasted words. It's front-loaded and efficiently conveys the core action without unnecessary elaboration, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of ENS operations and the lack of annotations and output schema, the description is insufficient. It doesn't explain what an 'ENS resolver' is, what the return value might be (e.g., an address or contract), or how this differs from other ENS tools in the sibling list. For a tool in a blockchain context with no structured support, 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?
The input schema has 100% description coverage, with the 'name' parameter documented as 'The ENS name'. The description doesn't add any extra meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 ('ENS resolver for a name'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'provider_resolve_name' or 'provider_lookup_address', which might have overlapping ENS-related functionality, so it lacks sibling distinction.
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 'provider_resolve_name' and 'provider_lookup_address' that might handle ENS resolution differently, there's no indication of context, prerequisites, or exclusions for this specific tool.
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 'Get' implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error handling, or what happens if the hash is invalid. For a tool with zero annotation coverage, this is a significant gap, scoring a 2.
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: 'Get a transaction by hash'. It's front-loaded with the core action and resource, with zero waste or unnecessary details, earning a 5.
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 parameter, the description is incomplete. It doesn't explain return values, error cases, or behavioral context, which is inadequate for a tool that retrieves transactional data. With minimal added value beyond the schema, it scores a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'transactionHash' fully documented in the schema. The description adds no additional meaning beyond implying retrieval by hash, which is already covered. Baseline is 3 when schema does the heavy lifting, so it scores a 3.
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 'Get a transaction by hash' clearly states the verb ('Get') and resource ('transaction'), specifying it's retrieved via hash. It distinguishes from siblings like provider_get_transaction_receipt (which gets receipt) and wallet_get_transaction_count (which gets count), but doesn't explicitly differentiate beyond the hash parameter. This is clear but lacks explicit sibling differentiation, warranting a 4.
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 context, prerequisites, or exclusions, such as when to use provider_get_transaction_receipt instead for receipt details or network_get_block for block-level data. With no usage instructions, it scores a 2.
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 lookup action but does not cover critical aspects such as network requirements, error conditions (e.g., invalid addresses or unregistered ENS names), rate limits, or response format. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning full marks for brevity and clarity.
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 incomplete for a tool that interacts with blockchain systems. It omits essential context like network dependencies, error handling, and return value details (e.g., ENS name string or null), leaving the agent with insufficient information for reliable use.
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 parameter 'address' clearly documented in the schema. The description adds no additional semantic context beyond the schema, such as address format (e.g., Ethereum 0x-prefixed hex) or validation rules. 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 verb 'Lookup' and the resource 'ENS name for an address', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'provider_resolve_name' (which resolves names to addresses), leaving some ambiguity about the reverse mapping relationship.
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 does not mention sibling tools like 'provider_resolve_name' for reverse lookups or clarify the context (e.g., Ethereum blockchain, ENS system), leaving the agent to infer usage scenarios without explicit direction.
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 ('resolve') but doesn't cover critical aspects like error handling (e.g., for invalid names), network dependencies, rate limits, or response format. For a tool with no annotation coverage, 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, clear sentence: 'Resolve an ENS name to an address.' It is front-loaded with the core action, has zero wasted words, and efficiently communicates the tool's function without unnecessary elaboration. This makes it easy to parse and understand 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 tool's complexity (involving ENS resolution), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the resolved address output looks like (e.g., Ethereum address format), potential errors, or dependencies on network state. For a tool in this context, more detail is needed to ensure proper usage.
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 'name' documented as 'The ENS name to resolve.' The description adds no additional semantic context beyond this, such as format examples (e.g., 'example.eth') or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
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: 'Resolve an ENS name to an address.' It specifies the verb ('resolve') and resource ('ENS name'), making the action explicit. However, it doesn't differentiate from sibling tools like provider_lookup_address (which performs reverse resolution), leaving room for improvement in sibling distinction.
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 sibling tools like provider_lookup_address (for reverse resolution) or other ENS-related operations, nor does it specify prerequisites or contexts for usage. This lack of comparative guidance limits its effectiveness in tool 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, the description carries full burden but only states it doesn't send transactions. It doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns specific data formats, or handles errors. The description is minimal and leaves critical behavior undocumented.
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 states the core purpose without unnecessary words. It's appropriately sized and front-loaded with 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?
For a tool with no annotations, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain return values, error handling, authentication requirements, or how it differs from similar provider_* tools, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying the 'transaction' parameter is for the call details, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('call a contract method') and specifies it's done 'without sending a transaction', which distinguishes it from write operations. However, it doesn't explicitly differentiate from sibling tools like provider_get_code or provider_get_storage_at that also read contract state without transactions.
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 like provider_get_code for reading contract code or wallet_send_transaction for actual transactions. The description implies it's for read-only contract calls but doesn't specify use cases or prerequisites.
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 the full burden of behavioral disclosure. It states the tool creates a wallet but doesn't mention security implications, storage location, whether the wallet is saved or ephemeral, or potential side effects like overwriting existing wallets. This leaves critical behavioral traits unspecified.
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 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 wallet creation (a security-sensitive operation) and the lack of annotations and output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., wallet address, private key, or object), error conditions, or important behavioral details, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three optional parameters (locale, password, path). The description adds no parameter-specific information beyond the schema, but the baseline is 3 since the schema provides adequate coverage without contradiction.
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 ('create a new wallet') and method ('with a random private key'), which distinguishes it from sibling tools like wallet_create_mnemonic_phrase or wallet_from_private_key. However, it doesn't specify what type of wallet (e.g., cryptocurrency) or context, leaving some ambiguity.
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 like wallet_create_mnemonic_phrase or wallet_from_private_key. The description lacks context about use cases, prerequisites, or trade-offs, offering minimal direction 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 full burden but offers minimal behavioral insight. It states the tool encrypts but doesn't disclose critical traits: whether encryption is irreversible without the password, what format the output takes (e.g., JSON string), if it modifies the original wallet or returns a new one, or any side effects like requiring specific permissions. For a security-sensitive operation, this is inadequate.
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 wasted words. It's front-loaded with the core action ('Encrypt a wallet'), making it easy to parse quickly. Every word earns its place by contributing to the basic purpose.
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 (encryption with nested options), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the output format, security implications, error conditions, or how 'options' customize encryption. For a tool that handles sensitive data, this leaves significant gaps for an agent to operate safely.
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 documented in the schema itself. The description adds no extra meaning beyond implying 'wallet' and 'password' are required (which the schema already shows). It doesn't clarify parameter interactions (e.g., how 'options' affect encryption) or provide examples, so it meets the baseline but doesn't enhance 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 ('encrypt') and target ('a wallet') with the mechanism ('with a password'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'wallet_from_encrypted_json' (which decrypts) or 'wallet_create_random' (which creates), but the verb+resource combination is specific enough for basic understanding.
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 prerequisites (e.g., needing an unencrypted wallet first), compare to siblings like 'wallet_from_encrypted_json' (for decryption), or specify use cases (e.g., securing a wallet for storage). Without this context, an agent might misuse it.
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 offers minimal behavioral context. It mentions decryption but doesn't disclose security implications (e.g., password handling), error conditions (e.g., invalid JSON/password), or what the created wallet enables (e.g., signing transactions). This is inadequate for a tool that handles sensitive credentials.
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 appropriately sized and front-loaded with the core action.
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 that handles encrypted data and passwords with no annotations or output schema, the description is insufficient. It lacks details on security practices, error handling, return values, or integration with sibling tools (e.g., what operations the created wallet supports). More context is needed given the sensitivity and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond implying the JSON is encrypted and requires a password for decryption, which is already evident from parameter names and schema descriptions.
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 ('Create a wallet') and method ('by decrypting an encrypted JSON wallet'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'wallet_from_mnemonic' or 'wallet_from_private_key', which are alternative wallet creation methods.
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 prerequisites (e.g., needing an existing encrypted wallet), nor does it compare to sibling tools like 'wallet_create_random' for new wallets or 'wallet_from_mnemonic' for recovery.
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 ('Create a wallet') but doesn't mention whether this is a read-only or destructive operation, what permissions are needed, what the output format is, or any error conditions. This is a significant gap for a tool that likely involves sensitive data handling.
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 any fluff or redundancy. It's appropriately sized and front-loaded, 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 complexity of wallet creation (involving sensitive data and potential security implications), no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like what the tool returns, error handling, or security considerations, which are crucial for safe and effective use.
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 (mnemonic, locale, path) with descriptions. The description adds no additional meaning beyond what's in the schema, such as explaining parameter interactions or constraints, which aligns with the baseline score when schema coverage is high.
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 ('Create a wallet') and the resource ('from a mnemonic phrase'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'wallet_create_random' or 'wallet_from_private_key', which also create wallets using different methods, so it misses full sibling 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 such as 'wallet_create_random' or 'wallet_from_private_key'. It lacks context about prerequisites (e.g., needing a mnemonic phrase) or exclusions, leaving the agent to infer usage from the 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, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose security implications (e.g., private key handling), error conditions, or what the created wallet enables (e.g., for signing transactions). This is a significant gap for a tool involving sensitive operations.
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 directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (wallet creation involves security and blockchain interactions), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a wallet object) or behavioral traits, leaving gaps for the agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'privateKey' documented as 'The private key'. The description adds no additional meaning beyond this, such as format requirements (e.g., hex string) or validation rules. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a wallet') and the resource ('from a private key'), making the purpose immediately understandable. It distinguishes from siblings like 'wallet_create_random' or 'wallet_from_mnemonic' by specifying the private key source, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'wallet_from_mnemonic' or 'wallet_from_encrypted_json'. The description lacks context about prerequisites (e.g., needing a valid private key) or typical use cases, leaving the agent to infer usage.
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 it 'gets' balance, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, network connectivity, rate limits, error conditions, or what happens when parameters are omitted. The description is minimal and lacks essential 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 extremely concise at just 6 words, front-loading the core purpose with zero wasted language. Every word earns its place by directly communicating the tool's function 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?
Given no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the balance returns in (e.g., Wei, Ether, token-specific units), whether it's for native currency or tokens, or any error handling. For a financial tool with potential complexity, this minimal description leaves critical 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 fully documents both parameters (blockTag and wallet). The description adds no 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, which applies here.
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 ('balance of the wallet'), making the purpose immediately understandable. It distinguishes from siblings like wallet_get_address or wallet_get_transaction_count by focusing specifically on balance retrieval. However, it doesn't explicitly differentiate from network-related tools, though the 'wallet_' prefix provides some context.
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. While the name suggests it's for balance queries, there's no mention of when to choose this over other wallet tools or network tools for similar purposes. No prerequisites, exclusions, or alternative tools are referenced.
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 a read operation ('Get') but doesn't disclose behavioral traits like whether it requires network access, has rate limits, returns cached or real-time data, or what format the output is in. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose, 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 but potentially network-dependent operation, the description is incomplete. It doesn't explain what 'gas price' means in context, how the value is obtained, or what the return format is, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single optional parameter 'wallet' with its description. The tool description adds no parameter information beyond what's in the schema, resulting in the baseline score of 3.
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 ('current gas price'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'network_get_fee_data' which might provide similar or overlapping gas price information, preventing 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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'network_get_fee_data' that might offer gas price data, the description lacks any context about use cases, prerequisites, or comparisons, leaving the agent to guess.
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 only adds a security warning about private key access. It fails to disclose critical behavioral traits such as whether this is a read-only operation, potential risks (e.g., exposure of sensitive data), or output format (e.g., returns a string). The warning is vague and insufficient for a high-stakes tool.
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 extremely concise—a single sentence that front-loads the core purpose and includes a relevant warning. Every word earns its place with no redundancy or fluff, making it efficient and well-structured.
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 handling sensitive private keys with no annotations or output schema, the description is inadequate. It lacks details on security implications, return values, error conditions, or usage context, leaving significant gaps for safe and effective agent operation.
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 parameter-specific semantics beyond implying security concerns, which does not enhance understanding of password or wallet usage. 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.
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 ('wallet private key'), making the purpose evident. It distinguishes from siblings like wallet_get_public_key by specifying private key retrieval, but does not explicitly contrast with other wallet tools like wallet_from_private_key or wallet_encrypt.
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 minimal guidance with a security warning, implying caution, but offers no explicit when-to-use context, prerequisites (e.g., when a wallet is encrypted), or alternatives (e.g., using wallet_from_private_key for different purposes). It lacks clear differentiation from 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. It states what the tool does but omits critical details: whether this operation is read-only or has side effects, if it requires authentication, potential rate limits, or what format the public key is returned in (e.g., hex, base64). For a cryptographic tool with security implications, this lack of transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the core purpose without any fluff. Every word earns its place: 'Get' specifies the action, 'wallet' identifies the resource type, and 'public key' pinpoints the exact data retrieved. This efficiency makes it easy for an agent to parse quickly, though it sacrifices detail for brevity.
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 cryptographic operations and the lack of annotations or output schema, the description is insufficiently complete. It doesn't explain what a public key is used for, how it relates to other wallet tools, or what the return value looks like (e.g., a string in hex format). For a tool in a security-sensitive domain with many siblings, more context is needed to ensure safe and correct usage.
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 single parameter 'wallet' fully documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., no examples of wallet formats or edge cases). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have clarified the relationship between the wallet input and the resulting public key.
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 resource ('wallet public key'), making the purpose immediately understandable. It distinguishes itself from sibling tools like wallet_get_address or wallet_get_private_key by specifying the exact cryptographic key being retrieved. However, it doesn't explicitly mention that this is for cryptographic operations or blockchain interactions, which could further differentiate it from generic key retrieval tools.
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 use cases like verifying wallet ownership, encryption, or signing operations, nor does it differentiate from siblings like wallet_get_address (which returns a different identifier) or wallet_get_private_key (which retrieves the sensitive counterpart). Without this context, an agent might struggle to choose between related wallet 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. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover other aspects like authentication needs (e.g., wallet parameter handling), rate limits, error conditions, or what the return value represents (e.g., integer count). This leaves gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly addresses what the tool does, making it easy to parse quickly. Every part of the sentence earns its place by specifying the action and target.
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 for a tool that retrieves dynamic data. It lacks details on return format (e.g., integer nonce), error handling, dependencies (like network state), and how it fits into broader workflows (e.g., transaction preparation). This makes it harder for an agent to use correctly without additional 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 both parameters (blockTag and wallet). The description adds no parameter-specific information beyond what's in the schema, such as clarifying 'nonce' relates to the transaction count or explaining default behaviors. 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.
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 the number of transactions sent from this account (nonce)'. It specifies the verb ('Get'), resource ('number of transactions'), and scope ('from this account'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like wallet_get_balance or wallet_get_address, which also retrieve account-specific information.
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 sibling tools like wallet_get_balance (for balance queries) or provider_get_transaction (for transaction details), nor does it specify use cases like checking account activity or preparing new transactions. The agent must infer usage from the purpose 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 but only states the action without behavioral details. It doesn't disclose that this is a cryptographic signing operation requiring wallet access, potential security implications, whether it's read-only or mutative, or what the output format might be. This leaves significant gaps for an agent to understand the tool's 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 extremely concise - a single parenthetical phrase - with zero wasted words. It's front-loaded with the core action and immediately specifies the standard, making it efficient for quick comprehension.
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 cryptographic signing tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what EIP-712 typed data signing entails, what the output looks like, security considerations, or how it differs from other signing methods. The context signals show complexity (nested objects, required parameters) that warrants more explanation.
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 parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond the tool name's hint about 'typed data' and 'EIP-712', which aligns with the schema parameters but doesn't provide extra context. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('sign') and resource ('typed data') with the specific standard 'EIP-712', making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'wallet_sign_message' or 'wallet_verify_typed_data', which would have earned a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'wallet_sign_message' for regular message signing or 'wallet_verify_typed_data' for verification. It also doesn't mention prerequisites like needing a wallet or the EIP-712 context, leaving 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'verify' implies a read-only, non-destructive operation, the description doesn't specify what happens on success/failure (e.g., returns a boolean), error conditions, or any side effects. For a cryptographic verification tool with zero 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 with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward verification tool, 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 tool's cryptographic complexity and lack of annotations or output schema, the description is incomplete. It doesn't explain the verification process, return values (e.g., boolean result), or error handling. For a tool that performs security-critical operations, this leaves too much undefined for reliable agent use.
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 clear documentation for all three parameters (address, message, signature). The description adds no additional parameter semantics beyond what's in the schema, such as format details or examples. This meets the baseline of 3 when schema coverage is high, but doesn't provide extra value.
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 'Verify a signed message' clearly states the tool's purpose with a specific verb ('verify') and object ('signed message'), distinguishing it from sibling tools like wallet_sign_message (which creates signatures) and wallet_verify_typed_data (which handles typed data). However, it doesn't explicitly mention what resource or entity is being verified (e.g., a cryptographic signature), leaving some ambiguity compared to a perfect 5-score description.
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 prerequisites (e.g., needing a signature from wallet_sign_message first), exclusions, or comparisons to sibling tools like wallet_verify_typed_data. This lack of context makes it harder for an agent to select the right tool in practice.
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 but offers minimal information. It states the verification action but doesn't describe what happens on success/failure, error conditions, performance characteristics, or security implications. This is inadequate for a verification tool with cryptographic operations.
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 phrase that directly states the tool's purpose with zero wasted words. It's appropriately sized for a straightforward verification tool and front-loads the core functionality.
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 cryptographic verification tool with 5 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the verification process, return values, or error handling. The context signals indicate complexity (nested objects, no output schema), but the description doesn't address these aspects.
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 clear parameter documentation. The description adds no parameter-specific information beyond the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even without additional param details 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 'Verify signed typed data' clearly states the tool's function with a specific verb ('verify') and resource ('signed typed data'), distinguishing it from siblings like wallet_verify_message. However, it doesn't explicitly differentiate from wallet_sign_typed_data beyond the verb, leaving some ambiguity about the relationship between signing and verification.
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 prerequisites (e.g., needing a signature from wallet_sign_typed_data), compare it to wallet_verify_message, or specify scenarios where typed data verification is preferred over message verification.
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 any behavioral traits such as whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, network dependencies, or what happens on failure. For a tool with zero annotation coverage, 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 extremely concise at just 5 words ('Get the current block number'), with zero wasted words. It's front-loaded with the core action and resource. Every word earns its place, making it easy to parse quickly 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 tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is incomplete. It doesn't explain what 'current block number' means in context (e.g., latest mined block), what format the output might be (e.g., integer, hex), or any error conditions. For a blockchain-related tool, more context about the return value and typical usage would be helpful, especially without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, and it correctly doesn't mention any. Since there are no parameters, the description doesn't add or detract from parameter understanding, meeting the baseline for parameter-less tools.
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 ('current block number'), making the purpose immediately understandable. It distinguishes this tool from siblings like provider_get_block (which retrieves full block data) and network_get_network (which gets network info), though it doesn't explicitly mention these distinctions. The purpose is specific but could be more differentiated from similar tools.
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 tool is appropriate (e.g., for checking blockchain progress or timing) or when to use sibling tools like provider_get_block (for detailed block data) or network_get_fee_data (for fee information). There's no context about prerequisites 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?
No annotations are provided, so the description carries the full burden. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't disclose any behavioral traits such as error conditions, performance characteristics, or what happens if the wallet isn't properly connected, which is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any redundant or unnecessary words. It's appropriately sized and front-loaded, making it highly efficient and easy to parse.
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 optional parameter) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on return values or potential errors, leaving gaps in completeness for a tool that interacts with wallet connectivity.
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 'wallet' fully documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score 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 ('Get') and the resource ('chain ID the wallet is connected to'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'network_get_network' or 'wallet_get_address', which might also involve network/wallet state queries, so it doesn't reach the highest score for sibling distinction.
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 clarify if this is for checking the current network context or how it differs from other network-related tools in the sibling list, leaving the agent without usage context.
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 context. It mentions the tool sets a configuration (implying mutation) and defaults, but doesn't disclose critical traits like persistence scope (session vs. global), permission requirements, error handling, or side effects on other tools. This is inadequate for a configuration tool.
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 a single, efficient sentence that front-loads the core action and provides context on defaults. It avoids redundancy but could be slightly more structured (e.g., separating purpose from default behavior).
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 configuration tool with no annotations or output schema, the description is incomplete. It lacks details on behavioral impact (e.g., how this affects other wallet/network tools), error cases, or return values. Given the complexity of provider settings in blockchain contexts, this leaves significant 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 coverage is 100% with one parameter well-documented as 'provider RPC URL'. The description adds marginal value by contextualizing it as overriding defaults or environment variables, but doesn't elaborate on format, validation, or examples beyond the schema. Baseline 3 is appropriate given 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 ('Set') and resource ('provider URL'), specifying it configures the RPC endpoint. It distinguishes from sibling tools by focusing on provider configuration rather than wallet operations or network queries, though it doesn't explicitly contrast with alternatives like environment variables.
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 overriding default or environment-set provider URLs, but lacks explicit guidance on when to use this versus alternatives (e.g., when to rely on defaults vs. set manually) or prerequisites. It mentions defaults but doesn't clarify trade-offs or scenarios.
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 it 'Get[s]' data, implying a read-only operation, but doesn't specify if it's real-time, cached, requires network access, has rate limits, or error conditions. For a tool with zero annotation coverage, this is a significant gap in transparency about its operational 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 front-loads the core purpose ('Get the current fee data') and adds clarifying examples ('base fee, max priority fee, etc.') without redundancy. Every word contributes value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or integration context. For a simple read operation, this might suffice, but the absence of output schema means the agent doesn't know what data to expect, leaving clear gaps in completeness.
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 input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce unnecessary complexity.
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 resource ('current fee data'), with specific examples of what that includes ('base fee, max priority fee, etc.'). It distinguishes itself from siblings like 'wallet_get_gas_price' by focusing on broader fee data rather than just gas price. However, it doesn't explicitly differentiate from all siblings, such as 'provider_get_block' which might also contain fee data, 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 prerequisites, context (e.g., for transaction planning), or compare to siblings like 'wallet_get_gas_price' or 'provider_get_block' that might offer overlapping or related data. This lack of usage context leaves the agent with minimal direction.
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 the tool signs but doesn't send, which is useful. However, it lacks critical information: what permissions are needed, whether this is a read-only or mutating operation, what format the signed transaction takes, or any security implications. For a signing 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 that communicates the core purpose without any wasted words. It's appropriately sized and front-loaded with 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?
For a transaction signing tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (signed transaction format), what happens on failure, security requirements, or how the signing interacts with the wallet parameter. The context signals show complexity (nested objects, 2 parameters), but the description doesn't address this complexity.
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 doesn't add any parameter-specific information beyond what's in the schema. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('sign a transaction') and distinguishes it from sending operations. It specifies 'without sending it' which differentiates it from sibling tools like wallet_send_transaction. However, it doesn't explicitly contrast with other signing tools like wallet_sign_message or wallet_sign_typed_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 by stating 'without sending it', suggesting this is for preparing transactions rather than executing them. However, it doesn't provide explicit guidance on when to use this versus wallet_send_transaction or other signing alternatives. No prerequisites or exclusions are mentioned.
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:

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

Score Badge

Copy to your README.md:

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

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/dcSpark/mcp-cryptowallet-evm'

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