Loading ToolBench
Comprehensive security sanitization library for Model Context Protocol (MCP) servers with trusted security libraries
mcp-sanitizer defines 5 tools with basic schemas and descriptions, but exhibits significant quality gaps. All tools have descriptions but they are terse (14-53 chars), well below the 50-200 char baseline for LLM-optimized docs. Schemas are present but minimal: parameters lack type specifications beyond 'string', no enums, no format constraints, and no documented output schemas. Tool names are action-verb based (read_, write_, list_, fetch_, search_) which is correct, but descriptions fail to explain WHEN to use each tool or dependencies. Error handling is not documented. The tools are file/URL utilities without clear composition guidance. Per-tool averages: naming 65 (acceptable action verbs), description 25 (critically short), schema 30 (type info missing). This server prioritizes sanitization library functionality over user-facing tool design.
Fetch content from a URL (with URL sanitization)
List files in a directory (with path sanitization)
Read contents of a file (with path sanitization)
Search for files with pattern (with pattern sanitization)
Write content to a file (with path and content sanitization)
Descriptions are critically short (14 - 53 chars) vs. baseline 50 - 200 chars. Examples: 'Read contents of a file (with path sanitization)' (51 chars), 'Fetch content from a URL (with URL sanitization)' (49 chars). These lack context on WHEN to use the tool, prerequisites, or dependencies.
Input schemas lack type information beyond 'string' and have no constraints (no enums, patterns, min/max, format). Parameter descriptions are terse one-liners (e.g. 'Path to the file to read') that do not explain expected format, valid values, or constraints an LLM needs to construct valid calls.
No documented output schemas. Tools return unspecified responses (examples in basic.js show {success, content} or {success, files} but these are examples, not formal specs). LLMs cannot plan downstream tool chains without knowing what fields are returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Error handling is not documented in tool definitions. Tool descriptions do not indicate what errors can occur or how the LLM should recover (e.g. 'File not found' is retryable; 'Access denied' requires user action).
No idempotency declaration. write_file is clearly destructive/non-idempotent (overwrites file) but no annotation or description warns the LLM about retry hazards. search_files and list_directory lack clarity on side effects.
Parameter naming inconsistency: 'path' is used for both read_file and list_directory (overloaded), but context differs, file path vs. directory path. Should use 'file_path' and 'directory_path' to avoid LLM confusion. fetch_url uses 'url' correctly; search_files correctly uses 'directory' and 'pattern'.
No pagination or result limiting documented for list_directory and search_files. If directories have hundreds of files, returning all results could blow context windows. Baseline pattern requires page/limit parameters and total count.