Critical gaps across all dimensions. Tool descriptions are extremely brief (5-30 chars, well below the 10-1024 baseline). Input schemas are minimal, most tools expose only a single string parameter with no type constraints, enums, or validation guidance. No output schemas documented. Parameter descriptions are generic ('File path to read', 'Search pattern') without format constraints, ranges, or examples. No error handling guidance. Dangerous tools (bash, shell, edit, write) lack confirmation patterns or dry-run support. Tool composition is poor: 'subagent' and 'agent' are near-duplicates with different parameter names ('agent' vs 'name'), forcing LLM disambiguation. No pagination, no result limits, no chaining IDs in responses. Security concerns: bash/shell/edit/write expose irreversible operations without safeguards; no audit trail or permission gates visible.

• Expand all descriptions to 50-200 chars. Include WHAT the tool does, WHEN to use it, and key prerequisites. E.g., 'read: Read file contents as text. Use to inspect code, configs, or logs. Returns full file content; for large files, use grep or find first to narrow scope.'
• Add parameter constraints: 'path' should specify min/max length, allowed characters (no '..' for path traversal), and format (absolute or relative). Use enums for 'pattern' (regex vs glob vs literal).
• Document output schemas for all tools. E.g., ls should return {files: [{name, size, modified, isDir}], total_count, next_cursor}. Include pagination and result limits (cap at 50 items).
• Add confirmation pattern to bash, shell, edit, write: require explicit 'confirm: true' parameter or return 'input_required' asking user to approve before executing irreversible operations.
• Merge 'subagent' and 'agent' into a single tool with consistent parameter naming (e.g., 'agent_name'). Document what agents are available and how to discover them.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry