Loading ToolBench
A Model Context Protocol server that provides access to the currently active tab of iTerm
Server has 10 tools with complete input schemas and descriptions. Naming follows verb_noun convention (write_*, read_*, send_*, stage_*, list_*, preview_*, apply_*, reject_*). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. However, output schemas are not documented, LLMs cannot predict return structure. Error handling is minimal; no recovery guidance. Parameter descriptions are good but lack format constraints (e.g., linesOfOutput has no min/max bounds). File operation tools lack validation guidance for path traversal or permission checks.
Apply a staged change after human approval. This writes the new content and removes the change from pending queue. Use this after preview_change when the human approves. The change ID comes from list_pending_changes. Once applied, the change is permanent (trust Git for version control).
List all staged changes waiting for review. Shows change IDs, file paths, timestamps, and descriptions. Use this to see what changes are queued for human approval. Each change shows its unique ID (needed for preview/apply/reject), the file it affects, when it was staged, and its description. Essential for managing multiple pending modifications.
Preview a specific staged change with full unified diff. Shows exactly what will change if the change is applied - removed lines prefixed with '-', added lines with '+', and context lines for clarity. Use this with a change ID from list_pending_changes to help humans understand the impact before approving. Essential for reviewing staged modifications. CRITICAL: Always format the diff output in a ```diff code block immediately after calling this tool so the human can clearly see and review the proposed changes before deciding to apply or reject them.
Read the most recent output from the iTerm terminal. Always use this after write_to_terminal to see command results. Reads the specified number of lines from the terminal buffer, counting from the bottom (most recent). Use a higher line count for commands with verbose output. Essential for verifying command execution success and reading error messages.
Output schemas not documented. LLMs cannot predict return structure for any tool. E.g., read_terminal_output returns what fields? write_to_terminal returns line count, but in what format? list_pending_changes returns what structure?
Numeric parameter linesOfOutput lacks bounds. No min/max specified, LLM could pass 0, -1, or 1000000, causing errors or timeouts. Should declare range 1 - 500.
File operation tools (write_file, write_file_with_diff) do not validate paths for traversal attacks or permission checks. No guidance on what happens if path is /etc/passwd or ../../../secret. LLM could be tricked into writing to sensitive locations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Reject and delete a staged change without applying it. Removes the change from the pending queue and cleans up associated files. Use this when the human decides not to proceed with a staged modification. The original file remains untouched. Once rejected, the change is permanently deleted.
Send control characters to interrupt or control running processes in the terminal. Use 'c' to stop a running process (Ctrl+C), 'z' to suspend it (Ctrl+Z), 'd' to send EOF (Ctrl+D), or 'l' to clear screen (Ctrl+L). Essential for stopping runaway processes, exiting interactive programs, or managing long-running tasks.
Stage file changes for human review before applying them. This creates a 'pending change' that can be reviewed, previewed with diff, and then either applied or rejected. Use this when making important changes that need human approval. Each staged change gets a unique ID and is saved in .pending/ directory. This is the SAFEST approach for critical file modifications. The process: 1) Stage the change, 2) Human reviews with preview_change, 3) Human decides to apply_change or reject_change. IMPORTANT: Always follow up by using preview_change and displaying the diff in a formatted ```diff code block so the human can see exactly what will change and approve/reject the changes.
Write or append content to a file using Node.js file system. Creates the file if it doesn't exist, including any necessary parent directories. Use mode 'w' to completely replace file contents, or 'a' to add to the end. This is the most direct way to create or modify files - much more reliable than echo/cat in terminal. Perfect for saving generated code, updating configurations, or creating new files.
Write file with diff preview showing exactly what changed. This is perfect for code modifications where you want to see the changes clearly. Shows a unified diff with removed lines marked with '-' and added lines with '+'. No backups are created - trust Git for version control.
Execute commands in the active iTerm terminal. Use this to run any shell command, script, or program. Examples: 'npm test', 'git status', 'python script.py'. The command runs in the current working directory of the terminal. After execution, use read_terminal_output to see the results. Note: This doesn't return output directly - it only tells you how many lines were produced.
Error handling is absent. No guidance on what errors are retryable, user-fixable, or fatal. E.g., if write_file fails due to permission denied, should LLM retry? Ask user? Give up? No recovery path documented.
send_control_character accepts 'letter' as free-form string. Should be enum: ['c', 'z', 'd', 'l', ']']. Current schema allows LLM to pass invalid values like 'x' or 'interrupt'.