Loading ToolBench
MCP server for file searching with advanced features by Sanket Shinde
Single tool 'search_in_file' has a clear action verb and well-formed input schema with proper JSON Schema structure. However, tool description is only 111 characters (baseline 194 for A+ tools), parameters lack guidance on format constraints and valid ranges, and critically, there is NO documented output schema. The tool returns a SearchResult object but this structure is never documented in the tool definition or handler response, LLMs cannot plan downstream operations without knowing the shape of returned data. No error handling guidance, no pagination support for result limits, and no recovery hints for common failures (file not found, permission denied, invalid regex). The implementation is straightforward but lacks production-grade polish.
Advanced file search with whole word matching, context lines, and line range filtering
No output schema documented. Tool description and handlers show the tool returns a SearchResult object with fields (file, keyword, options, totalMatches, linesWithMatches, matches), but this structure is never declared in the tool definition. LLMs cannot reliably extract or chain results without a formal output schema.
Tool description is only 111 characters, below the baseline of 194 chars for A+ tools (rubric: 10 - 1024 range). Description lacks WHEN to use it, WHAT it returns, and context for LLM selection. E.g., does it search plaintext only? Binary files? Large files? What happens if file not found?
Parameters lack format constraints and valid ranges. 'contextLines' and 'startLine' / 'endLine' accept numbers with no bounds, LLM could pass contextLines=999999 or startLine=-5, causing memory exhaustion or silent errors. No description of what happens if endLine < startLine or exceeds file length.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No error recovery guidance. Error handler returns 'Error: <message>' but does not categorize errors or guide next steps. If file not found, should LLM search for it? If regex invalid, should it suggest escaping? If permission denied, should it offer alternatives?
Parameter 'keyword' has no guidance on regex vs literal string. Code shows regex escaping is applied, but description does not state this. If LLM passes 'foo.*bar', will it be treated as a regex or escaped literally? Undocumented behavior invites misuse.
No result limiting or pagination hints. Large files can return thousands of matches, inflating the response and potentially exhausting context. No mention of how many matches are returned, whether results are truncated, or if pagination is available.
Path traversal risk not addressed. 'filepath' parameter accepts arbitrary strings with no validation. An agent could pass '../../etc/passwd' or '/etc/shadow', and the tool would attempt to read it. No documentation of path restrictions or sanitization strategy.