Loading ToolBench
A Rust-based MCP server providing file operations, SQLite database integration, RAG (Retrieval Augmented Generation) with vector search, and voice recognition capabilities
Server provides 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have input schemas with type definitions and descriptions present, meeting minimum requirements. However, descriptions are terse (10-30 chars), parameter descriptions lack detail on constraints/formats, and output schemas are documented in comments but not formally exposed in tool registration. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Error handling is minimal, no recovery guidance or actionable error messages. Tool naming follows verb_noun convention (file_read, sqlite_get) but lacks context about sandboxing and safety constraints. No pagination support for list_directory despite potential for large results.
Delete a file
Read contents of a file
Write contents to a file
List contents of a directory
Delete a key-value pair from SQLite database
Get a value from SQLite database by key
Set a key-value pair in SQLite database
Descriptions are critically short (10-30 chars). Rubric baseline is 194 chars; descriptions under 20 chars score 0-20. Examples: 'Read contents of a file' (23 chars) lacks context on when to use vs alternatives, prerequisites, or return structure. LLMs cannot determine tool selection from such sparse text.
No tool annotations despite clear risk levels. file_delete and sqlite_delete are DESTRUCTIVE; file_write and sqlite_set are WRITE operations. Annotations (readOnlyHint, destructiveHint, idempotentHint) are required for agents to reason about safety and retry logic. Current code marks risks in comments but does not expose them to the MCP protocol.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
Parameter descriptions lack constraint details. 'path' parameter appears in 4 tools but descriptions do not specify: allowed characters, max length, whether relative paths are sandboxed to root_path, or what happens if path traversal is attempted. Rubric requires format, range, and constraint details in descriptions.
Output schemas documented in code comments but not formally registered. Tool struct shows output schema in docstring (e.g. file_read returns {content, exists}) but Tool::new() call in source shows Some(json!({...})) only for file_read. Other tools may lack formal output schema registration, making it impossible for clients to validate responses.
No pagination or result limits for list_directory. Tool accepts a path but schema does not include limit, offset, or page parameters. If a directory contains thousands of files, response could exhaust context window. Rubric baseline: tools returning lists must support pagination and cap results at 20-50 items.