Loading ToolBench
Model Context Protocol server for knowledge store management with file operations, metadata handling, and trading strategy storage
This server has significant quality gaps. All three tools have basic descriptions (10-60 chars) that fall well below the 194-char baseline for production tools. The input schemas are present but minimalist, they lack parameter descriptions, which violates the critical rule that 'Every parameter needs a description.' The server implements file I/O on a knowledge store, but none of the tools document their output schema, making it impossible for LLMs to understand what to do with results. Error handling is not visible in the tool definitions. The tools are competently named with verb prefixes (read_, list_, search_), but descriptions are too terse to guide LLM selection. No tool accepts human-friendly identifiers, read_file requires a bare 'filename' parameter with no guidance on format or source. The schema for search_files is minimal and provides no documentation of result structure, pagination, or how matches are ranked.
Extract all definitions from all files in the knowledge store and return them as a structured map
Get detailed metadata information about a file
Get all files in a specific category (document, text, image, etc.)
Get overview of the knowledge store with statistics and categories
Get all trading strategies from MongoDB database
Get a specific trading strategy by name or ID
List all files in the knowledge store with basic info
List all files with rich metadata including descriptions, tags, categories, and size warnings
All parameter descriptions are missing. The 'filename' param in read_file has no description explaining expected format, whether it's a path or basename, or where files are located. The 'query' param in search_files lacks guidance on syntax, matching behavior, or supported operators.
Output schemas are not documented. Tools return unspecified structures, LLMs cannot plan downstream actions or know what fields to extract. A production tool must document what read_file returns (file content as string? metadata? encoding?), what list_files returns (array of what? with which fields?), and what search_files returns (match ranking? line numbers? file metadata?).
Tool descriptions are too short (10 - 60 chars, vs. 194-char baseline). 'Read the content of a specific file' is barely actionable. Does it return raw bytes or UTF-8 text? Does it support binary files? When should the LLM use read_file vs. list_files? Descriptions must answer: what does it do, when to use it, what it returns, and prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 6 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Read the content of a specific file
Search for files containing specific text in content
Search files by metadata (description, tags, category, summary) - smarter than content search
Search trading strategies by text query
Update metadata for a file (description, tags, category, summary)
Write content to a file
read_file parameter 'filename' has no guidance on format. Is it a relative path? Absolute? Basename only? Must it have an extension? This ambiguity will cause LLM errors when the tool rejects malformed inputs.
search_files provides no guidance on query syntax or matching semantics. Does it support regex? Boolean operators? Case-insensitive matching? Field-specific search? Without this, LLMs will guess and make invalid queries.
No error handling guidance visible. What happens if read_file is given a nonexistent file? If search_files returns no matches? If list_files encounters permission errors? Tools must return actionable error messages telling LLMs what to do next (e.g., 'File not found. Available files: ...')
list_files has no parameters for pagination or limits. If the knowledge store contains thousands of files, this tool will return all of them, blowing the context window. Must support limit and offset/cursor parameters and document max result size.
No documentation of file size limits for read_file. Will it read 1 MB files? 1 GB files? Multi-gigabyte files will exhaust memory and context. Must enforce a reasonable limit (e.g., 10 MB) and error gracefully.