Loading ToolBench
This repository contains an MCP (Model Context Protocol) server for analyzing Solidity contracts. Currently, it provides full function context analysis.
Single tool 'analyze-fn' has a moderately detailed description but suffers from significant schema and parameter documentation gaps. The tool name is action-oriented (good), but parameters lack individual descriptions, and the output schema is underspecified. Error handling is absent. The description, while detailed at ~280 chars, includes implementation details and procedural steps rather than focusing on WHAT the tool does and WHEN to use it. Input schema exists but parameters are not individually described in the registration, LLMs cannot understand what 'filePath' or 'fnToAnalyze' constraints are beyond type hints. Output schema is a bare Zod definition with no narrative explanation of what 'fnCallFlow' contains or its format. No error guidance, no validation examples, no security considerations around file access.
Analyzes a Solidity function to provide detailed execution flow, variable interactions, and contextual insights. When users want to understand how a specific function works, debug issues, or see its interactions within the contract, this tool will: 1) Parse the full contract source code, 2) Extract the target function's logic, 3) Show control flow paths, 4) Highlight state changes and external calls. `filePath` should be the absolute path to the Solidity contract file, `fnToAnalyze` should be the exact function name.
Parameters lack individual descriptions. 'filePath' and 'fnToAnalyze' have no narrative descriptions explaining constraints, expected formats, or error conditions. LLMs cannot infer whether filePath must be absolute, relative, or a glob pattern; whether fnToAnalyze is case-sensitive; or what happens if the function doesn't exist.
Output schema is underdocumented. The 'fnCallFlow' field is returned as a JSON string, but there is no schema description explaining the internal structure (what keys does the JSON object contain? what do they represent?). LLMs cannot plan downstream operations without understanding the output shape.
No error handling or recovery guidance. If the file does not exist, the function name is not found, or the Solidity code is malformed, the tool returns nothing actionable. Error responses should guide the LLM: 'File not found at <path>. Verify the path is absolute.' or 'Function <name> not found in contract. Use list_functions first.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Tool description conflates intent with implementation. It says 'when users want to understand how a specific function works, debug issues, or see its interactions' (WHEN) followed by 'this tool will: 1) Parse the full contract source code, 2) Extract the target function's logic...' (HOW). Focus the description on WHAT (analyzes a Solidity function for control flow and state changes) and WHEN (when you need to understand function behavior or interactions); omit implementation details.
No pagination, filtering, or output limits documented. If a large contract with hundreds of functions is analyzed, or if 'fnCallFlow' contains deeply nested AST structures, the response could be massive and blow the context window. Document max output size and whether results are truncated.
Security: no input validation or path traversal protection visible. The 'filePath' parameter is passed directly to fs.readFileSync() in ast-analyzer.ts without validation. An LLM could be tricked into passing '../../../etc/passwd' or similar. Implement path normalization and restrict access to a safe directory.