Loading ToolBench
MCP Server for TRON blockchain interaction including balance queries, transactions, smart contracts, and market data
The TRON MCP server has significant quality gaps across naming, descriptions, and schemas. While tool names generally follow verb_noun conventions (getBalance, sendTrx, getTransaction), descriptions are inconsistent and often too brief. Parameter schemas are present but many lack proper type definitions or constraints. The server exposes a private key parameter (sendTrx) as a tool input, which violates secret-injection patterns. Output schemas are not documented. Error handling exists but lacks recovery guidance. The 29-tool portfolio suffers from inconsistent quality, analytics tools (getEnergyStatisticsFromTRC20, getNetworkEnergyTrends) are better documented than core blockchain tools (sendTrx, getTransaction). No pagination limits are enforced despite tools returning potentially large datasets.
Add a new verified code example to the knowledge base
Call a smart contract function
Estimate energy consumption for a contract call
Get account resources (bandwidth and energy)
Get complete documentation for a TronGrid API method with verified examples
Get TRX balance for an address
Get block information with smart size management to prevent token overflow
Get current block number only (compact output)
sendTrx exposes private key as a tool parameter, violating secret-injection pattern. Private keys should never appear in tool inputs, they are logged, traced, and expose credentials in audit trails.
Output schemas are not documented for any tool. LLMs cannot plan downstream tool calls or extract required fields without knowing what a tool returns. This violates the tool pattern requirement.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Get verified code example with related documentation context
Get latest java-tron releases from GitHub
Get exact field structure for API method parameters and response
Get transaction details by hash
Get detailed TRX market data including 24h change, volume, and market cap
Get current TRX price in USD
Advanced search across all TRON documentation sources
Search TRON documentation and get relevant resources
Send TRX to an address
No pagination documentation. Tools like getTransactionHistory, getEnergyStatisticsFromTRC20, and getTopEnergyConsumers accept limit parameters but lack documentation on max limits, default behavior, and whether they support cursor-based or offset-based pagination. Without pagination guardrails, agents may exhaust context windows.
Description quality is inconsistent. Market tools (getTRXPrice, getTRXMarketData, getChainParameters) have descriptions under 40 characters, which is too brief for LLM tool selection.
Parameter descriptions lack format constraints. For example, getBlock's blockNumber, getUSDTTransferEnergy's toAddress, and getContractEnergyAnalysis's contractAddress accept strings but lack validation rules (valid formats, example patterns). This forces LLMs to guess at acceptable input formats.
Error handling lacks recovery guidance. Code shows errors are thrown but error responses do not include actionable recovery steps. Per the recovery-guide pattern, errors should tell LLMs what to do next (retry, ask user, call alternative tool).
Irreversible operations lack confirmation steps. sendTrx, deleteExample, and updateExample modify state but have no dry-run or confirmation pattern. Per the confirmation-request pattern, destructive operations should support a pre-confirmation step to prevent agent mistakes.
Tool names could be more specific for disambiguation. Multiple tools start with 'get' and operate on similar domains (e.g., getExample, getExampleWithCode, getExamplesForAPIMethod). Slightly more distinctive names would reduce LLM confusion when choosing between similar tools.