Critical failures across all dimensions. Tool definitions are inferred from file references (src/Tool.py) rather than visible in source code. No input schemas, parameter descriptions, or output schemas are present in the provided Rust codebase. Descriptions are minimal (16-32 chars, below 20-char floor). No evidence of parameter validation, error handling guidance, or composition patterns. The server appears to be a Python wrapper exposed via Rust MCP bridge, but tool registration and schema details are not visible in the provided code sample.

• Expose tool definitions explicitly in Rust code with full JSON Schema input/output definitions. Use serde_json to define and register tools with the MCP server, not via external Python files.
• Expand tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and WHAT it returns. Example: 'port_manifest: Analyze the active Python workspace and return a summary of module structure, dependencies, and compatibility issues. Use this first to understand the codebase before running query_engine.'
• Add parameter descriptions and type constraints for every input. If port_manifest accepts a 'workspace_path' parameter, document it as: 'workspace_path (string, required): Absolute path to the Python project root. Must be a valid directory.'
• Document output schemas with field names, types, and descriptions. Example: 'Returns {modules: [{name: string, imports: string[], issues: string[]}], total_modules: number, scan_time_ms: number}'.
• Implement error handling with recovery guidance. Return structured errors like '{error: "workspace_not_found", message: "Path /invalid/path does not exist", suggestion: "Verify the workspace_path parameter points to a valid Python project directory."}'.