Server has 8 tools with basic descriptions and input schemas, but significant gaps in parameter documentation and output schema clarity. All tools are READ_ONLY (good for safety), but descriptions are terse (avg ~60 chars, well below the 194-char baseline). Parameter descriptions exist but lack detail on constraints, formats, and valid ranges. No output schemas documented. Tool names follow verb_noun convention (compile, validate, parse, simulate, query, inspect_ast, batch_compile, list_backends) but lack clarity on when to use similar tools (compile vs batch_compile distinction unclear). Error handling and recovery guidance absent.

• Document output schemas for all tools. Specify: compile returns {code: string, target: string, errors?: string[]}; validate returns {valid: boolean, errors?: string[], warnings?: string[]}; parse returns {ast: object}; query returns {results: object[]}. Include field types and descriptions.
• Add enum constraints to parameters. Change 'target' description to include enum: ['rust', 'c', 'cpp', 'go', 'python', 'ts', 'all']. Add format guidance to 'sql' parameter: 'SQL SELECT query (e.g., SELECT * FROM rules WHERE type = "state_machine")'.
• Clarify compile vs batch_compile in descriptions. compile: 'Compile .n2 source to a single target language. Use when you know the target upfront.' batch_compile: 'Compile .n2 source to all supported targets in one call. Use for multi-language deployment or testing.'
• Add error handling guidance. Document common failures: 'Parse errors indicate syntax violations, check .n2 grammar. Validation errors indicate contract violations, review rule definitions. Compilation errors indicate unsupported language features, check target backend docs.'
• Expand parameter descriptions with constraints and examples. 'source: .n2 source code (max 1MB, UTF-8 encoded, must start with contract or rule definition)'. 'sql: SQL query string (supports SELECT, WHERE, ORDER BY; e.g., SELECT * FROM rules WHERE type = "state_machine")'.