Server has 9 tools with basic descriptions and input schemas, but significant quality gaps. Tool names lack clear action verbs (e.g., 'targets', 'specs', 'skills' are nouns, not verb_noun patterns). Parameter descriptions are minimal or absent, most inputs have only type and brief label, no guidance on format, constraints, or when to use. Output schemas are not documented anywhere in the source. Error handling is absent from tool definitions. No evidence of pagination, result limits, or structured response guidance. The 'api/v1/search/autoupdate' tool is a WRITE operation but lacks confirmation/dry-run pattern. Overall, definitions are skeletal, sufficient to invoke but not optimized for LLM reasoning or error recovery.

• Rename tools to verb_noun pattern: 'targets' → 'list_targets', 'specs' → 'get_specs', 'skills' → 'list_skills'. This enables LLMs to infer intent from the name alone.
• Add parameter descriptions with format, constraints, and examples. E.g., 'source: AST JSON source code (max 1MB, must be valid JSON with kind and declarations fields)'. Include error cases.
• Document output schemas for all tools. Specify which fields are returned, their types, and which are required for downstream tool calls. E.g., compile returns {ok: bool, output: string, error?: string}.
• Add pagination to api/v1/search: accept limit (1-100, default 20) and offset/cursor parameters. Return total count and next_cursor. Document result limit in description.
• For api/v1/search/autoupdate, add dry-run parameter or confirmation step. Document side effects: 'Enables auto-update mode, subsequent search calls will return live results. This may increase latency. Call with enabled=false to disable.'
• Add enum constraints to 'target' parameter in compile and codegen/strategy. Instead of free-form string, list valid targets: ['go', 'rust', 'python', 'javascript', 'typescript', 'java', 'csharp'].