Loading ToolBench
Lightweight MCP gateway proxy that sits between MCP clients and MCP servers, adding auth, rate limiting, tool-level access control, audit logging, and Prometheus metrics
Three tools with minimal definitions. All have basic input schemas (text/path parameters), but descriptions are extremely terse (10-13 chars each, well below the 34-char p10 baseline). No parameter descriptions provided. No output schemas documented. No error handling guidance. Tool names lack action verbs (echo, read_file, dangerous_delete are acceptable but minimal). This server reads as a mock/demo implementation rather than production-grade tooling.
Delete a file. The demo policy denies this tool.
Echo back the provided text.
Read a file from disk.
All tool descriptions are under 20 characters (echo: 10, read_file: 13, dangerous_delete: 13). Descriptions must be 34+ chars (p10 baseline) to provide LLM context for tool selection.
No parameter descriptions provided. The 'text' and 'path' parameters lack any explanation of expected format, constraints, or usage context. LLMs cannot infer parameter meaning from names alone.
No output schemas documented. Callers cannot know what fields to expect from tool responses, breaking downstream tool chaining and forcing LLMs to guess at response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
dangerous_delete tool lacks error handling guidance and confirmation mechanism. Destructive operations should support dry-run or explicit confirmation to prevent accidental data loss.
read_file tool has no path validation or traversal protection documented. Tool accepts arbitrary 'path' parameter with no constraints, enabling potential directory traversal attacks.