Loading ToolBench
An agent framework using Google ADK that integrates Model Context Protocol (MCP) tools, specifically for filesystem management via the @modelcontextprotocol/server-filesystem MCP server
This MCP server has fundamental structural issues. The source code shows only 2 tools (list_directory, read_file) that appear to be instantiated from an external MCP server (@modelcontextprotocol/server-filesystem) via MCPToolset wrapper, not defined directly in this codebase. Tool definitions are not explicitly visible in the provided source, they are delegated to a subprocess. Descriptions are minimal (13-24 chars each, below the 34-char p10 baseline), and there is no visible input schema definition in the source code for either tool. Parameter descriptions exist but are extremely terse. The server acts as a thin wrapper around an external filesystem MCP server without adding quality improvements or customizations. No error handling, validation, or output shaping is evident.
List contents of a directory in the filesystem
Read the contents of a file
Tool definitions are not directly visible in source code. Tools are delegated to an external subprocess (@modelcontextprotocol/server-filesystem) via MCPToolset. This means input schemas, detailed descriptions, and error handling are not defined in this codebase and cannot be validated or customized.
No input schemas visible in source code. The provided tool specifications show minimal schema information ('path' parameter as string only, no additional constraints, no format declarations, no min/max lengths).
Descriptions are extremely brief (13 and 24 characters respectively). 'List contents of a directory in the filesystem' is only 50 chars, below the 194-char production average, and lacks context for LLM tool selection (when to use vs alternatives, what structure is returned, pagination behavior).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Parameter 'path' has a description ('The directory path to list' / 'The file path to read') but provides no validation guidance. No mention of constraints (required format, absolute vs relative, max length), error cases (permissions, non-existent paths), or how to handle special characters or symlinks.
No documented output schema. LLMs cannot infer what fields list_directory returns (is it just filenames? sizes? timestamps? recursive?). No pagination or limit parameters visible, risking context window exhaustion on large directories.
No error handling guidance. What happens if a path doesn't exist? If permissions are denied? If a file is binary? The LLM receives no recovery hints (try searching first, offer alternatives, etc.).
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). While both tools are marked READ_ONLY in the metadata, this is not reflected in MCP protocol annotations that would inform the LLM and calling framework.
No input validation visible. LLMs could pass '../../../etc/passwd' (path traversal), very long paths, or null bytes. No sanitization against command injection or symlink attacks.
Tool composition is minimal. No batch tools (e.g., read_multiple_files), no discovery/pagination helpers, no folder-aware search. Common user intents ('show me all Python files in this directory') require multiple sequential tool calls.