Loading ToolBench
MCP server with file reading capabilities for AI-powered chat applications
The server defines only one tool, 'read_file', with a basic description and minimal schema. The tool name follows verb conventions (good), but parameter descriptions are missing entirely, schema completeness is limited, and output schema is undocumented. No error handling guidance, no security considerations (despite read access to the filesystem), and no input validation rules are documented. The implementation is functional but falls short of production-grade tool definition standards. The source code shows the tool registered via setRequestHandler(ListToolsRequestSchema) with a Zod-derived input schema (ReadFileArgsSchema), but the schema lacks parameter-level descriptions and the output schema is inferred but not fully validated in the tool response.
Read the complete contents of a file from the file system. Handles various text encodings and provides detailed error messages if the file cannot be read. Use this tool when you need to examine the contents of a single file. Only works within allowed directories.
Parameter 'path' has no description in the tool definition. LLMs cannot infer what 'path' controls (absolute vs relative? from what root? allowed directories?). This violates the requirement that every parameter must have a non-empty description explaining its semantics.
Tool description lacks critical context: (1) Does not state the absolute filesystem root or allowed directory list (only a comment says 'Only works within allowed directories' but no mechanism is documented). (2) Does not explain the path format (absolute? relative to cwd? requires normalization?). (3) No error recovery guidance (e.g., 'If file is not found, try listing directory with list_directory or checking permissions'). (4) Does not document output schema, what fields are in the result? Is encoding always UTF-8? What happens on binary files?
Input schema has no descriptions. The ReadFileArgsSchema defines path as z.string() with no constraint metadata (min length, pattern, allowed roots). The zodToJsonSchema() conversion likely produces a bare string type with no descriptions or constraints visible to the LLM. This invites invalid paths (../../etc/passwd traversal, non-existent paths, binary files) and provides no guidance on recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No output schema documented. The source shows FileSystemResultSchema defined (content array with text objects, optional _meta and isError), but the tool's returned response is not shown in full. LLMs need to know: What fields are returned? Is the result always a string, or can it be an array? What does _meta contain? How large can content be (risk of context overflow)?
No error handling guidance. The description and implementation provide no guidance on error recovery. For example: (1) File not found → should agent try a search or list the directory? (2) Permission denied → should agent ask the user to run with elevated privileges? (3) File too large → should agent split the read? (4) Encoding errors → fallback to latin-1 or binary?
Security issue: no path sanitization documented. The tool accepts any string path. While the code comment says 'Only works within allowed directories', there is no evidence of actual path validation (e.g., realpath() normalization, prefix checking against a whitelist). Path traversal (../../etc/passwd) could leak sensitive files if the root is loosely configured. No mention of symlink following, .git/ rejection, or secrets scanning.
No idempotence or side-effect guarantees. The description does not state that read_file is idempotent and safe to retry. This is implicitly true (reads have no side effects), but LLMs benefit from explicit statements: 'This is a read-only operation and is safe to call multiple times.'
No size or encoding limits documented. The tool description does not specify: (1) Maximum file size (to prevent context explosion). (2) Supported encodings (UTF-8 only? Or does it try latin-1, UTF-16, etc.?). (3) Handling of binary files (reject with error or try text conversion?). Without these limits, an agent could attempt to read a 10GB log file or a binary executable, wasting resources and tokens.