Loading ToolBench
The LLM-native shell - an MCP server providing interactive shell control with noise-dampened output, process supervision, and persistent sessions
mish presents 13 shell-interaction tools with complete input schemas and reasonable descriptions. Naming is action-verb-based and descriptive (sh_spawn, sh_interact, sh_call, handoff_initiate, lock_create). Most parameters are typed and described. However, descriptions are terse (average ~80 chars, baseline 194), and several tools conflate multiple concerns. Output schemas are not documented. Error handling guidance is absent. The tool set demonstrates good structural discipline but lacks LLM-optimization depth expected of A-grade servers.
Pause execution and hand terminal control to a human operator
List active operator handoffs
Create a coordination lock for serializing concurrent operations
Release a coordination lock
Wait for a lock to be released
List running mish server instances with process health status
Fire-and-forget command execution with noise-dampened output, category detection, and compression via grammar rules
Send input to an active session, read output, or kill the process
Descriptions are minimal (average ~80 chars vs. baseline 194 chars). Examples: sh_session_list ('List all active persistent sessions'), ps ('List running mish server instances with process health status'), lock_create ('Create a coordination lock for serializing concurrent operations'). These are self-evident from names and lack LLM-optimization guidance on WHEN to use each tool or WHAT dependencies exist.
No output schemas documented. sh_spawn, sh_interact, sh_call, sh_session_send, sh_session_list, handoff_list, ps, etc. all lack explicit response structures. LLMs cannot plan downstream chaining (e.g., does sh_session_list return session IDs for use in sh_session_send?) without seeing output fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Close a named persistent session
List all active persistent sessions
Send input to a named persistent session and wait for output
Create a persistent interpreter session (Python REPL, psql, node, etc.)
Start a persistent shell session with optional PTY, timeout, and wait_for sentinel
No error handling guidance. Tools like sh_spawn (timeout_sec), sh_call (timeout_sec), sh_session_send (timeout_sec) support timeouts but do not document what error the LLM receives, whether it is retryable, or what to do next. No recovery guides present.
Naming ambiguity: sh_spawn, sh_interact, sh_call, sh_session_start, sh_session_send all operate on persistent shell sessions but use different naming conventions (sh_* prefix vs sh_session_* prefix). LLMs may conflate 'sh_spawn + sh_interact' with 'sh_session_start + sh_session_send' without explicit differentiation.
'ps' tool name is generic and non-descriptive. Does it list processes, or mish server instances? Description clarifies but LLM must read it. Rename to list_mish_instances or get_server_health for clarity.
sh_call combines multiple concerns: execution, timeout, output mode (compressed/raw/json), and grammar-based compression. Output mode is an enum but not explained in tool description, LLMs cannot infer when to use 'compressed' vs 'raw' vs 'json'.
handoff_initiate and handoff_list lack context on the handoff coordination model. Does handoff_initiate block? Is the LLM paused? What does share_output=true vs false mean for downstream reasoning? These critical details are missing.
lock_create, lock_release, lock_watch have no explanation of lock semantics. Are locks advisory or enforcing? Does lock_watch block indefinitely or timeout? What is the failure mode if a lock is held? Concurrency tools require precise specification.
sh_interact 'action' enum includes send_input, read_tail, kill but lacks guidance on when to use read_tail before send_input, or whether state is preserved between calls. Implicit semantics invite misuse.