sandboxed.sh exhibits severe quality issues across all dimensions. Of 59 tools, 52 have NO visible input schemas in the provided source. Tool descriptions are present but minimal (average ~50 chars, well below the 194-char baseline for production tools). The Rust binaries (desktop-mcp, workspace-mcp, orchestrator-mcp, assistant-mcp) are referenced in Cargo.toml but their actual tool implementations are not shown in the provided code excerpts, making schema and parameter validation impossible. Only 7 UI tools (ui_dataTable, ui_optionList, ui_progress, ui_alert, ui_notification, ui_codeBlock, ui_code) have partial input schemas visible in the Swift source. The hermes_tools.rs file references 52 tools but provides no JSON Schema definitions, parameter descriptions, or output documentation. This is a severe deficit against the rubric's core requirements that EVERY parameter has a type and description, and EVERY tool has a documented output schema.
52 of 59 tools lack visible input schemas. No JSON Schema definitions found in provided source code for hermes_tools.rs; tool definitions exist only as names and brief descriptions.
Add complete JSON Schema definitions for all 52 hermes_tools with type, description, enum, and validation constraints for every parameter. Use the provided Rust source to extract parameter signatures and document them formally.
Expand tool descriptions from ~50 chars to 150 - 250 chars, following the pattern: '[WHAT], [WHEN TO USE], [KEY PARAMETERS], [RETURN SUMMARY]'. Example: 'List all active missions with optional filtering. Use this to discover running orchestration tasks before sending messages or checking status. Accepts filters for status, owner, or time range. Returns mission IDs, titles, and current status; see start_mission to initiate new work.'
Document output schemas for all tools, including field names, types, and what downstream tools expect. E.g., get_mission should return mission_id, title, status, created_at so that send_message_to_mission can accept mission_id directly.
Add pagination parameters (limit, offset or cursor) and result-count bounds to list_* and get_*_events tools. Document the maximum result count (e.g., 'Returns up to 50 most recent events; use offset for older entries').
For destructive tools (delete_workspace, cancel_mission, workspace_bash), add a dry-run or confirm_before_delete parameter and document error recovery (e.g., 'On EACCES, check workspace permissions; on ENOENT, the workspace was already deleted').
For workspace_bash, add explicit input validation documentation: 'Input: shell command string. Validation: no semicolons, pipes, or redirects allowed; commands limited to {list, ls, pwd, find, cat, grep}. Returns: stdout/stderr as structured output with exit code.'
Parameter descriptions missing for all hermes_tools (tools 1 - 52). LLMs cannot determine when parameters are required, what values they accept, or what formats they expect. No parameter type information visible.
Output schemas not documented for any hermes_tools. LLMs cannot infer what fields to expect, which breaks downstream tool chaining and forces unnecessary discovery calls.
Tool descriptions average ~50 characters, significantly below the 194-char production baseline. Descriptions like 'List all missions with optional filtering' lack context for when to call the tool, what parameters it expects, and what data it returns.
Destructive operations (delete_workspace, cancel_mission, workspace_bash) lack confirmation or dry-run guidance. No error handling documentation indicates whether failures are retryable or require user intervention.
UI tools (ui_dataTable, ui_optionList, ui_progress, ui_alert, ui_notification, ui_codeBlock, ui_code) have partial schemas but lack required parameter descriptions in the visible Swift source. Property descriptions are either absent or generic.
Tool definitions inferred from Cargo.toml binaries (desktop-mcp, workspace-mcp, orchestrator-mcp, assistant-mcp) but actual implementations not shown. Cannot verify schemas or error handling.
workspace_bash tool executes arbitrary shell commands with DESTRUCTIVE risk. No parameter descriptions, no input validation guidance, no error recovery documentation. Exposes command injection surface without sanitization guidance.
workspace_bash
Add permission/scope declarations to each tool describing required API capabilities. E.g., get_mission requires 'read:mission', update_mission_settings requires 'write:mission', delete_workspace requires 'write:workspace admin'.
Implement tool composition guidelines: ensure every list_* tool returns IDs/references that downstream get_* or update_* tools accept. E.g., list_missions must return mission_ids compatible with get_mission, send_message_to_mission, and cancel_mission.
For UI tools, move parameter descriptions from Swift models into JSON Schema descriptions visible to the MCP client. Ensure every property (id, title, columns, rows, options, selectionMode, defaultValue, confirmed, current, total, status, message, type, language, code, lineNumbers) has a clear, actionable description.
Document error handling for at least the top-5 high-risk tools (start_mission, send_message_to_mission, workspace_bash, delete_workspace, accept_project_track) with specific error codes, recovery actions, and retry guidance.