The MCP Ethers Wallet server provides a standardized interface for interacting with Ethereum wallets, networks, and smart contracts using Ethers.js v6.
Query Blockchain Data: Get network information, block details, gas prices, and fee data
Wallet Operations: Manage wallets, check balances (ETH and ERC20), retrieve transaction counts
Transaction Management: Send transactions, get transaction details, and manage transactions within blocks
Smart Contract Interaction: Call contract methods (read/write), get bytecode, query events and logs
ENS Operations: Resolve ENS names and addresses
Unit Conversion: Convert between wei and ether, format/parse units
Advanced Features: Sign messages, send pre-signed raw transactions, customize gas settings
Cross-Network Support: Works with multiple Ethereum-compatible networks
Provides API key-based access to Ethereum networks, serving as a node provider for blockchain interactions.
Enables comprehensive interaction with Ethereum networks, including querying blockchain data, managing wallets, sending transactions, and interacting with smart contracts.
Utilizes Ethers.js v6 as the core library for blockchain interactions, providing standardized interfaces for wallet management, smart contract interaction, and transaction handling.
Supports interaction with the Optimism network, allowing for blockchain queries, wallet operations, and transaction management on this Ethereum L2 solution.
Enables interaction with Polygon PoS network, providing tools for blockchain queries, wallet operations, and transaction management on this Ethereum scaling solution.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Ethers Wallet get Vitalik's ETH balance on mainnet"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
⚡ Claude Code Setup:
claude mcp add ethers-wallet -- node /path/to/ethers-server/build/src/index.jsA complete ethers.js v6 wrapper for Claude with 40+ tools for Ethereum blockchain interactions. Works with 20+ EVM networks including Ethereum, Polygon, Arbitrum, Base, and more.
Network info • Block/transaction data • Wallet operations • Gas estimation • ENS resolution • Message signing • Unit conversion
ERC20: Token info, balances, transfers, approvals
ERC721: NFT info, ownership, transfers, metadata
ERC1155: Multi-token balances, transfers, batch operations
Transaction preparation • ERC20/721/1155 transaction prep • Secure transaction broadcasting • Gas optimization
Smart contract calls • Contract code inspection • Custom ABI support
Related MCP server: EVM MCP Server
# Get Vitalik's ETH balance
"getWalletBalance": {
"address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
"provider": "mainnet"
}
# Get USDC token info
"erc20GetTokenInfo": {
"tokenAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"provider": "mainnet"
}git clone https://github.com/yourusername/ethers-server.git
cd ethers-server
npm install
npm run buildCreate .env file:
ALCHEMY_API_KEY=your_alchemy_key
INFURA_API_KEY=your_infura_key
DEFAULT_NETWORK=mainnetclaude mcp add --scope local ethers-wallet --env ALCHEMY_API_KEY=your_key -- node /path/to/build/src/index.jsclaude mcp add --scope project ethers-wallet -- node /path/to/build/src/index.js🔐 Secure by Design: Uses prepare → sign → send workflow. Private keys never stored on server. External signing supported (hardware wallets, offline signing).
⚠️ API Keys: Protect your .env file. Never expose Alchemy/Infura keys.
Built with ethers.js v6 for maximum compatibility and performance. Full TypeScript support with comprehensive error handling.
Testing: npm test (requires Hardhat local node)
Build: npm run build
Contributions welcome! See our comprehensive test suite and follow existing code patterns.
MIT License - Dennison Bertram (dennison@tally.xyz)
🚀 Production Ready: Successfully validated with live Ethereum mainnet transactions. Complete MCP server with 40+ tools for all your Web3 needs.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| tokenId | Yes | ||
| approved | Yes | ||
| provider | No | ||
| chainId | No | ||
| gasOptions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the contract to call | |
| abi | Yes | The ABI of the contract function to call, in JSON format | |
| method | Yes | The name of the method to call | |
| args | No | Optional. The arguments to pass to the contract function | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC1155 contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC1155 contract | |
| ownerAddress | Yes | The address to check balance for | |
| tokenId | Yes | The ID of the token to query | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenAddress | Yes | The address of the ERC1155 contract | |
| ownerAddresses | Yes | Array of addresses to check balances for | |
| tokenIds | Yes | Array of token IDs to check balances for | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenAddress | Yes | The address of the ERC1155 contract | |
| tokenId | Yes | The ID of the token to query | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the ERC20 token balance for a specific address. Alternative naming for compatibility with MCP client tests.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| ownerAddress | Yes | The Ethereum address whose balance to check | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
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 'Get[s] the ERC20 token balance,' implying a read-only operation, but doesn't mention any behavioral traits like authentication needs, rate limits, error conditions, or what the return format looks like (e.g., numeric balance, units). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated clearly in the first sentence. The second sentence about 'Alternative naming for compatibility' adds context but could be considered slightly extraneous. Overall, it's efficient with minimal waste, though not perfectly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain interactions and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., balance format, units), potential errors, or dependencies like network connectivity. For a tool with 5 parameters and no structured output information, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond the schema—it doesn't explain parameter relationships, usage examples, or constraints. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the ERC20 token balance for a specific address.' It includes a specific verb ('Get') and resource ('ERC20 token balance'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getERC20Balance' or 'getWalletBalance', which likely serve similar purposes, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'Alternative naming for compatibility with MCP client tests,' which hints at redundancy but doesn't clarify which sibling tools (e.g., 'getERC20Balance') are preferred or when to choose this one. Without explicit when/when-not instructions or named alternatives, the score is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about an ERC20 token including its name, symbol, decimals, and total supply. Alternative naming for compatibility with MCP client tests.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
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 describes a read-only operation ('Get detailed information'), which implies non-destructive behavior, but doesn't mention potential errors (e.g., invalid addresses), rate limits, authentication needs, or response format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated in the first sentence. The second sentence about 'Alternative naming' is somewhat tangential but may serve a purpose for compatibility. Overall, it's efficient with minimal waste, though the second sentence could be more directly helpful to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interacting with blockchain tokens), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., JSON structure), error conditions, or how it integrates with sibling tools like 'getAllNetworks' for provider details. For a tool in this context, more behavioral and output guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'contractAddress' differs from 'tokenAddress' beyond deprecation or clarify 'provider' usage). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about an ERC20 token including its name, symbol, decimals, and total supply.' It specifies the verb ('Get') and resource ('ERC20 token') with concrete examples of information returned. However, it doesn't explicitly differentiate from sibling tools like 'getERC20TokenInfo' or 'getERC20Balance', which appear to offer similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Alternative naming for compatibility with MCP client tests,' which hints at a technical reason for duplication but doesn't help an agent decide between this tool and 'getERC20TokenInfo' or other token-related tools. No explicit when/when-not instructions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of ERC721 NFTs owned by a specific address. Alternative naming for compatibility with MCP client tests.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenAddress | Yes | The address of the ERC721 contract | |
| ownerAddress | Yes | The address to check balance for | |
| provider | No | Optional. The provider to use. If not provided, the default provider is used. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what the return value looks like (e.g., integer count). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence directly states the purpose, and the second adds useful context about naming compatibility. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns a numeric value. It covers the basic purpose but lacks information about return format, error handling, or dependencies. For a read-only tool with rich schema but no output schema, it should ideally describe what the agent can expect as a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly with patterns and descriptions. The description doesn't add any parameter semantics beyond what's in the schema, such as explaining relationships between parameters or usage examples. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the number') and resource ('ERC721 NFTs owned by a specific address'), distinguishing it from sibling tools like erc20_balanceOf, getNFTInfo, or getNFTOwner. It explicitly identifies the ERC721 token type and balance-checking function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking NFT balances but doesn't explicitly state when to use this tool versus alternatives like erc1155_balanceOf, getNFTInfo, or getNFTOwner. It mentions 'Alternative naming for compatibility' which hints at context but doesn't provide clear when/when-not guidance or named alternatives for similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenAddress | Yes | The address of the ERC721 contract | |
| tokenId | Yes | The ID of the token to get the URI for | |
| provider | No | Optional. The provider to use. If not provided, the default provider is used. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The data to sign. Will be converted to hex if not already in hex format. | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| wei | Yes | The wei value to format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The value to format | |
| unit | Yes | The number of decimals or unit name (e.g., 'gwei', 18) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| saveToEnv | No | Optional. If true, the private key will be saved to the server's environment variables for future use. Default is false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all available blockchain networks. Use this to identify network names, chain IDs, and RPC URLs that can be used with other Ethereum tools. When using other tools with a 'provider' parameter, you can specify any of these network names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns (network information) and its purpose (identification for other tools), but doesn't disclose behavioral traits like whether this is a cached list, real-time network discovery, rate limits, authentication requirements, or error conditions. The description is accurate but lacks 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and output, the second provides explicit usage guidance. Every word adds value with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description provides good context about what information is returned and how to use it. However, it doesn't describe the format or structure of the returned network information (e.g., array of objects with specific fields), which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and output. This meets the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get information about all available blockchain networks') and identifies the resources returned ('network names, chain IDs, and RPC URLs'). It distinguishes this tool from sibling tools like 'getNetwork' (singular) by emphasizing it retrieves information about ALL networks, not just one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this to identify network names... that can be used with other Ethereum tools') and provides a specific usage context ('When using other tools with a 'provider' parameter, you can specify any of these network names'). It clearly differentiates this from tools that perform operations on specific networks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| blockTag | Yes | The block number or the string 'latest' | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The contract's address | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get guidance for resolving ENS names across networks and performing operations
| Name | Required | Description | Default |
|---|---|---|---|
| ensName | Yes | The ENS name to resolve (e.g., 'vitalik.eth') | |
| targetNetwork | Yes | The target network to perform operations on (e.g., 'MEGA Testnet', 'Optimism') | |
| operation | Yes | The operation to perform: 'balance' for ETH balance, 'txCount' for transaction count, 'code' for contract code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'guidance' but does not clarify what that entails—whether it returns instructions, metadata, or actionable data. It lacks details on permissions, rate limits, or behavioral traits like whether it's read-only or has side effects, which 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the purpose without unnecessary words. It is front-loaded and appropriately sized, though it could be more specific to enhance clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 3 required parameters and complex operations. It does not explain what 'guidance' returns, how to interpret results, or handle errors, leaving significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or providing examples. Baseline is 3 when schema does the heavy lifting, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get guidance for resolving ENS names across networks and performing operations', which provides a general purpose but lacks specificity about what 'guidance' means or what operations are available. It distinguishes from siblings like 'resolveName' by mentioning 'guidance', but the distinction is vague rather than clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'resolveName' or other ENS-related tools. The description implies usage for ENS resolution and operations, but does not specify contexts, prerequisites, or exclusions, leaving the agent to infer based on 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.
Get the amount of tokens that a spender is approved to spend on behalf of a token owner. Used to check ERC20 approval amounts.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| ownerAddress | Yes | The Ethereum address that owns the tokens | |
| spenderAddress | Yes | The Ethereum address that is approved to spend tokens | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
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 is for 'checking' approval amounts, implying a read-only operation, but does not disclose behavioral traits such as whether it requires network connectivity, potential rate limits, error conditions, or the format of the returned allowance. The description is too brief to provide adequate behavioral context for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and has zero waste. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is incomplete. It does not explain what the tool returns (e.g., numeric allowance, units), error handling, or dependencies on other tools like 'getAllNetworks' for provider values. For a read operation in a blockchain context, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain relationships between parameters like 'contractAddress' and 'tokenAddress', or how 'provider' and 'chainId' interact). 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the amount of tokens that a spender is approved to spend on behalf of a token owner.' It specifies the verb ('Get') and resource ('ERC20 allowance'), but does not explicitly differentiate from sibling tools like 'prepareERC20Approval' or 'getERC20Balance' beyond mentioning it's for checking approval amounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'Used to check ERC20 approval amounts.' It does not specify when to use this tool versus alternatives (e.g., 'prepareERC20Approval' for setting approvals, 'getERC20Balance' for balances) or any prerequisites. No explicit when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the ERC20 token balance for a specific address. Returns the balance amount along with the token symbol for easy reading.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| ownerAddress | Yes | The Ethereum address whose balance to check | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
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 return format (balance amount and token symbol) but fails to disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or error conditions. The description is insufficient for a tool with multiple parameters and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and return value without unnecessary details. It is front-loaded and wastes no words, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return format but lacks details on behavioral transparency, usage guidelines, and error handling. It meets the minimum viable threshold but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any meaningful semantic details beyond what the schema provides, such as explaining parameter interactions or usage examples. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the ERC20 token balance') and resource ('for a specific address'), and distinguishes it from siblings like 'erc20_balanceOf' by specifying it returns the balance amount along with the token symbol for easy reading, making the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'erc20_balanceOf' or 'getWalletBalance', nor does it mention prerequisites or exclusions. It lacks explicit usage context, relying solely on the tool's name and description for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about an ERC20 token including its name, symbol, decimals, and total supply. Requires the contract address of the token.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
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 retrieves information (implying a read-only operation) but doesn't mention potential errors (e.g., invalid addresses), rate limits, authentication needs, or network dependencies. For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and a key requirement. There's no wasted text, though it could be slightly more structured (e.g., separating usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on return values, error handling, network behavior, and differentiation from siblings. Without annotations or output schema, more context is needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by implying the 'contractAddress' is required, but doesn't provide additional context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about an ERC20 token including its name, symbol, decimals, and total supply.' It specifies the verb ('Get') and resource ('ERC20 token') with concrete data fields. However, it doesn't distinguish from sibling tools like 'erc20_getTokenInfo' or 'getERC20Balance', which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions 'Requires the contract address of the token,' which is a prerequisite but not a contextual guideline. There's no explicit advice on when to use this tool versus alternatives like 'erc20_getTokenInfo' or 'getERC20Balance', nor any exclusions or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific blockchain network. This provides the network's chain ID, native token, and RPC URL that can be used with other Ethereum tools. This network name can be used as the 'provider' parameter in other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the network to get details for (case-insensitive, e.g., 'ethereum', 'polygon', 'arbitrum') |
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 discloses that the tool returns specific details (chain ID, native token, RPC URL) and mentions a use case for the output, but it lacks information on error handling, rate limits, authentication needs, or whether it's a read-only operation. The description does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded with the main purpose, followed by details and a use case. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It clearly explains what the tool does and its output's utility. However, it could improve by mentioning error cases or behavioral traits, as no annotations are provided to cover those aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'name'. The description adds value by specifying the type of information returned (chain ID, native token, RPC URL) and a use case for the output, which helps the agent understand the tool's purpose beyond the parameter definition. With 0 parameters beyond the schema, this exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get detailed information') and resource ('about a specific blockchain network'), distinguishing it from sibling tools like getAllNetworks or getSupportedNetworks by focusing on a single network's details rather than listing multiple networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to get detailed information about a specific blockchain network') and hints at its utility ('This network name can be used as the 'provider' parameter in other tools'), but it does not explicitly state when not to use it or name specific alternatives like getAllNetworks for broader listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about an ERC721 NFT collection including its name, symbol, and total supply. Provides basic details about the NFT contract.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC721 contract | |
| provider | No | Optional. The provider to use. If not provided, the default provider is used. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states this is a read operation ('Get information'), it doesn't mention important behavioral aspects like whether this requires network access, potential rate limits, error conditions, or what format the returned information takes. For a tool that presumably queries blockchain data, this lack of behavioral context is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently convey the core functionality. The first sentence states the purpose and key data returned, while the second provides additional context about the type of contract. There's no unnecessary verbiage, though it could be slightly more structured to separate purpose from behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (blockchain data retrieval), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't explain what specific information is returned beyond mentioning 'name, symbol, and total supply,' nor does it address error handling, network requirements, or how the optional parameters affect behavior. For a tool with no structured output definition, more descriptive completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's already in the schema. With 100% schema description coverage, all three parameters (contractAddress, provider, chainId) are already documented in the input schema. The description doesn't provide additional context about parameter usage, relationships between parameters, or examples of valid values beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about an ERC721 NFT collection including its name, symbol, and total supply.' It specifies the verb ('Get'), resource ('ERC721 NFT collection'), and key data fields. However, it doesn't explicitly distinguish this tool from similar siblings like 'getNFTMetadata' or 'getERC20TokenInfo', which reduces clarity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getNFTMetadata', 'getNFTOwner', and 'getNFTTokenURI' available, there's no indication of what makes this tool unique or when it should be preferred over those other NFT-related tools. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| tokenId | Yes | ||
| provider | No | ||
| chainId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current owner of a specific ERC721 NFT token. Returns the Ethereum address that owns the specified token ID.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC721 contract | |
| tokenId | Yes | The ID of the token to check | |
| provider | No | Optional. The provider to use. If not provided, the default provider is used. | |
| chainId | No | Optional. The chain ID to use. |
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 return type ('Ethereum address') but lacks details on error conditions, rate limits, authentication requirements, or whether this is a read-only operation (though implied by 'Get'). More behavioral context is needed 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that directly state the purpose and return value. Every word earns its place, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and return type but lacks usage guidelines, error handling, and behavioral details that would help an agent use it correctly in context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the relationship between contractAddress and tokenId). 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the current owner') and resource ('specific ERC721 NFT token'), distinguishing it from siblings like getNFTInfo or getNFTMetadata that provide different information. It precisely defines what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the purpose is clear, there's no mention of when to choose it over similar tools like getNFTInfo (which might include owner data) or how it relates to other NFT-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC721 contract | |
| tokenId | Yes | The ID of the token to get the URI for | |
| provider | No | Optional. The provider to use. If not provided, the default provider is used. | |
| chainId | No | Optional. The chain ID to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all supported networks and their configurations. For more detailed information about networks, use the getAllNetworks and getNetwork tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 describes what the tool returns (a list of networks and configurations) but lacks details about response format, pagination, rate limits, authentication requirements, or error conditions. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides valuable usage guidance. There is no wasted text or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters), no annotations, and no output schema, the description is adequate but incomplete. It explains what the tool does and when to use it, but lacks details about the return format, behavioral constraints, or error handling that would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters, and it doesn't add any parameter-specific information beyond what the schema already provides (which is none needed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('list of all supported networks and their configurations'). It distinguishes from sibling tools by mentioning alternatives for more detailed information, though it doesn't explicitly differentiate from all similar tools like 'getAllNetworks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating when to use this tool (for a list of networks and configurations) and when to use alternatives ('getAllNetworks' and 'getNetwork' for more detailed information). However, it doesn't explicitly state when NOT to use this tool or compare it to all relevant siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | The transaction hash to lookup | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The Ethereum address to query | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The Ethereum address to query | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available prompts in the system
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose details like pagination, rate limits, authentication needs, or return format. 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.
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 and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and the tool's simplicity (0 params), the description is minimal. It covers the basic purpose but lacks behavioral context (e.g., what 'prompts' are, how results are returned), making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add param details, but this is acceptable given the lack of parameters, aligning with the baseline for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available prompts in the system' clearly states the verb ('List') and resource ('prompts'), with 'all available' specifying scope. However, it doesn't differentiate from sibling tools, which are unrelated blockchain/transaction tools, so no explicit distinction is needed but could be implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or exclusions, such as whether it requires authentication or if there are filtering options elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| privateKey | Yes | The private key of the wallet to load. Should start with '0x'. | |
| saveToEnv | No | Optional. If true, the private key will be saved to the server's environment variables for this session. Default is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The Ethereum address to resolve | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| ether | Yes | The ether value to parse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a smart contract interaction transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The smart contract address to interact with | |
| data | Yes | The contract interaction data (encoded function call) as hex string | |
| value | No | Optional. The amount of ETH to send with the transaction (default: '0') | 0 |
| fromAddress | Yes | The Ethereum address sending the transaction | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. | |
| gasLimit | No | Optional. The gas limit for the transaction | |
| gasPrice | No | Optional. The gas price (in gwei) for legacy transactions | |
| maxFeePerGas | No | Optional. The maximum fee per gas (in gwei) for EIP-1559 transactions | |
| maxPriorityFeePerGas | No | Optional. The maximum priority fee per gas (in gwei) for EIP-1559 transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states the tool 'returns transaction data that can be signed and broadcast,' it doesn't address critical behavioral aspects: whether this is a read-only operation (likely, since it only prepares), what happens if parameters are invalid, whether it performs any validation of contract addresses or data, or if there are rate limits. For a tool with 10 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise: two clear sentences that state the action and outcome without unnecessary words. It's front-loaded with the core purpose and wastes no space on repetition or irrelevant details. Every sentence earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the returned transaction data contains, how to use it with signing/broadcasting tools, error conditions, or dependencies on other tools (like getAllNetworks for provider values). The context signals indicate high complexity that isn't adequately addressed by the brief description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters (e.g., gasPrice vs maxFeePerGas for different transaction types), provide examples, or clarify when certain parameters are needed. With complete schema coverage, the baseline is 3, but the description doesn't enhance understanding of parameter usage or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Prepare a smart contract interaction transaction for signing.' It specifies the action (prepare), resource (smart contract interaction transaction), and outcome (returns transaction data for signing/broadcasting). However, it doesn't explicitly differentiate from sibling tools like 'prepareTransaction' or 'prepareERC20Transfer', which appear to serve similar preparation functions for different transaction types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple 'prepare*' sibling tools (prepareTransaction, prepareERC20Transfer, prepareERC721Transfer, etc.), there's no indication whether this is a general-purpose contract interaction tool or when to choose it over more specific preparation tools. The description mentions the outcome but not the appropriate context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an ERC1155 batch transfer transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC1155 contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC1155 contract | |
| fromAddress | Yes | The address sending the tokens | |
| toAddress | Yes | The address receiving the tokens | |
| tokenIds | Yes | Array of token IDs to transfer | |
| amounts | Yes | Array of amounts to transfer | |
| data | No | Additional data (default: '0x') | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. | |
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
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 prepares a transaction for signing but lacks critical details: whether it performs validation (e.g., balance checks, contract compatibility), if it estimates gas, what happens on errors, or if it requires network connectivity. For a transaction-preparation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core action. It avoids redundancy and wastes no words. However, it could be slightly more structured by explicitly separating purpose from output, but this is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, transaction preparation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return format (beyond 'transaction data'), error conditions, or dependencies (e.g., network state). For a tool that prepares blockchain transactions, this leaves 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 69%, with 13 parameters, 5 required. The description adds no parameter-specific information beyond what the schema provides. It mentions 'transaction data' but doesn't clarify parameter relationships (e.g., tokenIds/amounts array alignment, provider/chainId interaction) or defaults beyond schema hints. With moderate schema coverage, the baseline 3 is appropriate as the description doesn't compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Prepare an ERC1155 batch transfer transaction for signing' and specifies the output: 'Returns transaction data that can be signed and broadcast.' It distinguishes itself from sibling tools like prepareERC1155Transfer (single transfer) and prepareERC1155SetApprovalForAll (approval). However, it doesn't explicitly contrast with other batch-capable tools like prepareContractTransaction, leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., token ownership, approval status), compare with other transfer tools (e.g., prepareERC1155Transfer for single transfers, prepareContractTransaction for generic calls), or specify typical use cases. 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.
Prepare an ERC1155 setApprovalForAll transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC1155 contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC1155 contract | |
| operator | Yes | The address to approve/revoke for all tokens | |
| approved | Yes | Whether to approve (true) or revoke (false) | |
| fromAddress | Yes | The address that owns the tokens | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. | |
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'returns transaction data that can be signed and broadcast'. It doesn't disclose critical behavioral traits like whether this requires wallet connectivity, what happens if parameters are invalid, error conditions, or how the returned data should be used with signing/broadcast tools. For a transaction preparation tool with 11 parameters, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states the action and target, second states the return value and its purpose. Every word earns its place, and the most important information (what it does and what it returns) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex transaction preparation tool with 11 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the workflow (how the returned data integrates with signing/broadcasting), error handling, or behavioral constraints. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 64%, so the description must compensate but adds no parameter-specific information beyond what's implied by the tool name. It doesn't explain relationships between parameters (e.g., provider vs chainId, gas parameters) or clarify the deprecated tokenAddress. The baseline 3 reflects that schema does most documentation work, but the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Prepare an ERC1155 setApprovalForAll transaction for signing') and the outcome ('Returns transaction data that can be signed and broadcast'). It distinguishes from sibling tools like 'prepareERC1155Transfer' or 'setNFTApprovalForAll' by specifying the exact ERC1155 approval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when preparing an ERC1155 approval transaction for signing, but doesn't explicitly state when to use this vs alternatives like 'prepareERC721SetApprovalForAll' or 'setNFTApprovalForAll'. It mentions the return value purpose but lacks context about prerequisites or integration with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an ERC1155 token transfer transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC1155 contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC1155 contract | |
| fromAddress | Yes | The address sending the tokens | |
| toAddress | Yes | The address receiving the tokens | |
| tokenId | Yes | The ID of the token to query | |
| amount | Yes | The amount of tokens to transfer | |
| data | No | Additional data (default: '0x') | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. | |
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
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 prepares transaction data for signing and broadcasting, implying it's a read-only preparation step (not destructive). However, it doesn't disclose critical behavioral traits: whether it requires wallet connectivity, gas estimation behavior, network/provider requirements, error conditions, or what 'prepare' entails technically. The description is minimal beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: first states what it does, second states the output. No wasted words, though it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, blockchain transaction preparation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the transaction data structure returned, error handling, network dependencies, or how this fits into a signing/broadcasting workflow. For a tool with many parameters and no structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 69% (9 of 13 parameters have descriptions). The tool description adds no parameter-specific information beyond what's in the schema. It doesn't explain relationships between parameters (e.g., contractAddress vs tokenAddress deprecation, gas parameters interaction), default behaviors, or validation rules. With moderate schema coverage, the baseline 3 is appropriate as the description doesn't compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Prepare an ERC1155 token transfer transaction for signing' and specifies the output: 'Returns transaction data that can be signed and broadcast.' It distinguishes from siblings like prepareERC1155BatchTransfer (batch vs single) and prepareERC20Transfer (different token standard), but doesn't explicitly differentiate from prepareTransaction or prepareContractTransaction which are more generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose prepareERC1155Transfer over prepareERC1155BatchTransfer (for batch transfers), prepareTransaction (generic), or prepareContractTransaction (custom calls). No prerequisites, exclusions, or contextual advice are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an ERC20 token approval transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| spenderAddress | Yes | The Ethereum address to approve for spending tokens | |
| amount | Yes | The amount of tokens to transfer (can be decimal, e.g. '1.5') | |
| fromAddress | Yes | The Ethereum address that owns the tokens | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. | |
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool prepares a transaction for signing and returns data, it doesn't cover critical aspects like whether this is a read-only operation (likely not, as it prepares a transaction), potential gas costs, error conditions, or how it interacts with the blockchain. The description is minimal and misses key behavioral traits needed for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds output details in the second. It's efficient with zero wasted words, though it could be slightly more informative without losing conciseness. The structure is clear but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (ERC20 approval with 11 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the transaction's lifecycle (e.g., that it must be signed and broadcast separately), potential side effects, or error handling. For a tool that prepares blockchain transactions, this leaves significant gaps in understanding its full context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 64%, with 11 parameters (4 required). The description adds no parameter-specific information beyond what the schema provides (e.g., it doesn't explain the relationship between contractAddress and tokenAddress, or clarify gas parameter usage). Since schema coverage is moderate, the baseline is 3, as the description doesn't compensate for the coverage gap but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('prepare an ERC20 token approval transaction for signing') and resource ('ERC20 token'), distinguishing it from sibling tools like prepareERC20Transfer (which transfers tokens) or prepareERC721Approval (which handles NFTs). It explicitly mentions the output ('Returns transaction data that can be signed and broadcast'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it's for ERC20 token approvals, but doesn't explicitly state when to use this tool versus alternatives like prepareContractTransaction or prepareTransaction. It mentions the output can be 'signed and broadcast,' suggesting a multi-step workflow, but lacks clear guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an ERC20 token transfer transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | The address of the ERC20 token contract | |
| tokenAddress | No | DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract | |
| recipientAddress | Yes | The Ethereum address to receive the tokens | |
| amount | Yes | The amount of tokens to transfer (can be decimal, e.g. '1.5') | |
| fromAddress | Yes | The Ethereum address sending the tokens | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. | |
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't disclose that this is a read-only preparation step (not a broadcast), doesn't mention gas estimation or network requirements, and omits error conditions like insufficient balance. For a complex 11-parameter tool with financial implications, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that front-load the core purpose and output. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the transaction lifecycle, error handling, or relationship to signing/broadcasting tools. Given the high-stakes nature of token transfers, more contextual guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the 64% schema coverage by clarifying the output purpose ('transaction data that can be signed and broadcast'), which helps interpret parameters like gas fields. While it doesn't detail individual parameters, the high-level context compensates for schema gaps, especially given the 11 parameters involved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('prepare an ERC20 token transfer transaction for signing') and resource ('ERC20 token'), distinguishing it from sibling tools like prepareERC20Approval or prepareTransaction. It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it 'returns transaction data that can be signed and broadcast,' suggesting it's part of a multi-step process. However, it doesn't explicitly guide when to use this tool versus alternatives like prepareTransaction or sendTransaction, nor does it mention prerequisites like wallet loading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an ERC721 NFT approval transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| tokenId | Yes | ||
| approvedAddress | Yes | ||
| fromAddress | Yes | ||
| provider | No | ||
| chainId | No | ||
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'returns transaction data that can be signed and broadcast,' which clarifies it's a preparation step (non-destructive) and not an execution. However, it doesn't disclose critical behavioral traits like required permissions, gas estimation, network dependencies, or error handling for the 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by the return value. Zero waste—every word earns its place, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (10 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, behavioral context (e.g., network effects, signing requirements), and doesn't explain the return format beyond 'transaction data,' leaving gaps for a tool with many inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no meaning beyond the schema—no explanation of what parameters like 'provider', 'chainId', or gas fields do, or how they interact. The description only implies parameters through 'ERC721 NFT approval,' but doesn't detail semantics for any of the 10 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('prepare') and resource ('ERC721 NFT approval transaction'), specifying it's for signing and returns transaction data. It distinguishes from siblings like 'approveNFT' (which might execute) and 'setNFTApprovalForAll' (which is for all tokens), but doesn't explicitly contrast with 'prepareERC721SetApprovalForAll' (for all approvals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'prepareERC721SetApprovalForAll' (for batch approvals) or 'approveNFT' (which might execute directly). The description implies it's for preparing a single NFT approval transaction, but lacks 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.
Prepare an ERC721 NFT setApprovalForAll transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| operator | Yes | ||
| approved | Yes | ||
| fromAddress | Yes | ||
| provider | No | ||
| chainId | No | ||
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'Returns transaction data that can be signed and broadcast.' It doesn't disclose that this is a read-only preparation step (not actually sending), what happens if parameters are invalid, whether it interacts with blockchain nodes, or any rate limits. The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two clear sentences that front-load the purpose and outcome. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex blockchain transaction preparation tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the relationship between preparation and execution tools, doesn't clarify parameter roles, and provides minimal behavioral context despite the tool's significant complexity and potential consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 10 parameters (4 required), the description provides no information about any parameters. It doesn't explain what 'contractAddress', 'operator', 'approved', 'fromAddress', or the 6 optional gas/chain parameters mean or how they should be used, leaving significant gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Prepare an ERC721 NFT setApprovalForAll transaction for signing') and the resource involved (ERC721 NFT transactions). It distinguishes from siblings like 'prepareERC721Approval' (single approval) and 'setNFTApprovalForAll' (likely the execution tool) by focusing on preparation rather than execution or different approval types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'prepareERC721Approval' (for single approvals) or 'setNFTApprovalForAll' (which might execute the transaction), nor does it specify prerequisites like needing a wallet loaded first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an ERC721 NFT transfer transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| tokenId | Yes | ||
| toAddress | Yes | ||
| fromAddress | Yes | ||
| provider | No | ||
| chainId | No | ||
| gasLimit | No | ||
| gasPrice | No | ||
| maxFeePerGas | No | ||
| maxPriorityFeePerGas | No |
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 prepares a transaction for signing, implying it's a read-only operation that doesn't execute on-chain, but it doesn't clarify critical behaviors: whether it requires authentication, interacts with a blockchain provider, handles gas estimation, or validates inputs (e.g., token ownership). For a tool with 10 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that are front-loaded with the core purpose and output. Every word earns its place, with no redundant or vague phrasing. It efficiently communicates the essential function without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the transaction data format returned, error conditions, dependencies on other tools (e.g., wallet loading), or how it integrates with siblings like 'sendSignedTransaction'. For a preparation tool in a blockchain context, this lacks necessary operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameters. It adds no semantic information about any of the 10 parameters (e.g., what 'provider' refers to, how 'gasLimit' is used, or the role of 'chainId'). This leaves the agent reliant solely on schema patterns and names, which is insufficient for complex blockchain interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Prepare an ERC721 NFT transfer transaction for signing' and specifies the output: 'Returns transaction data that can be signed and broadcast.' It distinguishes from siblings like 'transferNFT' (which likely executes) and 'prepareERC721Approval' (which handles approvals). However, it doesn't explicitly contrast with 'prepareTransaction' or 'prepareContractTransaction' which might be more generic alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing wallet setup or prior approvals), nor does it differentiate from sibling tools like 'prepareTransaction' (generic), 'prepareERC721Approval' (for approvals), or 'transferNFT' (which might execute directly). This leaves the agent guessing about the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a basic ETH transfer transaction for signing. Returns transaction data that can be signed and broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| toAddress | Yes | The Ethereum address to send ETH to | |
| value | Yes | The amount to send in ETH (e.g., '1.0', '0.5') | |
| fromAddress | Yes | The Ethereum address sending the ETH | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. | |
| gasLimit | No | Optional. The gas limit for the transaction | |
| gasPrice | No | Optional. The gas price (in gwei) for legacy transactions | |
| maxFeePerGas | No | Optional. The maximum fee per gas (in gwei) for EIP-1559 transactions | |
| maxPriorityFeePerGas | No | Optional. The maximum priority fee per gas (in gwei) for EIP-1559 transactions |
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 discloses that the tool prepares transaction data for signing and broadcasting, which implies it's a read-only preparation step (not executing the transaction). However, it doesn't mention permissions, rate limits, network dependencies, or error handling, leaving behavioral gaps for a tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds output details in the second. It's efficient with no wasted words, though it could be slightly more structured by explicitly separating purpose from output or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and output but lacks details on behavioral traits, error cases, or how the prepared data should be used with sibling tools like signMessage or sendSignedTransaction. For a preparation tool in a blockchain context, more guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining interactions between parameters (e.g., gasPrice vs. maxFeePerGas) 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('prepare a basic ETH transfer transaction for signing') and the resource ('ETH transfer transaction'), distinguishing it from sibling tools like prepareContractTransaction or prepareERC20Transfer. It explicitly mentions the output ('Returns transaction data that can be signed and broadcast'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ETH transfers but doesn't explicitly state when to use this tool versus alternatives like prepareContractTransaction or sendTransaction. It mentions the output is for signing and broadcasting, which provides some context, but lacks explicit guidance on prerequisites, error conditions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The ENS name to resolve | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a signed transaction to the blockchain network. Returns transaction hash and receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| signedTransaction | Yes | The signed transaction data as hex string | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. |
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 action ('send') and return values, but lacks critical behavioral details such as whether this is a write operation (implied but not stated), potential for failure (e.g., network errors, insufficient gas), side effects (e.g., on-chain state changes), or security considerations (e.g., irreversible once confirmed). This is a significant gap for a blockchain transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and action, the second specifies the return values. It's front-loaded with the core functionality and 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain transactions (write operations with irreversible effects), no annotations, and no output schema, the description is incomplete. It covers the basic purpose and returns but misses critical context like error handling, confirmation requirements, or cost implications. It's adequate as a minimum but has clear gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain format details for 'signedTransaction' or usage trade-offs for 'provider' vs 'chainId'). 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('send a signed transaction') and resource ('to the blockchain network'), and distinguishes it from sibling tools like 'sendTransaction' (which likely sends unsigned transactions) and 'sendTransactionWithOptions' (which likely provides more configuration). It also specifies the return values ('transaction hash and receipt').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it's for sending signed transactions, distinguishing it from tools like 'prepareTransaction' or 'sendTransaction'. However, it doesn't explicitly state when NOT to use this tool or name alternatives, such as using 'sendTransaction' for unsigned transactions or 'sendTransactionWithOptions' for more control.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The Ethereum address to send to | |
| value | Yes | The amount to send in ether | |
| data | No | Optional. The hex data to include in the transaction | |
| mockMode | No | Optional. If true, just simulates the transaction without sending it. Default is false. | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The Ethereum address to send to | |
| value | Yes | The amount to send in ether | |
| data | No | Optional. The hex data to include in the transaction | |
| gasLimit | No | Optional. The gas limit for the transaction | |
| maxFeePerGas | No | Optional. The maximum fee per gas (in gwei) | |
| maxPriorityFeePerGas | No | Optional. The maximum priority fee per gas (in gwei) | |
| nonce | No | Optional. The nonce to use for the transaction | |
| mockMode | No | Optional. If true, just simulates the transaction without sending it. Default is false. | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. | |
| chainId | No | Optional. The chain ID to use. If provided with a named network and they don't match, the RPC's chain ID will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| operator | Yes | ||
| approved | Yes | ||
| provider | No | ||
| chainId | No | ||
| gasOptions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to sign | |
| provider | No | Optional. Either a network name or custom RPC URL. Use getAllNetworks to see available networks and their details, or getNetwork to get info about a specific network. You can use any network name returned by these tools as a provider value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | ||
| tokenId | Yes | ||
| to | Yes | ||
| provider | No | ||
| chainId | No | ||
| gasOptions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0approveERC20erc1155_balanceOf3 fields changedInput schema / properties / contractAddressAdded value: +{
+ "description": "The address of the ERC1155 contract",
+ "pattern": "^0x[a-fA-F0-9]{40}$",
+ "type": "string"
+}Input schema / properties / tokenAddress / descriptionPrevious value: -"The address of the ERC1155 contract"New value: +"DEPRECATED: Use contractAddress instead. The address of the ERC1155 contract"Input schema / requiredPrevious value: -[
- "tokenAddress",
- "ownerAddress",
- "tokenId"
-]New value: +[
+ "contractAddress",
+ "ownerAddress",
+ "tokenId"
+]erc20_balanceOf3 fields changedInput schema / properties / contractAddressAdded value: +{
+ "description": "The address of the ERC20 token contract",
+ "type": "string"
+}Input schema / properties / tokenAddress / descriptionPrevious value: -"The address of the ERC20 token contract"New value: +"DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract"Input schema / requiredPrevious value: -[
- "tokenAddress",
- "ownerAddress"
-]New value: +[
+ "contractAddress",
+ "ownerAddress"
+]erc20_getTokenInfo3 fields changedInput schema / properties / contractAddressAdded value: +{
+ "description": "The address of the ERC20 token contract",
+ "type": "string"
+}Input schema / properties / tokenAddress / descriptionPrevious value: -"The address of the ERC20 token contract"New value: +"DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract"Input schema / requiredPrevious value: -[
- "tokenAddress"
-]New value: +[
+ "contractAddress"
+]getAllNetworks1 field changedInput schema / additionalPropertiesRemoved value: -falsegetERC20Allowance3 fields changedInput schema / properties / contractAddressAdded value: +{
+ "description": "The address of the ERC20 token contract",
+ "type": "string"
+}Input schema / properties / tokenAddress / descriptionPrevious value: -"The address of the ERC20 token contract"New value: +"DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract"Input schema / requiredPrevious value: -[
- "tokenAddress",
- "ownerAddress",
- "spenderAddress"
-]New value: +[
+ "contractAddress",
+ "ownerAddress",
+ "spenderAddress"
+]getERC20Balance3 fields changedInput schema / properties / contractAddressAdded value: +{
+ "description": "The address of the ERC20 token contract",
+ "type": "string"
+}Input schema / properties / tokenAddress / descriptionPrevious value: -"The address of the ERC20 token contract"New value: +"DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract"Input schema / requiredPrevious value: -[
- "tokenAddress",
- "ownerAddress"
-]New value: +[
+ "contractAddress",
+ "ownerAddress"
+]getERC20TokenInfo3 fields changedInput schema / properties / contractAddressAdded value: +{
+ "description": "The address of the ERC20 token contract",
+ "type": "string"
+}Input schema / properties / tokenAddress / descriptionPrevious value: -"The address of the ERC20 token contract"New value: +"DEPRECATED: Use contractAddress instead. The address of the ERC20 token contract"Input schema / requiredPrevious value: -[
- "tokenAddress"
-]New value: +[
+ "contractAddress"
+]getSupportedNetworks1 field changedInput schema / additionalPropertiesRemoved value: -falsegetWalletBalance1 field changedInput schema / properties / address / patternAdded value: +"^0x[a-fA-F0-9]{40}$"listPrompts1 field changedInput schema / additionalPropertiesRemoved value: -falseprepareContractTransactionprepareERC1155BatchTransferprepareERC1155SetApprovalForAllprepareERC1155TransferprepareERC20ApprovalprepareERC20TransferprepareERC721ApprovalprepareERC721SetApprovalForAllprepareERC721TransferprepareTransactionsendSignedTransactiontransferERC20approveERC20approveNFTcheckWalletExistscontractCallerc1155_balanceOferc1155_balanceOfBatcherc1155_urierc20_balanceOferc20_getTokenInfoerc721_balanceOferc721_tokenURIethSignformatEtherformatUnitsgenerateWalletgetAllNetworksgetBlockDetailsgetBlockNumbergetContractCodegetEnsResolutionGuidancegetERC20AllowancegetERC20BalancegetERC20TokenInfogetFeeDatagetGasPricegetNetworkgetNFTInfogetNFTMetadatagetNFTOwnergetNFTTokenURIgetSupportedNetworksgetTransactionDetailsgetWalletBalancegetWalletTransactionCountlistPromptsloadWalletlookupAddressparseEtherresolveNamesendTransactionsendTransactionWithOptionssetNFTApprovalForAllsignMessagetransferERC20transferNFTThere is significant overlap and ambiguity among tools, such as multiple ERC20 balance tools (erc20_balanceOf, getERC20Balance) and ERC721 token URI tools (erc721_tokenURI, getNFTTokenURI), which could confuse agents. Some tools like listPrompts appear unrelated to the Ethereum wallet domain, adding to the confusion.
Naming conventions are inconsistent, mixing snake_case (e.g., erc20_balanceOf) and camelCase (e.g., getERC20Balance) without a clear pattern. Verb styles vary (e.g., 'get' vs. 'prepare' vs. 'send'), and some tools lack descriptive names (e.g., contractCall, ethSign), making the set chaotic.
With 54 tools, the count is excessive for an Ethereum wallet server, leading to bloat and potential confusion. This many tools suggests poor scoping, as many functions could be consolidated (e.g., multiple ERC20/ERC721 tools), making it overwhelming for agents to navigate.
The toolset covers core Ethereum operations like balances, transfers, approvals, and transaction handling across ERC20, ERC721, and ERC1155 standards, but there are gaps such as missing descriptions for many tools (e.g., approveNFT, getBlockDetails) and unclear coverage for advanced features like smart contract deployment or event listening.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/crazyrabbitLTC/mcp-ethers-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
