Loading ToolBench
File context server for Model Context Protocol - reads and analyzes code files with advanced filtering, chunking, caching, and code analysis capabilities
This file context server has 11 tools with reasonable schema coverage and descriptions, but suffers from uneven quality across tools, missing parameter constraints, and incomplete error handling guidance. Most tools have descriptions (good baseline compliance), but descriptions vary widely in actionability. Tool names follow verb-first conventions well (read_, get_, search_, analyze_, list_, watch_, unwatch_, set_). However, parameter descriptions lack constraint details (enums, ranges, formats), and output schemas are not explicitly documented. The server implements file operations with appropriate caching and streaming logic, but the tool interface does not expose rich enough metadata for LLM planning.
Analyze code files for metrics, complexity, and structure. Returns code metrics, outline, language detection, security issues, style violations, and complexity metrics.
Get the total number of chunks for a file or directory. Returns chunk metadata to help with planning read_context requests. Use this before calling read_context with specific chunk numbers.
Get the current context specification including active profile and file selections.
Get available context profiles. Profiles define how files are filtered and included in context.
Get a list of all currently watched paths.
List files that have been modified since a given timestamp. Useful for tracking changes between context generations.
WARNING: Run get_chunk_count first to determine total chunks, then request specific chunks using chunkNumber parameter. Read and analyze code files with advanced filtering and chunking. The server automatically ignores common artifact directories and files: - Version Control: .git/ - Python: .venv/, __pycache__/, *.pyc, etc. - JavaScript/Node.js: node_modules/, bower_components/, .next/, dist/, etc. - IDE/Editor: .idea/, .vscode/, .env, etc. **WARNING** use get_chunk_count first to determine total chunks, then request specific chunks using chunkNumber parameter.
Output schemas not documented. Tools like analyze_code, watch_path, get_profiles lack explicit response schema definitions. LLMs cannot plan downstream actions or extract required fields when return structures are implicit.
Parameter constraints missing. fileTypes accepts array OR string but the union type is not clearly described. maxSize, encoding, chunkNumber lack ranges or format constraints. contextLines and maxResults in search_context have no bounds documented.
Error handling and recovery guidance missing. Tools do not document what errors might occur, when they are retryable, or what the LLM should do next. No guidance on 'path not found', 'permission denied', 'file too large' scenarios.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Search for patterns in files. Supports regex patterns and context extraction around matches. Returns matching lines with surrounding context.
Set the active context profile.
Stop watching a path for file system changes.
Start watching a path for file system changes. Emits events when files are added, modified, or deleted.
Pattern parameter in search_context accepts raw regex but no guidance on invalid patterns, syntax errors, or performance concerns (e.g., ReDoS). Description does not warn about resource intensity or timeouts.
analyze_code description vague. States it 'returns code metrics, outline, language detection, security issues' but does not specify what fields are returned, or how to interpret complexity metrics. LLM cannot know which sub-fields to extract.
watch_path, unwatch_path lack detail on behavior. Do they return event objects? How are file changes reported, via streaming, polling, or another mechanism? The tool definitions do not explain the interaction model.
No idempotency guarantees documented. set_profile and watch_path could have side effects. Are they idempotent? Can they be safely retried? This matters for agent error recovery.
Pagination not supported in search_context. If a pattern matches thousands of lines, the tool returns all of them, risking context window overflow. Should accept maxResults and return has_more flag.
fileTypes parameter inconsistency. Description says 'WITHOUT dots (e.g. ["ts", "js", "py"] or just "ts")' but the schema allows both array and string. The union type creates ambiguity for LLMs, should accept only one form.