Five tools with identical schemas and descriptions. All have proper input schemas with typed parameters and descriptions (prompt, model, cwd, timeoutMs, idleTimeoutMs). Tool descriptions are adequate (120-180 chars) but generic, they describe WHAT each agent does but lack WHEN to use each one or how they differ. No output schemas documented. No error handling guidance. Model parameter validation is strong (regex pattern enforced). Missing: per-tool differentiation, output structure docs, recovery guidance for common failures.

• Add per-tool output schema documentation. Specify whether each agent returns stdout/stderr, structured JSON, or free text, and what fields are present (e.g., {exitCode, stdout, stderr, changes: [{file, before, after}]}). This enables LLMs to extract and chain results.
• Differentiate tool descriptions by agent capability and use case. E.g., 'Codex: GPT-4-powered agent for complex refactoring and multi-file changes' vs 'Cursor: Repo-aware agent optimized for context-aware edits within existing codebases'. Help LLMs select the right agent.
• Add error handling guidance to each tool description. E.g., 'Timeouts (>30min) indicate a stalled agent, retry with a simpler prompt or smaller cwd. Exit code 1 usually means the agent rejected the task; check stderr for details.'
• Document the model parameter constraint ('must match [A-Za-z0-9][A-Za-z0-9._:/-]{0,127}') in the parameter description itself, not just in tool description. LLMs read param descriptions, not tool docstrings.
• Add a 'permissionMode' parameter to the schema (currently only in code) so clients can request read-only runs for review workflows. Document when this is supported per agent.