Loading ToolBench
Universal MCP Filter & CLI Proxy to minimize LLM token consumption by filtering and compressing command outputs before they reach LLM context
clov is a token-optimization proxy with 23 tools spanning file operations, git, cloud CLIs, and diagnostics. Strengths: consistent tool naming (verb_noun), comprehensive parameter schemas with types, and clear descriptions focused on compression/filtering semantics. Weaknesses: output schemas are undocumented (critical gap per pattern:tool), error handling lacks recovery guidance, and descriptions are functional but brief (averaging ~80 chars, below the 194-char production baseline). Most tools are READ_ONLY with appropriate risk annotations, but two WRITE tools (hook, fetch) lack confirmation/dry-run patterns. Tools like 'brief', 'digest', and 'graph' perform heuristic summarization with internal logic but no documented output structure for LLMs to chain on. The codebase shows mature CLI implementation (Rust, proper defaults, option flags) but treats MCP as a thin passthrough rather than designing for agent composition.
AWS CLI with compact output (force JSON, compress)
Generate 2-line technical summary (heuristic-based)
Run tests and show only failures
Run command and show heuristic summary
Docker commands with compact output
Run command and show only errors/warnings
Download with compact output (strips progress bars)
Output schemas undocumented for all tools. Tools like 'brief', 'digest', 'graph', 'check', 'fail' perform processing and return structured output, but MCP clients cannot see what fields to expect. Agents cannot chain these tools effectively or extract data for downstream operations.
No recovery guidance in error handling. Tools accept arbitrary arguments and invoke external CLIs (git, aws, kubectl, docker) without documenting error cases or what the LLM should do if the command fails (retry, alternative approach, user input needed).
WRITE tools lack confirmation/dry-run patterns. 'hook' modifies CLAUDE.md and settings.json; 'fetch' downloads files. Neither tool offers a dry-run or confirmation step before execution. Agents can accidentally modify configuration or overwrite files without recourse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
List directory contents with token-optimized output (proxy to native ls)
GitHub CLI (gh) commands with token-optimized output
Git commands with compact output
Summarize project dependencies
Initialize clov instructions in CLAUDE.md
Kubectl commands with compact output
Filter and deduplicate log output
Directory tree with token-optimized output (proxy to native tree)
Ultra-condensed diff (only changed lines)
pnpm commands with ultra-compact output
PostgreSQL client with compact output (strip borders, compress tables)
Find files with compact tree output (accepts native find flags like -name, -type)
Show JSON structure without values
Compact grep - strips whitespace, truncates, groups by file
Show environment variables (filtered, sensitive masked)
Read file with intelligent filtering
Descriptions are functional but below production baseline (avg ~80 chars vs 194-char baseline). Descriptions focus on what the tool does (e.g. 'List directory contents') but omit WHEN to use it or WHY it differs from similar tools. 'files' vs 'scan', when does an LLM pick one over the other?
Parameter descriptions lack constraint details. 'level' in 'view' has enum [none, minimal, aggressive] but the description does not explain what each level filters. 'max_lines' in 'view' has no range. 'depth' in 'schema' defaults to 5, is that optimal? Descriptions should state why, not just expose the flag.
No pagination support in tools that return lists. 'scan' returns 'max' results (default 50); 'search' returns 'max' (default 50). No total count or next_cursor. If an agent needs more results, how does it ask for the next batch? No documented pagination pattern.
Heuristic summarization tools (brief, digest) expose internal model download logic ('force_download' flag) in the schema. This is implementation detail leakage. The 'model' parameter in 'brief' only accepts 'heuristic', but the schema and description suggest it might accept other values. Overspecifies internals.
Proxy tools with variable argument arrays lack input validation guidance. 'git' passes 'command' as a subcommand enum, but accepts arbitrary 'directory', 'config_override', 'git_dir', 'work_tree' flags. If the user passes invalid git flags, the tool fails with a git error, not an MCP-level actionable error. Agents cannot recover.