Critical failures across all dimensions. Tool definitions are inferred from file references only, no explicit schema registration visible in source. No parameter descriptions, no input schemas, no output schemas documented. Descriptions are generic one-liners (10-20 chars) that fail to explain WHEN to use each tool or what it returns. Security-critical tools (http_request, deploy_service, app_lifecycle) lack permission gates, scope declarations, or audit trail guidance. No error handling patterns visible. Tool names are inconsistent: some use verbs (probe_*, run_*, parse_*), others are nouns (secret_scan, sast_scan). No evidence of idempotency, pagination, or composition patterns. This server is not production-ready.

• Create explicit tool registration in server/src/mcp/tools/index.js with full JSON Schema for each tool. Include type, description, and constraints for every parameter.
• Expand tool descriptions to 50-200 characters. Answer: What does it do? When should the LLM call it? What does it return? Example: 'Probe target endpoint for SQL injection vulnerabilities using parameterized payloads. Returns list of vulnerable parameters and injection points. Call after discovering API endpoints.'
• Add permission gates and scope declarations to security-critical tools. Document required scopes (e.g., 'read:filesystem', 'write:deployment') and implement server-side permission checks before execution.
• Document output schemas for all tools. Specify return type (object, array, string), field names, and types. Include pagination parameters (limit, offset, total_count) for list-returning tools.
• Implement error handling patterns: categorize errors as retryable/user-fixable/fatal, include the invalid value and constraint violated, and provide recovery guidance (e.g., 'User not found. Try search_users() first.').