Critical gaps across all dimensions. Tool definitions exist as string names only in MCP_TOOL_NAMES array (server/mcpToolHandlers.js), with no visible schema registration, parameter definitions, or structured output documentation. Only one tool (update_task_status) has partial input schema visible in the provided code. Descriptions are present but generic (10-50 chars), lacking LLM-optimized guidance on WHEN to use each tool or what it returns. No error handling patterns, no parameter validation rules, no output schemas documented. The codebase shows tool handlers exist but the MCP protocol layer is not visible in provided source, tool definitions appear inferred rather than explicitly registered with proper schemas.

• Create explicit JSON Schema for all 25 tools. Each must define required parameters, types, descriptions, and constraints (enums, min/max, patterns). Use JSON Schema format compatible with MCP spec.
• Expand tool descriptions to 50-200 characters. Include: (1) what the tool does, (2) when to use it vs similar tools, (3) key prerequisites. Example: 'Claim a task stage to lock it for work. Use after claim_task() to work on a specific stage. Returns stage_id and lock_token.'
• Document output schemas for all tools. Specify returned fields, types, and which IDs/references are needed for downstream tool calls. Example: list_projects should return [{project_id, name, status, repo_url}].
• Add parameter descriptions for all inputs. For each parameter, state: type, format, constraints, and examples. Example: 'status (string, enum: pending|in_progress|completed|blocked), the new task status'.
• Implement error handling patterns: (1) categorize errors as retryable/user-fixable/fatal, (2) include the invalid value and constraint violated, (3) suggest recovery steps. Example: 'Invalid status: got "pending", must be one of: in_progress, completed, blocked. Try update_task_status() again with a valid status.'