Loading ToolBench
A Model Context Protocol (MCP) server for auditing smart contracts using Slither, Aderyn, and other tools
Server provides 6 tools with explicit schemas and descriptions. Tool naming uses action verbs (audit_*, read_*, check_) and is generally clear. However, descriptions are inconsistent in depth, some parameter descriptions lack operational detail, and output schemas are not explicitly documented in the provided code. Error handling guidance is absent. The server targets smart contract auditing (a specialized domain) and covers the core use cases well, but lacks the LLM-optimization patterns seen in A-grade tools.
Run Aderyn static analysis on a smart contract file or project root. Aderyn is a Rust-based Solidity analyzer; results are returned as normalized findings.
Run all available static analyzers (Slither, Aderyn, heuristic patterns) on a contract file or project directory and return a single normalized findings report. This is the recommended entry point for a full static-analysis pass.
Check which audit tools (slither, aderyn, solc, solc-select, forge) are installed, with versions and installation instructions.
Run lightweight, comment-aware heuristic checks (reentrancy hints, tx.origin, selfdestruct, delegatecall, etc.) on a single contract file. Low-confidence by design.
Read and return the source code of a smart contract file.
Run Slither static analysis on a smart contract file or project directory. Returns normalized findings. Slither is a Solidity & Vyper static analysis framework.
No output schemas documented. Tools return 'normalized findings report' and 'source code', but the LLM has no visibility into the structure, fields, or format of responses. This forces the LLM to guess at output structure and breaks downstream tool chaining.
Descriptions lack operational context. 'read_contract' (43 chars) and 'check_tools' (55 chars) are below the 10 - 1024 char baseline and below the 50 - 200 char LLM-optimized range. No guidance on prerequisites, when to call, or what happens on error.
No error handling guidance. Tools accept file paths but do not document what happens if the file does not exist, is unreadable, or is too large. No recovery hints (e.g., 'Try check_tools() first to verify Slither is available').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions lack operational constraints. 'contract_path' in all tools does not specify: file size limits, supported extensions (.sol/.vy), behavior on missing files, or how to handle project directories vs. files. LLM cannot validate input before calling.
audit_project 'tools' parameter is an enum but lacks description. LLM cannot determine the difference between 'slither', 'aderyn', and 'pattern' or when to choose one vs. all three. Should explain that 'pattern' is fast but low-confidence, vs. 'slither' is comprehensive.
No parameter descriptions for 'detectors' and 'exclude_detectors' in slither_audit. LLM does not know the format (comma-separated? spaces? array?), valid detector names, or examples. Invites malformed calls.