Loading ToolBench
EVM token deployment and management MCP server - deploys ERC-20 tokens, queries token information, and manages token transfers across multiple EVM-compatible blockchains
Token-minter-mcp has complete tool definitions with schemas and descriptions, but falls short of production quality on several dimensions. All 5 tools are explicitly registered with input schemas using Zod validation and non-empty descriptions. However, descriptions lack LLM-optimization context (missing 'when to use' guidance and recovery patterns), parameter descriptions are present but minimal (averaging ~40 chars vs 72-char baseline), and critical error handling is absent. No output schemas are documented, forcing LLMs to infer response structure. Most significantly, the irreversible tools (deployToken, transferToken) lack confirmation/dry-run patterns and error classification. Naming is verb-first and clear (get_, deploy_, transfer_), meeting the pattern:tool baseline. The server demonstrates competent schema definition but poor error guidance and missing operational safeguards that distinguish A-tier tools.
Deploys a new ERC-20 token on the specified EVM-compatible chain with customizable decimals and initial supply. Returns the transaction hash without waiting for confirmation.
Queries the native token balance (e.g., ETH or POL) of the current account on the specified chain.
Queries the balance of a specific ERC-20 token for the current account on the specified chain.
Queries information about an existing ERC-20 token, including name, symbol, decimals, and total supply.
Transfers a specified amount of ERC-20 tokens to a recipient address and waits for transaction confirmation.
No documented output schemas. LLMs cannot infer response structure; all 5 tools return responses with undocumented fields. This forces LLMs to guess at field names and types, increasing hallucination risk on downstream calls.
Irreversible operations (deployToken, transferToken) lack dry-run or confirmation patterns. Agents can trigger mainnet token deployments or large transfers without user acknowledgment, risking financial loss.
Error handling is generic and non-actionable. All tools return plain text errors without recovery guidance. Example: deployToken throws 'Insufficient balance' but does not suggest the exact chain, currency, or amount needed. Per pattern:recovery-guide, errors should guide LLM to next steps (retry? ask user? call a different tool?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions are terse and lack validation context. 'Token contract address' does not explain format (0x... hex string, 42 chars), length, or valid character set. LLMs may pass invalid formats.
PRIVATE_KEY exposed as environment variable with no vault abstraction. While not a tool parameter (safer), the key is loaded into process memory without rotation, audit logging, or permission gating. If server logs are captured or memory dumped, credentials leak. Per pattern:secret-injection, secrets must be rotated and audit-logged.
No error classification or permission gating. All users with access to the server can deploy tokens or transfer funds on mainnet. Per pattern:permission-gate and pattern:scope-declaration, tools should verify caller authority and declare required permissions (e.g., 'write:blockchain').