Loading ToolBench
Universal port of ToolRush v2 (Hermes Agent plugin) to MCP-capable agent harnesses. Exposes fast file reading, batch operations, content search, directory traversal, and persistent shell execution as MCP tools over stdio.
ToolRush exposes 8 tools with complete input schemas and descriptions. Naming follows verb_noun convention (fast_read, batch_read, fast_search, etc.). Descriptions are detailed (100-300 chars) and explain WHAT, WHEN, and HOW. However, output schemas are not formally documented in the source, responses are inferred from code comments. Parameters have types and descriptions, but lack enums for constrained values (e.g., no enum for case_sensitive boolean). Error handling is present but generic ('binary file', 'not UTF-8 decodable') without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata. Batch tools lack per-operation error isolation documentation in schemas.
1..16 shell commands through ONE call, order-preserving, whole batch validated before dispatch, per-op error isolation.
1..16 reads through ONE call, input order preserved, whole batch validated before dispatch — serial by design.
1..16 searches through ONE call, order-preserving, whole batch validated before dispatch, per-op error isolation. The Go server fans the ops out in parallel goroutines.
Lane status, versions, kill-switch state, counters.
In-process read: one open()/stat, line-number gutter, BOM strip, binary sniff, beyond-EOF hint, mtime-keyed cache.
Content search. Primary: direct rg transport (real ignore files, real regex grammar). Fallback: pure-Python walk when rg is missing or TOOLRUSH_SEARCH=0. context=N adds N lines of gutter around each hit.
Output schemas not formally documented. Code comments describe response structure (success, error, content, total_lines, file_size, hint) but no JSON Schema definitions visible in tool registration. LLMs cannot reliably parse or chain results without explicit output type declarations.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata (READ_ONLY, IRREVERSIBLE). warm_exec and batch_exec are destructive but lack destructiveHint annotation. Agents cannot infer safety properties from tool definitions alone.
Error responses lack recovery guidance. Examples: 'binary file (NUL byte in first 8000 bytes)' and 'binary file (not UTF-8 decodable)' tell the agent a file is binary but not what to do next. Should suggest: 'File is binary. Use fast_tree to list directory contents instead, or specify a text file path.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Budgeted directory listing: deterministic dirs-first alphabetical walk, depth/entry budgets, basename pattern filter, shared skip list. No .gitignore parsing.
ONE persistent bash (--noprofile --norc), per-call unique frame markers, rc capture, cwd/exports survive across calls, process-group kill on timeout, NEVER retries a submitted command. TOOLRUSH_PERSIST=0 -> spawn-per-call fallback.
Batch tools (batch_read, batch_search, batch_exec) document 'per-op error isolation' in descriptions but schemas do not show how per-operation errors are returned. Response structure for partial failures is unclear, does the tool return an array of results with per-item success/error, or a single error for the whole batch?
Parameter 'pattern' in fast_tree and fast_search lacks format/constraint documentation. Is it a glob, regex, or literal string? Baseline rubric requires 'regex pattern, length limit, or character restriction' to be stated in descriptions. Currently vague.