Loading ToolBench
A Java-based MCP server for token-optimized code analysis and workspace navigation. Provides structural code queries, file reading with diff optimization, search capabilities, and JavaScript-based scripting against a workspace index.
Token-guard is a sophisticated Java MCP server with 11 well-designed tools for code analysis and workspace manipulation. Tool naming follows verb_noun conventions (query_codebase_structure, execute_script, apply_edit). Descriptions are detailed and contextual (avg ~150 chars), explaining WHAT, WHEN, and WHY. Input schemas are present with typed parameters and descriptions. However, output schemas are not explicitly documented in the visible code, only input schemas are defined. Error handling is mentioned but recovery guidance is sparse. Security considerations (read-only hints, write operations) are implicit in descriptions but not formally annotated. The server demonstrates strong patterns around tool composition (search_tools → describe_tools → execute_tool chain) and parameter clarity (e.g., query_type enum, depth/map_tokens constraints).
Edit a workspace file by exact string replacement. Each old_string must occur exactly once in the file (include surrounding context to disambiguate). To create a new file, pass a single edit with an empty old_string. Returns a unified diff of the change — you do not need to re-read the file.
Get the full parameter schemas for downstream tools found via search_tools. Pass the server/tool names; then call execute_tool with matching arguments.
Run a small JavaScript program locally against the workspace and return only its result — far cheaper than chains of individual tool calls. The value of the last expression is returned (objects are JSON). Available APIs (read-only): fs.read(path, {startLine?, endLine?}), fs.glob(pattern), fs.grep(pattern, {glob?, maxResults?}), fs.stat(path), index.symbol(name), index.callers(name), index.callees(name), index.outline(path), index.search(query). No network, no writes (use apply_edit), 5 s limit.
Invoke a downstream MCP tool by its server/tool name (from search_tools). Pass 'arguments' matching the schema from describe_tools. Read-style results are cached; repeated identical calls cost nothing downstream.
List workspace files as a compact indented tree — far smaller than raw directory dumps (gitignore-aware, noise directories excluded, output capped). Use depth to control recursion.
Output schemas not documented. Tools describe inputs but not return types. LLMs cannot plan downstream calls or extract chaining IDs without knowing response structure.
Tool annotations (readOnlyHint, destructiveHint) not visible in schema. Risk/WRITE labels exist in metadata but not formally declared in MCP tool definitions.
Error handling guidance sparse. Tools mention constraints (e.g., 'exactly once' for apply_edit) but do not document recovery paths or error categories (retryable vs fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Query the codebase's structure instead of reading files: class/method outlines, signatures, callers/callees, dependencies, type hierarchy, symbol search. An outline is a small fraction of the size of the file it summarizes — PREFER this over reading whole files to understand code. Java files only.
Token-optimized file reading — PREFER this over generic file reads. Re-reading a file you have already seen never returns the full content again: unchanged files return a one-line notice, changed files return only a unified diff of what changed. Use start_line/end_line to read a specific range.
Rebuild working state after context compaction or a restart: a dense summary of the files read and edited in this workspace's recent sessions, recent errors, and the last tool calls. Call this FIRST when you have lost track of prior work instead of re-reading files.
Search the documentation of the script APIs available in execute_script. Call this first to discover the right functions, then write a script.
Search workspace file contents with a regex. Returns only the matching lines grouped by file with line numbers, hard-capped to stay small — use this instead of reading files to locate code. Repeated identical searches are served from cache at no recomputation cost.
Find tools from the connected downstream MCP servers by describing what you need (e.g. 'create a github issue'). Returns ranked one-line summaries as server/tool names. Then call describe_tools for full schemas and execute_tool to invoke — this keeps unused tool schemas out of context.
restore_context has empty input schema (no parameters). Description is vague ('rebuild working state'). LLMs cannot determine when to call it or what it returns.
Pagination not visible for list_directory or search_files. If results can exceed context limits, tools should accept limit/offset and return total_count or next_cursor.