crypto-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for the HTTP transport. Default: 3000. | |
| MNEMONIC | No | BIP-39 mnemonic phrase. | |
| TRANSPORT | No | stdio (default) or http. | |
| PRIVATE_KEY | No | 0x-prefixed hex private key. | |
| ALCHEMY_API_KEY | Yes | Your Alchemy API key. | |
| DEFAULT_NETWORK | No | Default chain when a call omits network (e.g. polygon-amoy, sepolia). Default: ethereum. | |
| DERIVATION_PATH | No | HD path used with MNEMONIC (defaults to ethers' default path). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_native_balanceA | Get the native currency balance (ETH/POL/etc.) of an address on a supported network. |
| get_token_balanceA | Get an ERC-20 token balance for an address, using the token's on-chain decimals and symbol. |
| get_gas_priceB | Get current fee data (gas price, EIP-1559 fields) for a network. |
| get_blockA | Fetch a block by number, tag (e.g. 'latest'), or hash on a supported network. |
| get_transactionA | Fetch a transaction and, if mined, its receipt by hash on a supported network. |
| resolve_ensA | Resolve an ENS name to an address, or an address to its primary ENS name, where the network supports ENS. |
| read_contractB | Call a read-only (view/pure) contract method. Provide the contract address, an ABI fragment array, the method name, and arguments. |
| simulate_transactionA | Dry-run a transaction (native/erc20/contract) WITHOUT broadcasting. Returns success/revert, gas estimate, and a decoded revert reason when it would fail. |
| send_nativeA | Sign and broadcast a native currency transfer from the configured wallet. STATE-CHANGING: spends funds. |
| send_tokenA | Sign and broadcast an ERC-20 transfer from the configured wallet, converting the amount using the token's decimals. STATE-CHANGING. |
| write_contractB | Sign and broadcast a call to a state-changing contract method. Provide address, ABI fragments, method, args, and optional native value. STATE-CHANGING. |
| sign_messageA | Sign an arbitrary text message (EIP-191 personal_sign) with the configured wallet. |
| sign_typed_dataB | Sign EIP-712 typed data with the configured wallet. Provide domain, types, and value. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.