Critical failures across all dimensions. Tool definitions are inferred from file paths and names only, no explicit schema registration visible in provided source. No input parameter schemas, output schemas, or parameter descriptions found. Tool descriptions are minimal (10-40 chars), far below the 50-200 char baseline for LLM-optimized tools. No error handling guidance, no security annotations, no composition hints. The codebase shows package.json and dependency structure but does NOT expose the actual tool definitions, schemas, or MCP server implementation code needed for evaluation.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and what it returns. Example: 'Get a specific workload by ID. Use this after list_workloads() to retrieve full configuration details. Returns workload name, status, deployment region, and resource IDs needed for update_workload().'
• Document input schemas for all parameters. For get_workload, specify: workload_id (string, required, 'The unique workload identifier returned by list_workloads()'), include_details (boolean, optional, default false, 'If true, return full resource configuration; if false, return summary only').
• Document output schemas. For list_workloads, specify: returns array of {workload_id, name, status, region, created_at}; total_count (integer); next_cursor (string or null for pagination).
• Add error recovery hints to get_* and update_* tools. Example for get_workload: 'If workload not found, call list_workloads() to verify the ID. If still not found, the workload may have been deleted.'
• Mark destructive tools with explicit state-change warnings. For update_workload: 'WARNING: This modifies the workload configuration. Changes are immediate and may affect running deployments. Consider calling terraform_plan_check() first to preview changes.'