Server has 6 tools with basic schemas and descriptions, but significant gaps prevent production use. All tools have descriptions (10-50 chars, mostly under the 50-200 char LLM-optimized range), and input schemas are present with type definitions. However, output schemas are completely undocumented, LLMs cannot plan downstream calls or extract results. Parameter descriptions are minimal (e.g., 'Path to the TypeScript file to analyze' for filePath). No error handling guidance, no recovery paths, no actionable error messages. Tools lack composition hints (e.g., get_type_suggestions output doesn't document what fields are returned). No security considerations despite WRITE operations on the filesystem. Naming is clear (verb_noun pattern), but descriptions don't explain WHEN to use each tool or what distinguishes analyze_file from analyze_directory beyond scope.

• Document output schema for every tool. Example for analyze_file: 'Returns {anyCount: number, locations: [{line: number, column: number, context: string}], filePath: string}'. This enables LLMs to extract and chain results.
• Expand tool descriptions to 80-150 chars with WHEN/WHY guidance. Example: 'Analyze a single TypeScript file for unsafe any types. Use this for targeted inspection; use analyze_directory for bulk scans. Returns count and locations of any types found.'
• Add enum constraint to 'replacement' parameter: {type: 'string', enum: ['unknown', 'Record<string, unknown>', 'object']}. Prevents hallucinated values.
• Implement error handling with recovery hints. Catch file-not-found, permission-denied, and parse-error; return structured errors like {error: 'file_not_found', path: '...', suggestion: 'Check file path or permissions'}.
• Add dry-run parameter to fix_any_types and fix_directory (boolean, default false). When true, return proposed changes without writing. Enables safe preview before destructive operations.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry