MetaMask MCP

by Xiawpohr

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, such as 'get-block' and 'get-block-number' which could cause minor confusion. However, descriptions clarify their differences, and the majority of tools target specific actions like contract operations, account management, and transaction handling without significant ambiguity.
Naming Consistency4/5
Tool names follow a consistent verb-noun pattern with hyphens (e.g., 'get-account', 'send-transaction'), but there are minor deviations like 'call' and 'disconnect' that lack nouns. Overall, the naming is predictable and readable, with only a few tools breaking the pattern.
Tool Count3/5
With 28 tools, the count is borderline high for a wallet integration server, potentially feeling heavy. While it covers many blockchain operations, some tools like 'wait-seconds' seem peripheral, and the set might benefit from consolidation to reduce complexity without losing core functionality.
Completeness5/5
The tool set provides comprehensive coverage for MetaMask wallet and blockchain interactions, including account management, contract operations (deploy, read, write), transaction handling, gas estimation, and network utilities. There are no obvious gaps, and it supports full CRUD-like workflows for the domain.
Average 2.9/5 across 28 of 28 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?
With no annotations provided, the description carries full burden but fails to disclose any behavioral traits. It doesn't mention that this is a state-changing operation requiring authorization, gas fees, or network interaction, nor does it describe potential side effects, error handling, or return values. This is inadequate for a tool with significant implications like contract writes.
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: 'Execute a write function on a contract.' It is front-loaded and wastes no words, though this brevity contributes to its lack of detail. Every word earns its place by stating the core action, but it may be overly terse for such a complex tool.
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 tool's complexity (8 parameters, no annotations, no output schema, and significant behavioral implications like blockchain transactions), the description is severely incomplete. It fails to explain what the tool returns, error conditions, gas or fee implications, or how it differs from siblings, leaving critical gaps 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%, providing clear parameter documentation in the schema itself (e.g., 'The contract's ABI,' 'Value in wei sent with this transaction'). The description adds no additional meaning beyond the schema, but the high coverage justifies a baseline score of 3, as the schema does the heavy lifting for parameter 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 'Execute a write function on a contract' states a basic purpose but is vague about what constitutes a 'write function' in this context. It doesn't distinguish from sibling tools like 'read-contract' or 'send-transaction' beyond the word 'write,' and lacks specificity about the resource being modified or the exact nature of the operation.
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?
No guidance is provided on when to use this tool versus alternatives like 'read-contract' for read-only calls, 'send-transaction' for general transactions, or 'deploy-contract' for deployment. The description offers no context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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' implies a write/mutation operation, but it doesn't disclose any behavioral traits such as required permissions, whether it's reversible, rate limits, or what the output looks like (e.g., a signature string). This is inadequate for a tool with potential security or state-changing implications.
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 ('Sign a message.') with no wasted words, making it front-loaded and easy to parse. Every word earns its place by directly stating the tool's action, though this conciseness comes at the cost of detail.
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 a signing operation (likely involving cryptography or blockchain), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'signing' entails in this context, what the result is, or any dependencies, leaving significant gaps for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'message' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format constraints or examples), so it meets the baseline of 3 for high schema coverage without compensating value.
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 'Sign a message' clearly states the verb ('sign') and resource ('a message'), providing a basic understanding of the tool's function. However, it lacks specificity about what type of signing (e.g., cryptographic, blockchain) or context, and doesn't distinguish it from sibling tools like 'verify-message' beyond the obvious verb difference.
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 account or connection), exclusions, or comparisons to siblings like 'verify-message' or 'send-transaction', 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?
No annotations are provided, so the description carries the full burden. It mentions 'read-only,' indicating no state changes, but lacks details on permissions, rate limits, error handling, or response format. For a tool with 5 parameters and no annotations, this is insufficient behavioral disclosure.
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 states the core action and outcome. It is front-loaded with the main purpose, though it could be slightly more structured by explicitly mentioning key parameters or constraints.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error cases, and return values, making it inadequate for a tool that interacts with contracts and requires precise 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?
Schema description coverage is 100%, with each parameter (abi, address, functionName, args, chainId) documented in the schema. The description adds no additional parameter semantics beyond implying 'read-only' function calls, so it meets the baseline of 3 without compensating for gaps.
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 states the tool 'call[s] a read-only function on a contract, and returning the response,' which identifies the verb ('call'), resource ('contract'), and scope ('read-only function'). However, it does not differentiate from siblings like 'call' or 'write-contract' beyond the 'read-only' qualifier, making the purpose clear but not specific enough for full 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 implies usage for read-only contract functions but provides no explicit guidance on when to use this tool versus alternatives like 'call' or 'write-contract.' There is no mention of prerequisites, exclusions, or specific contexts, leaving 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?
No annotations are provided, so the description carries full burden. 'Switch' implies a mutation/write operation, but the description doesn't disclose behavioral traits like whether this requires user confirmation in a wallet, what happens on failure (e.g., chain not supported), or if it changes global state. It lacks context on permissions, side effects, or error conditions.
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. It's front-loaded with the core action. However, it could be more informative by specifying context (e.g., 'Switch the active blockchain network in a connected wallet'), but as-is, it's appropriately concise.
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 (mutation tool with nested parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what 'target chain' means, the expected behavior (e.g., prompts user, updates wallet), return values, or error handling. For a tool that likely interacts with a wallet or blockchain provider, more context is needed for safe and correct 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%, with clear descriptions for both parameters: 'chainId' as 'ID of chain to switch to' and 'addEthereumChainParameter' as 'Add not configured chains to Ethereum wallets.' The description adds no additional meaning beyond the schema, but the schema provides adequate documentation, meeting the baseline score of 3 for high coverage.
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 'Switch the target chain' clearly states the verb ('switch') and resource ('target chain'), making the basic purpose understandable. However, it doesn't specify what 'target chain' refers to (e.g., blockchain network in a wallet context) or differentiate from siblings like 'get-chain-id' or 'get-chains' that retrieve chain information rather than switch to one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a connected wallet), exclusions, or compare to siblings like 'get-chain-list' for listing available chains. The agent must infer usage from the name and schema 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. 'Fetch' suggests a read-only operation, but it doesn't specify if this requires authentication, has rate limits, returns paginated data, or what the output format looks like. The description is minimal and lacks critical behavioral details for a tool with parameters.
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, 'Fetch the token information.', which is front-loaded and wastes no words. Every part of the sentence contributes to the purpose, making it efficient and well-structured for 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 fetching token data in a blockchain context, the description is incomplete. With no annotations, no output schema, and siblings that handle similar functions, it fails to clarify what 'token information' entails—e.g., metadata, decimals, symbol—or how it differs from other tools. This leaves significant gaps for an AI agent to understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'address' and 'chainId' in the input schema. The description adds no additional meaning beyond the schema, such as explaining what 'token information' includes or how parameters affect the fetch. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch the token information' states a clear verb ('fetch') and resource ('token information'), but it's vague about what specific token information is retrieved. It doesn't distinguish from sibling tools like 'get-token-balance' or 'get-native-currency-balance', which also fetch token-related data. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-token-balance' and 'get-native-currency-balance', there's no indication of what makes 'get-token' unique—such as whether it fetches metadata, supply, or other token details. Usage is implied only by the name, with no explicit context 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?
With no annotations provided, the description carries full burden but fails to disclose critical behavioral traits. It doesn't mention that this is a write/mutation operation (implied by 'send'), potential costs (gas fees), irreversible nature, network dependencies, or authentication requirements. The description adds no meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single 4-word sentence that's front-loaded with the core action. There's zero wasted language or redundancy, making it easy to parse while still conveying 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?
For a transaction-sending tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after sending (e.g., returns transaction hash, requires confirmation), error conditions, network requirements, or relationship to sibling tools. The agent would struggle to use this 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%, providing good documentation for all 6 parameters. The description adds no additional parameter semantics beyond what's in the schema, but with complete schema coverage, the 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send transactions to networks' clearly states the action (send) and target (transactions to networks), but it's vague about what kind of transactions and lacks differentiation from siblings like 'write-contract' or 'call'. It doesn't specify if this is for native token transfers, contract interactions, or both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'write-contract', 'call', or 'deploy-contract'. The description provides no context about prerequisites, network requirements, or typical use cases, leaving the agent to infer usage from parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool performs a deployment (implying a write/mutation operation) but doesn't disclose critical traits: whether it requires authentication, consumes gas/transaction fees, has rate limits, returns a transaction hash or contract address, or what network effects occur. For a mutation tool with zero annotation coverage, 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 front-loads the core purpose ('Deploy a contract to the network') and specifies key inputs. 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?
For a complex mutation tool (contract deployment) with no annotations and no output schema, the description is insufficient. It lacks behavioral details (e.g., gas costs, return values), usage prerequisites, and error handling context. Given the high-stakes nature of blockchain deployments, more completeness is needed to guide an AI agent 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 parameters (abi, args, bytecode). The description mentions 'bytecode, and constructor arguments' but doesn't add meaningful context beyond the schema's descriptions (e.g., format details, validation rules). It omits 'abi' entirely. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deploy') and target ('contract to the network'), with specific inputs mentioned ('bytecode, and constructor arguments'). It distinguishes from siblings like 'write-contract' by focusing on deployment rather than interaction. However, it doesn't explicitly differentiate from all possible deployment-related tools that might exist.
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 (e.g., needing a connected wallet, sufficient funds), nor does it contrast with sibling tools like 'write-contract' for contract interactions or 'send-transaction' for general transactions. Usage context is implied but not explicit.
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. 'Disconnect' suggests a mutation or state change, but it doesn't disclose behavioral traits such as whether it's reversible, requires authentication, affects other sessions, or has side effects like clearing cached data. This leaves critical gaps for an agent to understand the tool's impact.
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 directly states the tool's purpose, making it easy to parse quickly. This is an example of optimal conciseness for a simple tool.
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 a wallet disconnect operation (likely a mutation with state changes), the description is incomplete. No annotations or output schema exist to clarify behavior or results. It fails to address what happens post-disconnect, error conditions, or confirmation of success, leaving the agent with insufficient context.
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 parameter documentation is needed. The description doesn't add param details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
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 'Disconnect the wallet' clearly states the action (disconnect) and resource (wallet), but it's vague about what 'disconnect' entails—does it log out, clear session, or revoke permissions? It distinguishes from siblings like 'get-connect-uri' or 'show-connect-qrcode', but lacks specificity compared to tools like 'sign-message' or 'send-transaction'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must be connected first), exclusions, or related tools like 'get-connect-uri' for reconnection. The context is implied from the tool name alone, but explicit usage instructions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool estimates fees for likely inclusion in the next block, which is useful, but lacks details on rate limits, error handling, network dependencies, or output format. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with the main action ('Estimate for the fees per gas') and includes essential context ('in wei', 'for a transaction to be likely included in the next block'), making it highly concise and effective.
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 fee estimation in blockchain contexts, no annotations, and no output schema, the description is incomplete. It lacks information on what the output includes (e.g., base fee, priority fee), how estimates are derived, potential inaccuracies, or dependencies on network conditions. For a tool with significant contextual needs, this description does not provide sufficient completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('chainId' and 'formatUnits'). The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'chainId' affects the estimate or the implications of 'formatUnits'. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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: 'Estimate for the fees per gas (in wei) for a transaction to be likely included in the next block.' It specifies the verb ('estimate'), resource ('fees per gas'), and context ('for a transaction to be likely included in the next block'). However, it does not explicitly differentiate from sibling tools like 'estimate-gas', which estimates gas usage rather than fees, leaving room for confusion.
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 on when to use this tool. It implies usage when estimating fees for transaction inclusion, but does not specify alternatives (e.g., vs. 'estimate-gas' for gas usage) or exclusions (e.g., not for historical data). No explicit when-to-use or when-not-to-use instructions are given, relying on implicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool fetches information but does not describe what information is returned (e.g., block details like timestamp, transactions), error conditions (e.g., invalid hash), performance traits (e.g., rate limits), or side effects. This is inadequate for a read operation 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, efficient sentence that front-loads the core purpose ('Fetch information about a block') and specifies the input options. There is no wasted wording, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 does not explain what information is fetched (e.g., block header data, transactions), return format, or error handling. For a tool with four parameters and no structured output documentation, more context is needed to guide effective use 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%, so the schema fully documents the four parameters (chainId, blockHash, blockNumber, blockTag) with descriptions and enum values. The description adds minimal value by listing the three block identifier types (number, hash, tag) but does not provide additional semantics beyond what the schema already covers, such as usage examples or constraints.
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 ('Fetch information about a block') and specifies the resource ('a block'), with three alternative identifiers (block number, hash, or tag). However, it does not explicitly distinguish this tool from sibling tools like 'get-block-number' or 'get-transaction', which also retrieve blockchain data but for different resources.
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 mentions three input methods (block number, hash, or tag) but does not specify which to prefer, prerequisites, or exclusions. For example, it does not clarify if this is for general block data retrieval compared to 'get-block-number' (which might only return the number) or 'get-transaction' (for transaction details).
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. 'Get' implies a read operation, but the description doesn't specify whether this requires authentication, returns paginated results, has rate limits, or what format the output takes. This leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. For a tool that presumably returns configuration data about blockchain chains, the description should clarify what 'configured' means, what information is returned, and how this differs from similar sibling tools. The current description leaves too much ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description appropriately doesn't attempt to add parameter information beyond what's already clear from the schema, which is correct for a parameterless tool.
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 configured chains' clearly states the action (get) and resource (configured chains), but it's somewhat vague about what 'configured chains' means in this context. It doesn't differentiate from sibling tools like 'get-chain-list' or 'get-chain-id', which appear to serve related but distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-chain-list' or 'get-chain-id'. There's no mention of prerequisites, context, or exclusions that would help an agent choose appropriately among these similar-sounding tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't mention potential side effects, rate limits, authentication needs, or what happens with invalid addresses. 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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to grasp immediately.
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 doesn't explain what the balance return value includes (e.g., units, decimals), error handling, or network context, which are crucial for effective 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?
The schema description coverage is 100%, with the single parameter 'address' documented in the schema as 'Address to get balance for.' The description adds no additional meaning beyond this, such as format examples or constraints, but the schema provides adequate baseline information.
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 ('native currency balance of an address'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get-token-balance' or 'get-account', which might handle similar balance queries but for different resources.
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 such as 'get-token-balance' for non-native currencies or 'get-account' for broader account info. The description lacks context about prerequisites, exclusions, or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states what the tool does, not how it behaves. It doesn't mention whether this is a read-only operation, what network/chain it queries, potential rate limits, error conditions, or what format the balance is returned in.
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 immediately. Every word earns its place with zero wasted text or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how to interpret the balance value, what networks/chains it works with, or any error scenarios - leaving significant gaps for an AI agent to understand 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?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description doesn't add any additional semantic context beyond what's in the schema - it doesn't clarify what type of addresses are valid, whether the token must be ERC-20, or provide examples.
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 token balance') and resource ('of an address'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'get-native-currency-balance' which serves a similar purpose for native currency rather than tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-native-currency-balance' or 'get-account'. There's no mention of prerequisites, context, or comparison with sibling tools that might provide similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, what happens if the transaction doesn't exist, what data format is returned, or any rate limits or authentication requirements. 'Fetch' implies read-only, but this isn't explicitly confirmed.
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 7 words, with zero wasted language. It's front-loaded with the core purpose and doesn't include unnecessary elaboration. Every word serves a clear purpose in communicating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what transaction data is returned, error conditions, or how this differs from get-transaction-receipt. Given the complexity of blockchain transactions and the sibling tools available, more context is needed for 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 fully documents both parameters. The description mentions 'hash or block identifiers' which implies the hash parameter, but doesn't add meaningful context beyond what the schema provides. The description doesn't explain the relationship between hash and chainId parameters or provide usage examples.
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 ('fetch') and resource ('transaction'), and specifies the input criteria ('given hash or block identifiers'). It distinguishes from siblings like get-transaction-receipt by focusing on transaction data rather than receipt data. However, it doesn't explicitly differentiate from get-block which might also provide transaction 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use get-transaction-receipt instead, or clarify the relationship with get-block which might contain transaction 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 full burden. It states the tool fetches a receipt but doesn't disclose behavioral traits like error handling (e.g., if hash is invalid or transaction pending), performance (e.g., latency, rate limits), or output format (e.g., JSON structure). This is inadequate for a tool with potential complexity in blockchain contexts.
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 fluff. It's front-loaded and appropriately sized for a simple fetch operation, 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 no annotations and no output schema, the description is incomplete. It doesn't cover what a transaction receipt contains (e.g., status, logs, gas used), error scenarios, or dependencies (e.g., transaction must be confirmed). For a blockchain tool with potential nuances, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (hash and chainId). The description adds minimal value beyond the schema, only implying the hash parameter's purpose. It doesn't explain parameter interactions (e.g., chainId defaults or validation) or provide examples, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('Transaction Receipt'), specifying it requires a transaction hash. It distinguishes from sibling tools like 'get-transaction' (which fetches transaction details) and 'wait-for-transaction-receipt' (which waits for receipt availability). However, it doesn't explicitly mention the chain ID parameter, slightly limiting 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. It doesn't mention prerequisites (e.g., transaction must be mined), compare with 'get-transaction' or 'wait-for-transaction-receipt', or specify use cases like verifying transaction success. This leaves the agent without context for 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 the full burden of behavioral disclosure. It states what the tool does but doesn't explain how it behaves—for example, whether it displays the QR code visually, returns it as data, requires specific permissions, or has side effects. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently conveys the essential information, 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 the lack of annotations and output schema, the description is incomplete for a tool that likely involves visual or data output (QR code). It doesn't explain what 'Show' entails—e.g., whether it returns an image, text, or triggers a display—or address potential complexities like error handling. This leaves the agent with insufficient context for 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 schema description coverage is 100%, with the single parameter 'uri' documented as 'Connect URI'. The description adds no additional meaning beyond this, such as format examples or usage context. Since the schema handles the parameter documentation adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Show') and the resource ('connect QR code for a given connect URI'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-connect-uri' or explain what a 'connect QR code' is used for in this context, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 how it relates to 'get-connect-uri' or other sibling tools. It lacks context about prerequisites, timing, or exclusions, leaving usage unclear beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions waiting for inclusion and confirmations, but lacks details on timeouts, error handling, polling behavior, or what happens if the transaction fails. For a tool that involves waiting and potentially blocking operations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. Every word earns its place: 'Waits for the transaction to be included on a block' sets the action, and 'returns the transaction receipt' specifies the outcome. No waste or redundancy.
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 waiting for blockchain transactions, no annotations, and no output schema, the description is incomplete. It doesn't explain the return value (transaction receipt structure), error conditions, or behavioral nuances like polling intervals. For a tool with 3 parameters and significant operational implications, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (hash, confirmations, chainId). The description adds no additional meaning beyond what's in the schema, such as explaining the relationship between confirmations and block inclusion or 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: 'Waits for the transaction to be included on a block, and then returns the transaction receipt.' It specifies the verb ('waits for'), resource ('transaction'), and outcome ('returns the transaction receipt'). However, it doesn't explicitly differentiate from sibling tools like 'get-transaction-receipt' or 'wait-seconds', which would require 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. It doesn't mention sibling tools like 'get-transaction-receipt' (which might fetch a receipt without waiting) or 'wait-seconds' (which waits for time rather than transaction confirmation), nor does it specify prerequisites or exclusions. Usage is implied but not explicitly stated.
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. 'Get' implies a read operation, but it doesn't disclose whether this requires authentication, what data is returned, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and immediately states the core functionality 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 lack of annotations and output schema, the description should provide more context about what 'current account' means in this blockchain context and what data is returned. The simple statement is inadequate for a tool that likely returns important account information like address, balance, or chain details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters, earning a baseline score of 4 for this situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current account', making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'get-native-currency-balance' or 'get-token-balance' which also retrieve account-related information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get-native-currency-balance' and 'get-token-balance' that retrieve specific account data, there's no indication of what 'current account' means or when this general tool is preferred over more specific ones.
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 for behavioral disclosure. It mentions fetching the 'most recent block seen,' which implies read-only behavior and possibly real-time data, but doesn't clarify latency, error conditions, permissions needed, or if it's cached vs. live. For a tool with no annotations, this leaves significant gaps in understanding its 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 directly states the tool's function. It's appropriately sized for a simple tool and front-loaded with the essential action, making it 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 (1 parameter, no output schema, no annotations), the description is minimally adequate but has clear gaps. It explains the basic purpose but lacks usage guidelines, behavioral details, and output information. For a read operation in a blockchain context, more context on reliability or typical use cases would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'chainId' well-documented in the schema as 'ID of chain to use when fetching data.' The description doesn't add any extra meaning about parameters beyond what the schema provides, such as default behavior if omitted or example values. Given high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('number of the most recent block seen'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-block' (which retrieves full block data) or 'get-chain-id' (which gets chain identifier), 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain if this is for quick status checks versus detailed block analysis (which might use 'get-block'), or mention prerequisites like needing a connected chain. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the action ('Get') but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires network connectivity, potential errors, or response format. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (simple read operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'chain id' means in this context, the return value, or any error conditions, leaving gaps for the agent to infer.
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 the schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any gaps.
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 current chain id' clearly states the verb ('Get') and resource ('current chain id'), making the purpose immediately understandable. However, it doesn't differentiate from siblings like 'get-chain-list' or 'get-chains' which might return multiple chains or chain information, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-chain-list' or 'get-chains', nor does it mention any prerequisites or context for usage. It's a basic statement of function without operational 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 the full burden of behavioral disclosure. It only states the action ('Get a list') without detailing aspects like whether it's read-only, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps for a tool that likely 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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words or fluff. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 tools and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'chains information' includes, how the list is formatted, or any behavioral traits, leaving the agent with incomplete context for proper use.
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 the schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description doesn't need to compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of all chains information'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-chains' or 'get-chain-id', which appear to be related, so it lacks sibling distinction 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 like 'get-chains' or 'get-chain-id', nor does it mention any prerequisites or exclusions. It merely states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic function but doesn't describe error conditions (e.g., invalid names, network failures), performance characteristics (e.g., latency, rate limits), or what happens with optional parameters (chainId, blockNumber). For a tool with 3 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple lookup tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is minimally complete. It states what the tool does but lacks details on behavior, error handling, and output format. For a lookup tool in a blockchain context, more context about typical use and limitations would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (name, chainId, blockNumber). The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate but minimal value addition from the description regarding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetch') and resource ('ENS address for name'), making the purpose immediately understandable. It distinguishes from sibling 'get-ens-name' which performs the reverse lookup. However, it doesn't specify what type of address (e.g., Ethereum address) is returned, 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?
The description provides no guidance on when to use this tool versus alternatives like 'get-account' or 'get-ens-name'. It doesn't mention prerequisites (e.g., needing an ENS name) or typical use cases (e.g., resolving human-readable names to addresses). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'fetch' which implies a read operation, but doesn't disclose behavioral traits like whether it requires network connectivity, rate limits, error conditions (e.g., if no ENS name exists), or what 'primary' means specifically. The description is minimal and lacks context about the operation's characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Fetch the primary ENS name for address'). There is zero wasted text, and it directly communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on behavior, usage, or output. Without annotations or output schema, the agent has incomplete information about what the tool returns or how it behaves, though the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (address, chainId, blockNumber). The description adds no parameter-specific information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding but doesn't need to compensate for gaps.
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 ('fetch') and resource ('primary ENS name for address'), making the purpose immediately understandable. It distinguishes from sibling 'get-ens-address' which performs the inverse operation. However, it doesn't specify that this fetches the reverse resolution (address → name) versus forward resolution, though the distinction from the sibling tool is implied.
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 address), exclusions, or compare it to similar tools like 'get-ens-address' (which gets address for name). The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Wait') but doesn't describe what happens during the wait (e.g., blocking behavior, async handling), error conditions, or performance implications like maximum allowed seconds. This leaves significant gaps for a tool that controls execution flow.
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, direct sentence that front-loads the core functionality. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse.
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 role in controlling execution timing and the lack of annotations or output schema, the description is insufficient. It doesn't explain what 'Wait' entails operationally (e.g., whether it blocks other actions), return values, or error handling, which are critical for an agent to use it correctly in a workflow.
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 description adds meaningful context for the single parameter by specifying it represents 'seconds' to wait, which clarifies the unit and purpose beyond the schema's generic 'number' type. With 0% schema description coverage and only one parameter, this adequately compensates, though it doesn't detail constraints like minimum/maximum values.
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 with a specific verb ('Wait') and resource ('the given seconds'), making it immediately understandable. However, it doesn't differentiate from the sibling tool 'wait-for-transaction-receipt', which serves a similar waiting function but with different context and parameters.
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 'wait-for-transaction-receipt' or general timing operations. It lacks context about appropriate scenarios, prerequisites, 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?
No annotations are provided, so the description carries the full burden. It mentions the tool executes 'without submitting a transaction', implying it's non-destructive and likely read-only, but doesn't clarify key behaviors: whether it requires authentication, has rate limits, returns simulation results or errors, or how it handles gas estimation. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Executing a new message call') and adds crucial context ('immediately without submitting a transaction'). There is zero waste, and every word earns its place.
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 interactions, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., simulation results, contract state), error conditions, or prerequisites (e.g., network connection). For a tool with 3 parameters and significant behavioral implications, this leaves too much unspecified.
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 three parameters ('to', 'data', 'value') with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. 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 action ('Executing a new message call') and distinguishes it from submitting a transaction to the network. It specifies the immediate execution aspect, which helps differentiate from sibling tools like 'send-transaction' or 'write-contract'. However, it doesn't explicitly mention what a 'message call' is or its typical use cases (e.g., reading contract state).
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 when to use this tool ('immediately without submitting a transaction') versus alternatives like 'send-transaction', suggesting it's for read-only or simulation purposes. However, it lacks explicit guidance on when NOT to use it (e.g., for state-changing operations) or detailed comparisons with siblings like 'read-contract' or 'estimate-gas'.
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 but only states what the tool does without disclosing behavioral traits like whether it requires user interaction, returns a URI format, or has any side effects. It's minimal and lacks crucial operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, efficiently conveying the core purpose. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is adequate as a basic statement but incomplete for practical use. It doesn't explain what the URI is used for, how it's returned, or integration details, leaving gaps in context.
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 parameter documentation is needed. The description doesn't add param info, which is acceptable here, but it could have clarified output semantics, though that's not required for this dimension.
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 ('connect URI'), specifying it's for connecting to a MetaMask wallet. However, it doesn't differentiate from sibling tools like 'show-connect-qrcode', which might serve a similar purpose, leaving some ambiguity about uniqueness.
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, such as 'show-connect-qrcode' or other connection-related tools. The description lacks context about prerequisites or scenarios, offering no help 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?
No annotations are provided, so the description carries the full burden. It states the tool's function but lacks behavioral details: it doesn't specify what 'verify' entails (e.g., cryptographic validation, return format, error conditions), whether it's read-only or has side effects, or any performance/security considerations. This 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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, 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 the complexity (cryptographic verification), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what verification entails, the return value (e.g., boolean success/failure), error handling, or cryptographic standards used, leaving the agent with insufficient context 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?
Schema description coverage is 100%, so the schema already documents all three parameters (address, message, signature) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as format details or examples, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('verify') and resource ('message'), with the qualification 'was signed by the provided address' distinguishing it from generic verification. It directly contrasts with the sibling tool 'sign-message', which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: verifying a signature against a message and address, suggesting it's for authentication or integrity checks. However, it doesn't explicitly state when to use this versus alternatives (e.g., other verification methods) or any prerequisites, leaving some guidance implicit rather than explicit.
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 without submitting, which implies it's read-only and non-destructive, but doesn't mention potential limitations like network dependency, error conditions, or whether it requires specific permissions. 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 a single, efficient sentence that immediately conveys the core purpose without any wasted words. It's perfectly front-loaded with the essential information, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks information about return values, error handling, or network requirements. Without annotations or output schema, the agent must infer behavioral details, making this description incomplete for optimal tool selection.
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-specific information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 6 parameters. According to the rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('estimate the gas necessary') and resource ('to complete a transaction'), distinguishing it from siblings like 'send-transaction' (which submits) and 'estimate-fee-per-gas' (which estimates fees rather than total gas). It explicitly mentions 'without submitting it to the network', which clarifies its non-executive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('without submitting it to the network'), implying it's for pre-transaction planning. However, it doesn't explicitly state when not to use it or name alternatives like 'send-transaction' for actual execution, which would have earned a perfect score.
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:

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

Score Badge

Copy to your README.md:

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

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/Xiawpohr/metamask-mcp'

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