Allows performing EVM blockchain operations (reading balances, contracts, transactions, etc.) via Alchemy RPC.
Supports interactions with Ethereum mainnet and testnets (sepolia).
Supports interactions with Optimism mainnet and testnet (optimism-sepolia).
Supports interactions with Polygon mainnet and testnet (polygon-amoy).
Click on "Deploy 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., "@crypto-mcp-server what's my 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.
A Model Context Protocol server that lets any MCP client (Claude Desktop, Cursor, etc.) perform EVM blockchain operations — reading balances, reading/writing contracts, simulating and sending transactions, and signing messages — through Alchemy RPC, using a wallet derived from a mnemonic or private key.
Multi-chain across Alchemy-backed networks. The target network is
selectable per tool call (defaults to the configured DEFAULT_NETWORK).
Mainnets: ethereum, base, arbitrum, optimism, polygon
Testnets: sepolia, base-sepolia, arbitrum-sepolia,
optimism-sepolia, polygon-amoy
Both transports: stdio (default, for local clients) and Streamable HTTP (for remote/hosted use).
Tools:
Reads: get_native_balance, get_token_balance, get_gas_price,
get_block, get_transaction, resolve_ens, read_contract
Writes: send_native, send_token, write_contract
Pre-flight: simulate_transaction (dry-run, never broadcasts)
Signing: sign_message (EIP-191), sign_typed_data (EIP-712)
Related MCP server: MCP Crypto Wallet EVM
Node.js ≥ 18
An Alchemy API key
A wallet mnemonic or private key
npm install
cp .env.example .env # then fill in the values
npm run buildVariable | Required | Description |
| yes | Your Alchemy API key. Used to build RPC endpoints for all chains. |
| one of | BIP-39 mnemonic phrase. Provide exactly one of this / key. |
| one of |
|
| no | HD path used with |
| no | Default chain when a call omits |
| no |
|
| no | Port for the HTTP transport. Default: |
The server fails to start (non-zero exit) if ALCHEMY_API_KEY is missing,
if neither key is provided, or if both keys are provided.
stdio (default — most MCP clients launch the server this way):
npm run start
# or for development with reload:
npm run devStreamable HTTP:
TRANSPORT=http PORT=3000 npm run start
# MCP endpoint: http://localhost:3000/mcpAdd to your client's MCP config (e.g. Claude Desktop's
claude_desktop_config.json, or .cursor/mcp.json). See
examples/mcp-client-config.json.
{
"mcpServers": {
"crypto": {
"command": "node",
"args": ["/absolute/path/to/crypto-mcp-server/dist/index.js"],
"env": {
"ALCHEMY_API_KEY": "your-alchemy-key",
"PRIVATE_KEY": "0xyour-private-key",
"DEFAULT_NETWORK": "ethereum"
}
}
}
}This server can spend funds. It holds a mnemonic or private key in process memory and can sign and broadcast transactions.
Secrets are read only from environment variables and are never logged, echoed, or returned in tool outputs or error messages.
Prefer simulate_transaction before any send_* / write_contract call to
preview gas and catch reverts.
The HTTP transport exposes spend operations over the network. It performs
no authentication of its own — run it only behind a trusted network and/or an
authenticating proxy. For local single-user use, prefer stdio.
Use a dedicated, low-value wallet. Never point this at a key holding significant funds without your own additional controls.
npm run lint # type-check only (tsc --noEmit)
npm run test # vitest
npm run build # compile to dist/Fetch a block by number, tag (e.g. 'latest'), or hash on a supported network.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | Block number, tag ('latest'/'finalized'), or block hash. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it discloses a read operation but does not detail error handling, network dependencies, or other behavioral traits.
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?
A single, front-loaded sentence that efficiently conveys the tool's purpose without extraneous information.
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?
The description covers the core action but does not specify what the returned block data includes (no output schema), leaving some ambiguity for an 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?
Schema coverage is 100%, so baseline is 3; the description echoes schema parameter descriptions without adding new meaning.
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 fetches a block using number, tag, or hash, distinguishing it from sibling tools that handle gas prices, balances, etc.
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 retrieving block data but lacks explicit guidance on when to use this tool versus alternatives or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current fee data (gas price, EIP-1559 fields) for a network.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention that the tool is read-only, requires no authentication beyond the network, or any rate limits. It just states the action without behavioral 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 a single sentence with 10 words, no redundancy, and effectively front-loads the core purpose. Every word contributes value.
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?
While the tool is simple with one parameter, the lack of output schema means the description should clarify what 'fee data' includes (e.g., gas price and EIP-1559 fields). It is adequate but could be more explicit about return structure.
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 coverage is 100% with a single optional parameter 'network' with a clear enum description. The description adds no extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'get' and the resource 'current fee data' with details on gas price and EIP-1559 fields, clearly distinguishing it from sibling tools that deal with blocks, balances, or transactions.
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, nor any prerequisites or conditions. The description simply states what it does without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the native currency balance (ETH/POL/etc.) of an address on a supported network.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address to query. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
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 implies a read-only operation via 'Get', but does not explicitly state that it does not modify state or require special permissions. The behavior is adequately inferred but not fully disclosed.
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 sentence, front-loaded with the action and resource, with no extraneous words. Every part serves a purpose.
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 simple tool with two parameters and no output schema, the description covers the core purpose and network options. However, it lacks clarity on the return format (e.g., wei vs. ether), which would be helpful given no output schema is provided.
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 coverage is 100%, so the baseline is 3. The description mentions 'address' and 'network' but adds no additional meaning beyond what the schema already provides. The term 'native currency balance (ETH/POL/etc.)' describes the result, not the 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 tool retrieves the native currency balance (ETH/POL/etc.) of an address, using a specific verb ('Get') and resource ('native balance'). This distinguishes it from the sibling tool 'get_token_balance' which handles token balances.
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 implicitly indicates when to use this tool (for native balances) and the sibling tool get_token_balance suggests an alternative, but no explicit when-not-to-use or exclusion criteria are provided. The context is clear enough for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an ERC-20 token balance for an address, using the token's on-chain decimals and symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 token contract address. | |
| address | Yes | Holder address to query. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
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 using 'on-chain decimals and symbol' but does not disclose if the tool makes an RPC call, error handling, or any safety traits. Limited behavioral 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 a single, clear sentence with no unnecessary words. Efficiently communicates the main action.
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?
The tool lacks an output schema, and the description does not explain the return format or error cases. It mentions 'decimals and symbol' but incomplete for a full understanding. Adequate but not thorough.
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 100% description coverage for all 3 parameters. The description does not add new meaning beyond the schema, so baseline score of 3 is appropriate.
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 'Get an ERC-20 token balance', specifying the verb ('Get'), resource ('ERC-20 token balance'), and the use of on-chain data. This distinguishes it from sibling tools like 'get_native_balance' and 'get_transaction'.
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 does not explicitly state when to use this tool vs alternatives. It implies use for ERC-20 tokens by naming 'ERC-20', but no when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a transaction and, if mined, its receipt by hash on a supported network.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses conditional behavior ('if mined'), but does not specify what happens if the transaction is not mined (e.g., error or partial result). Missing details on authentication, rate limits, or side effects.
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?
A single, front-loaded sentence of 14 words efficiently conveys the tool's purpose without superfluous information.
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 no output schema, the description hints at return structure (transaction and receipt if mined). It could mention what happens for unmined transactions or invalid hashes, but overall it sufficiently sets expectations for a simple fetch operation.
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 coverage is 100% with descriptions for hash and network, including an enum. The description adds no additional meaning beyond what is already in the schema, so it meets the baseline but does not enhance 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 tool fetches a transaction and its receipt if mined, by hash on a supported network. It uses a specific verb (fetch) and resource (transaction), and distinguishes from sibling tools like get_block or get_gas_price by focusing on transaction details.
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 is provided. The description only states what it does, without context on when not to use it or which sibling tool might be more appropriate for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a read-only (view/pure) contract method. Provide the contract address, an ABI fragment array, the method name, and arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | ABI fragments in human-readable form, e.g. ['function totalSupply() view returns (uint256)']. | |
| args | No | Positional arguments for the method. | |
| method | Yes | Method name to call. | |
| address | Yes | Contract address. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. Description only states 'read-only' implying no state change, but omits details like gas cost, revert behavior, or required authentication.
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?
Single sentence front-loaded with purpose. Concise but could be slightly more informative without adding length.
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?
No output schema; description fails to mention return value (the method result). Lacks error handling context or default network behavior.
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 has 100% coverage of parameter descriptions. The tool description does not add new semantic context beyond what's in the schema, so baseline 3 is appropriate.
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 calls a read-only contract method, distinguishing it from write_contract. Uses specific verb 'call' and specifies 'view/pure' nature.
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?
Indirectly implies usage for read-only methods but lacks explicit guidance on when to use versus write_contract or other tools. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an ENS name to an address, or an address to its primary ENS name, where the network supports ENS.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | An ENS name (e.g. vitalik.eth) or an address to reverse-resolve. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions bidirectional resolution and network support, but lacks details on error handling, rate limits, or authentication. Without annotations, more behavioral context would be beneficial.
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?
Single sentence conveys core functionality efficiently with no extraneous words.
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?
Lacks output schema, so description should hint at return format (e.g., address or ENS name). Minimal info on behavior across networks or failure cases makes it slightly incomplete for a bidirectional resolution tool.
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?
Adds value beyond schema by clarifying query can be ENS name or address for reverse resolution, and network defaults to server's configured network. Schema coverage is 100% but description enriches 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?
Description clearly states bidirectional resolution of ENS names and addresses, which is specific and distinct from sibling tools that focus on native blockchain operations like get_block, send_native, etc.
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?
Implicitly clarifies usage for ENS resolution on supported networks, but lacks explicit when-to-use or when-not-to-use guidance. Sibling tools are unrelated, so no alternative guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign and broadcast a native currency transfer from the configured wallet. STATE-CHANGING: spends funds.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address. | |
| amount | Yes | Amount in native units (e.g. '0.01'). | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly marks the tool as 'STATE-CHANGING: spends funds', which is a critical behavioral trait. However, it does not elaborate on failure modes, permissions, or reversibility, leaving some 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 extremely concise: two sentences that state the core purpose and the key behavioral note. Every word is necessary, front-loaded with the action. No fluff.
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 has no output schema and no annotations, the description covers the essential purpose and state-changing nature. It lacks details about return values or error handling, but for a simple send operation, it is reasonably complete and actionable.
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%, and the parameter descriptions in the schema already explain 'to', 'amount', and 'network' adequately. The tool description adds no extra semantic value beyond what is in the schema, so a baseline score of 3 is appropriate.
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 'Sign and broadcast a native currency transfer' with verb+resource, distinguishes from siblings like send_token by specifying 'native currency' and 'configured wallet', and adds state-changing context. No 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 does not explicitly state when to use or not use this tool. It mentions 'native currency' which implicitly distinguishes from token transfers, but lacks direct guidance on alternatives or prerequisites. The inference is possible but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign and broadcast an ERC-20 transfer from the configured wallet, converting the amount using the token's decimals. STATE-CHANGING.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address. | |
| token | Yes | ERC-20 token contract address. | |
| amount | Yes | Amount in token units (e.g. '100.5'). | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'STATE-CHANGING' but provides no further behavioral details such as authorization requirements, side effects, error conditions, or rate limits. With no annotations, the description carries the full burden and falls short.
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 very concise with two sentences and front-loads the core action. However, the phrase 'STATE-CHANGING' is somewhat redundant and could be omitted to improve conciseness further.
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?
Despite having 4 parameters and no output schema, the description lacks details about return values (e.g., transaction hash), error cases, or setup requirements (e.g., wallet configuration). The tool is incomplete for practical use 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 coverage is 100%, so the schema already describes parameters. The description adds meaningful value by explaining that the amount is converted using the token's decimals, which is not in the schema. However, it does not elaborate on other parameters like 'to' or 'network' defaults.
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 ('sign and broadcast') and resource ('ERC-20 transfer'), and adds the specific detail about converting amount using token decimals. It distinguishes from sibling tools like send_native (native token) and simulate_transaction (simulation).
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 ERC-20 transfers but does not explicitly state when to use this tool over alternatives (e.g., send_native, write_contract) or mention any prerequisites or exclusions. Guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign an arbitrary text message (EIP-191 personal_sign) with the configured wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message text to sign. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the signing method (EIP-191 personal_sign) and that it uses the configured wallet, but does not mention side effects, error conditions, or return format. For a signing operation, this is adequate but not comprehensive.
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?
One sentence of 12 words, perfectly concise. Action and resource are front-loaded. No unnecessary words.
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 simple operation with one parameter and no output schema, the description is mostly complete. It explains the standard used and the type of message. However, it could specify the return value (likely the signature) to be more complete.
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 coverage is 100%, so baseline 3. The description adds minimal meaning beyond schema's 'message text to sign' by saying 'arbitrary text message', which is essentially the same.
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 it signs an arbitrary text message using EIP-191 personal_sign with the configured wallet. It specifies the exact standard and distinguishes from sibling sign_typed_data implicitly.
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 when to use (when signing an arbitrary text message) but does not explicitly state when not to use or contrast with alternatives like sign_typed_data. No exclusion criteria 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.
Sign EIP-712 typed data with the configured wallet. Provide domain, types, and value.
| Name | Required | Description | Default |
|---|---|---|---|
| types | Yes | EIP-712 types (excluding EIP712Domain). | |
| value | Yes | The typed data value to sign. | |
| domain | Yes | EIP-712 domain object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose that the wallet must be unlocked, any potential side effects, or the signature format returned (e.g., hex string). Insufficient detail for a signing operation.
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?
Description is a single concise sentence, front-loaded with key information. No wasted words, but could benefit from slight expansion for completeness without harming 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 of EIP-712 signing and no output schema, the description is insufficient. It does not explain what the tool returns (signature format), prerequisites (wallet state), or differentiate clearly from sign_message.
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% with brief descriptions for each parameter. The description merely restates 'Provide domain, types, and value' without adding semantic detail beyond the schema. Baseline 3 is appropriate.
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 'sign' and the resource 'EIP-712 typed data' with the configured wallet. It distinguishes from sibling tools like 'sign_message' which handles simple messages only.
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 mentions to provide domain, types, and value but lacks explicit guidance on when to use this tool versus alternatives (e.g., sign_message for simple messages). No when-not or alternative tool names given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run a transaction (native/erc20/contract) WITHOUT broadcasting. Returns success/revert, gas estimate, and a decoded revert reason when it would fail.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Recipient (native/erc20) or contract address (contract). | |
| abi | No | ABI fragments for contract calls. | |
| args | No | Args for contract calls. | |
| kind | Yes | Which kind of transaction to simulate. | |
| token | No | Token address for erc20 transfers. | |
| value | No | Native value for contract calls. | |
| amount | No | Amount for native/erc20 transfers. | |
| method | No | Method name for contract calls. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
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 is a dry-run (no broadcast), returns success/revert, gas estimate, and decoded revert reason. This covers key behavioral traits, though it omits details like idempotency or authorization.
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, clear sentence that is front-loaded with the essential purpose and returning information. No redundant words.
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?
Although the schema describes each parameter, the overall workflow (e.g., parameter dependencies based on 'kind') is not explained. For a tool with 9 parameters and complex interactions, the description is minimally complete but lacks guidance on how to properly construct the input.
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 baseline is 3. The description only adds context for the 'kind' parameter (native/erc20/contract) but does not elaborate on other parameters beyond what the schema already 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 uses specific verbs ('dry-run', 'without broadcasting') and clearly identifies the resource (transaction types: native/erc20/contract). It distinguishes this tool from siblings like send_native or write_contract that would broadcast.
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 use for testing before actual broadcasting but does not explicitly state when to use this tool versus alternatives like send_native or write_contract. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign and broadcast a call to a state-changing contract method. Provide address, ABI fragments, method, args, and optional native value. STATE-CHANGING.
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | Human-readable ABI fragments. | |
| args | No | Positional arguments. | |
| value | No | Optional native value to send with the call (native units). | |
| method | Yes | Method name to invoke. | |
| address | Yes | Contract address. | |
| network | No | Target network. One of: ethereum, base, arbitrum, optimism, polygon, sepolia, base-sepolia, arbitrum-sepolia, optimism-sepolia, polygon-amoy. Defaults to the server's configured default network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It notes 'STATE-CHANGING' and 'broadcast', but omits critical details such as gas costs, balance requirements, nonce handling, error behavior, return value, or transaction finality. This is insufficient for a mutation 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?
Two concise sentences, front-loaded with the core action and key inputs. No redundant information. Every sentence contributes to clarity.
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?
Despite good parameter coverage in the schema, the description lacks essential contextual details for a transaction tool: no mention of the return type (likely transaction hash), gas implications, prerequisites, or potential reverts. An agent would be under-informed about the tool's full behavior and risks.
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 schema covers all 6 parameters with descriptions (100% coverage). The description merely lists parameter names without adding meaning beyond the schema, so it meets the baseline but provides no extra semantic 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 action ('Sign and broadcast a call') and the resource ('state-changing contract method'), explicitly listing key parameters. The 'STATE-CHANGING' emphasis and contrast with siblings like 'read_contract' make 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 provides a basic usage hint ('Provide address, ABI fragments, method, args, and optional native value') but does not explicitly state when to use this tool versus alternatives like 'simulate_transaction' or 'send_native'. No exclusions or conditional guidance is given.
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.
v0.1.0get_blockget_gas_priceget_native_balanceget_token_balanceget_transactionread_contractresolve_enssend_nativesend_tokensign_messagesign_typed_datasimulate_transactionwrite_contractScored across 13 tools
Each tool targets a distinct operation: block retrieval, balance queries, transfers, signing, simulation, etc. No two tools overlap in purpose; even similar actions like sending native vs token are clearly differentiated by asset type and description.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_block, send_native, sign_message). The verbs are uniform and the structure is predictable, making it easy to infer tool functionality from the name.
With 13 tools, the server covers a broad yet focused set of crypto operations (reads, writes, signing, simulation) without being overwhelming. This count is well within the optimal range for a domain-specific MCP server.
The tool set covers essential read/write operations, ENS resolution, signing, and simulation. Minor gaps exist, such as token approval (required for ERC-20 transfers) and event log retrieval, but core workflows are well-supported.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Alchemy (Ethereum + L2) MCP.
Safety-first EVM and Bitcoin RPC tools for balances, contracts, blocks, and transactions
Multi-chain wallet intelligence: balances, transactions, ENS, OFAC screening across 7 chains.