Loading ToolBench
MCP server providing terminal functionality through Electron
This server has 4 tools with basic schemas and minimal descriptions. Tool names follow a verb_noun pattern (terminal_start, terminal_execute, terminal_output, terminal_stop), which is positive. However, descriptions are very brief (10-25 chars), severely under the production baseline of 194 chars. Parameters lack depth, no format constraints, ranges, or dependency documentation. No output schemas are documented. Error handling is absent from the tool definitions. The code shows basic message handling but no input validation, no actionable error messages, and no recovery guidance. Security concerns: terminal execution tools accept arbitrary commands with no sandboxing, validation, or permission checks. This is a low-maturity implementation that would not pass code review for production agent tooling.
Execute a command in an existing terminal session
Get the current output of a terminal session
Create a new terminal session and execute an initial command
Terminate a running terminal session
All tool descriptions are critically short (10-25 chars). Production baseline is 194 chars. Descriptions must explain WHAT the tool does, WHEN to use it, and what it returns. Current descriptions ('Create a new terminal session and execute an initial command') lack context for LLM selection and do not document side effects or prerequisites.
No output schemas documented. Tools return unspecified responses. LLMs cannot plan downstream tool calls or extract the right data without knowing the response structure (field names, types, whether pagination is supported, what IDs are included for chaining).
No input validation or error handling in tool implementations. The index.js code has no checks for command injection, path traversal, or malicious payloads. terminal_start and terminal_execute accept arbitrary shell commands without sanitization or constraints. No error responses guide recovery (e.g., 'sessionId not found, list active sessions with terminal_list').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Irreversible operation (terminal_stop) lacks confirmation or dry-run pattern. Agents can accidentally kill running sessions without warning. No idempotence guarantee, repeated calls may have different side effects.
Parameter descriptions are missing or trivial. The 'command' param in terminal_start/terminal_execute has description 'Command to execute in the new terminal session' but no format constraints, examples of valid commands, timeout expectations, or context about shell environment. 'sessionId' param in terminal_execute/terminal_output/terminal_stop lacks guidance on how to obtain one or what happens if it is invalid.
No tool composition or chaining support documented. There is no terminal_list, terminal_get_sessions, or terminal_describe tool. An agent that needs to know which sessions are active must guess sessionIds. The tools do not return sessionIds in a consistent format, risking broken reference chains.
Security: no permission gates or scope declarations. terminal_start and terminal_execute allow arbitrary shell commands (spawn, exec). There is no check for a calling user's authority, no scope-based access control, and no audit trail (who executed what command, when, with what result).