Loading ToolBench
MCP server for reading local folder files and providing context for queries with Claude AI integration
This server provides 4 read-only filesystem tools with basic input schemas and descriptions. However, several critical gaps prevent a higher score: (1) Parameter descriptions are minimal and lack actionable constraints; (2) Output schemas are not documented, responses are unstructured text blobs rather than typed objects; (3) No error recovery guidance, errors are returned as plain text without hints on what to do next; (4) No pagination or result limits despite tools that could return large lists; (5) Tool descriptions lack context on when to use each tool vs. alternatives. The tools are straightforward and correctly avoid mutation, but the definitions fall short of production-grade quality. Average per-tool score: 58/100.
Get a comprehensive analysis of a folder including file types, sizes, and structure
List all files and directories in a given directory
Read the contents of a file from the local filesystem
Search for files by name pattern in a directory and its subdirectories
Output schemas are not documented. Tools return unstructured text responses (e.g., 'File: {path}\n\nContent:\n{content}') instead of typed JSON objects with clear field semantics. LLMs cannot reliably extract structured data or chain these outputs to downstream tools.
Parameter descriptions are too brief and lack actionable constraints. E.g., 'path' for read_file has no mention of: (a) absolute vs. relative path handling, (b) symlink behavior, (c) file size limits, (d) supported encodings, (e) error cases (permissions, not found). These gaps force LLMs to guess.
No pagination or result limits. list_directory and search_files can return unbounded results. If an LLM calls search_files on '/' with pattern '*', results could number in the millions, exhausting context and introducing hallucination. Missing limit, offset, and next_cursor parameters.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Error responses are plain text with no recovery guidance. E.g., 'Failed to read file: EACCES (permission denied)' tells the LLM nothing about next steps. Missing actionable errors like 'File not found. Check path with list_directory() first.' or 'Permission denied, you may need elevated access.'
Tool descriptions lack differentiator context. All four tools operate on the filesystem, but descriptions don't explain WHEN to use each. E.g., 'When should I use search_files vs. analyze_folder?' or 'Use list_directory for structure, search_files for pattern matching.' Without this, LLMs spend reasoning cycles on tool selection.
analyze_folder tool description is vague. 'Get a comprehensive analysis of a folder including file types, sizes, and structure', but what does the output actually contain? Total size? File count? MIME type breakdown? Nested folder depth? Without documented output schema, LLMs cannot predict what to expect or how to use the data.
No security boundaries documented. Can these tools access /etc/passwd, /root/.ssh/id_rsa, or other sensitive files? No mention of path whitelisting, symlink following restrictions, or permission model. Production deployments need explicit scope declarations.