Critical failures across all dimensions. Tool definitions are inferred from benchmark test files rather than visible in actual MCP server code (Sources/AIShellMCP/MCPServer.swift shows only factory_diagnostics with empty schema {}). Nine of ten tools lack verifiable schemas, descriptions are vague/generic, and no parameter documentation exists. Tool names lack clear verb-noun structure (e.g., 'run_check', 'run_observe' are ambiguous). No evidence of error handling, output schemas, or composition patterns. This server appears to be a test harness, not a production MCP implementation.

• Add explicit JSON Schema definitions to all tools in MCPServer.swift. Include type, description, and constraints for every parameter. Example: {"type": "object", "properties": {"file_path": {"type": "string", "description": "Absolute path to file to read"}}, "required": ["file_path"]}
• Rename tools to follow verb_noun pattern: run_check → validate_repository, run_observe → monitor_run, workspace_wait → wait_for_file_change, artifact_read → read_artifact_logs, change_impact → analyze_change_impact.
• Expand tool descriptions to 50-200 characters, answering: What does it do? When should the LLM call it? What does it return? Example: 'Validates repository integrity by running diagnostics. Returns status, errors found, and remediation steps. Call this before making changes to ensure clean state.'
• Document output schemas for all tools. Specify return type (object/array), field names, types, and what each field represents. Example: {"type": "object", "properties": {"status": {"type": "string", "enum": ["pass", "fail"]}, "errors": {"type": "array", "items": {"type": "string"}}}}
• Add error handling guidance. For each tool, document what errors can occur, why, and what the LLM should do next. Example: 'If file not found, call search_context() with a partial path. If permission denied, request elevated access.'