Loading ToolBench
Model Context Protocol (MCP) server for BNB Chain - BSC EVM and Greenfield decentralized storage
This BNB Chain MCP server exposes 23 blockchain tools with consistent naming and reasonable schemas. Tool names follow verb_noun patterns (get_block_by_hash, read_contract, deploy_contract, etc.), which is good. However, descriptions are generic and lack LLM-specific guidance on when to use each tool vs. alternatives. Parameter descriptions are present but minimal, most say what a field is, not why an LLM should pass it or what values are valid. Output schemas are not documented in the source code, which is a critical gap for LLM planning. Error handling is basic or absent, no recovery guidance visible. Critical security issue: private keys are passed as string parameters (write_contract, execute_bridge, deploy_contract, deploy_create2), violating secret-injection patterns and exposing credentials to logging/tracing.
Reverse resolve multiple addresses to ENS names
Check if an ENS name is available for registration
Deploy a smart contract from bytecode and constructor arguments
Deploy a contract using CREATE2 for deterministic addresses across chains
Execute a cross-chain bridge transfer
Get ERC20 approval events for a token or address
Get a block by hash
Private keys exposed as string parameters in write operations (execute_bridge, write_contract, deploy_contract, deploy_create2). This violates secret-injection pattern, credentials will leak into agent logs, traces, and prompt history. CRITICAL SECURITY FLAW.
Output schemas are not documented in source code. LLMs cannot infer what fields are returned, complicating downstream tool chaining and forcing agents to guess field names. Example: does get_block_by_hash return 'blockNumber' or 'number'? does read_contract return 'result' or 'output'?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Get a block by number
Get a quote for bridging tokens across chains
Track the status of a bridge transaction
Get event logs from a specific contract
Get the avatar URL for an ENS name
Get comprehensive details about an ENS name
Get text records for an ENS name (avatar, twitter, email, etc.)
Get ERC20 token transfer events
Get the latest block
Get logs filtered by event topic hash
List all supported bridge protocols and their capabilities
Check if an address is a smart contract or an externally owned account (EOA)
Read data from a smart contract by calling a view/pure function
Resolve an ENS name to its Ethereum address
Get the ENS name for an Ethereum address (reverse lookup)
Write data to a smart contract by calling a state-changing function
Descriptions are generic and lack LLM-specific guidance. Most descriptions are 1 - 2 sentences stating what the tool does, but do not explain WHEN to use it, what prerequisites exist, or how it differs from similar tools. Example: 'Get a block by hash' does not hint at whether to use get_block_by_hash or get_block_by_number, or that blockHash expects '0x...' format.
Parameter descriptions lack constraints and format hints. For example, 'blockHash' description just says 'The block hash to look up' but does not specify '0x-prefixed hex string', 'abi' parameter does not explain ABI format or schema, and 'functionName' does not indicate case sensitivity. LLMs cannot infer these constraints.
No error handling or recovery guidance visible. Tools do not document what errors are retryable (e.g. network timeout on bridge_status) vs. unrecoverable (invalid contract address). LLMs have no guidance on what to do if a call fails.
Destructive operations (execute_bridge, write_contract, deploy_contract) lack confirmation or dry-run patterns. An LLM mistake could trigger irreversible blockchain transactions. No mechanism to ask for user confirmation before executing.
Some parameters accept optional enum values but do not declare enums in schema. Example: 'bridge' parameter in execute_bridge description says 'stargate, layerzero, wormhole, across' but schema may not enforce enum constraint. LLMs will guess at values and pass invalid ones.
No permission declarations or scope annotations. Tools do not declare required permissions (e.g., 'read:blockchain', 'write:blockchain'). Agents cannot know what privileges each tool requires or apply least-privilege configurations.