Loading ToolBench
An MCP server that provides file system context to LLMs
This server has 18 tools with READ_ONLY, WRITE, and DESTRUCTIVE risk levels, but the source code provided does not include the actual tool definitions, schemas, or parameter descriptions. Only tool names and risk classifications are visible; the cmd/main.go file where tools are registered is not included in the source excerpt. Without access to the schema definitions, input parameter types, descriptions, and output formats, scoring must be conservative. Based on visible evidence: (1) Tool naming follows verb_noun pattern (read_file, list_files, write_file, delete_file), solid naming. (2) No parameter descriptions, schemas, or input validation logic visible in the provided code. (3) The server framework code shows JSON-RPC handling and error responses, but tool-specific definitions are absent from the sample. (4) Security concerns: delete_file and other destructive operations are exposed without visible permission gates or confirmation patterns. (5) Output schemas for tools are not documented in the provided excerpts.
Analyze all files in a directory for code metrics
Analyze a file for code structure, imports, and complexity metrics
Clear the file cache
Count the number of lines in a file
Generate a code outline for a file showing classes, functions, and imports
Get file cache statistics
Get the number of chunks a file would be split into at a given chunk size
Get the tree structure of a folder
List files in a directory with optional filtering
No tool input schemas visible in source code. Cannot verify parameter types, required fields, constraints, enums, or field descriptions. Per HARD SCORING RULE: if no input schema visible, schema score must be 0.
No tool descriptions visible in source code. Tool registration in cmd/main.go not provided. LLMs cannot determine when or why to select a tool without descriptions. Per HARD SCORING RULE: if description missing, description score must be 0.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 19 | 2024-11-05+ | v1 |
Read a specific chunk of a file
Read the contents of a file
Destructive tools (delete_file) exposed without visible permission gates, confirmation patterns, or dry-run support. No evidence of access control checking before deletion. Risk of accidental data loss.
Write/mutating operations (write_file, create_directory, copy_file, move_file, delete_file) lack documented idempotency guarantees. Agents may retry on ambiguous failures, causing duplicate file creation or unintended overwrites.
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract required fields if response structure is unknown. Analysis tools (analyze_file, analyze_directory) with complex outputs are especially problematic.
list_files and search_files have no visible pagination parameters (limit, offset, page_size). Large directory listings could exceed context window or timeout.
Error handling relies only on generic JSONRPCError with Code and Message fields. No recovery guidance visible, errors do not tell LLMs what to do next or whether errors are retryable.
Parameters likely accept file paths as strings with no visible input sanitization. Risk of path traversal attacks if untrusted agent input is passed to filesystem operations. No evidence of validation against '..' or absolute path injection.