Critical gaps across all dimensions. Tool definitions lack proper schemas, input parameters are documented in descriptions but not in formal JSON Schema with type constraints. Descriptions are minimal (10-50 chars), well below the 50-200 char baseline for LLM-optimized tools. No output schemas documented. Tool names lack action verbs (e.g., 'calc.health' instead of 'check_calc_health'). No error handling guidance, no parameter validation rules, no recovery paths. All 13 tools exhibit the same structural deficiencies. This server is not production-ready.

• Add formal JSON Schema to every tool input. Use type, enum, minLength, maxLength, pattern, and minimum/maximum constraints. Example: calc.export should declare format as enum: ['csv', 'pdf'] in schema, not just description.
• Expand tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'calc.health' → 'Check if the calculation module is operational and ready to process emissions jobs. Call this first to verify connectivity before running compute operations.'
• Rename tools to verb_noun convention. Replace 'calc.health' with 'check_calc_health', 'calc.db.get' with 'get_calc_records', 'calc.export' with 'export_calc_results'. This improves LLM parsing and intent inference.
• Document output schemas for every tool. Specify returned fields, types, and structure. Example: calc.compute should return {job_id: string, status: string, emissions_total: number, timestamp: ISO8601}.
• Add error handling guidance. For each tool, document: (1) what errors can occur, (2) whether they are retryable, (3) what the LLM should do next. Example: 'If job_id not found, call list_calc_jobs() to discover available IDs.'