Server has 10 tools with mixed quality. Naming is generally verb-based (list_, find_, read_, generate_, get_, is_), which is good. However, descriptions vary widely in quality and completeness. Most tools lack structured output schema documentation. Parameter descriptions are present but often generic. No error handling guidance for recovery. Tools like generate_image have detailed parameter docs, but others like list_engineers have minimal descriptions. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Output schemas are not formally documented, LLMs must infer structure from descriptions.

• Add formal JSON Schema output documentation for all tools. Example: generate_image should document {'success': bool, 'files': [str], 'cost': float, 'error': str} with field descriptions.
• Implement tool annotations: mark generate_image with destructiveHint=true; mark all read-only tools with readOnlyHint=true; mark idempotent tools with idempotentHint=true.
• Expand list_engineers description from 'List all engineers' to 'Retrieve all engineers in the system. Returns array of engineer records with id, name, github_login, email, country_code, timezone. Use this to discover available engineers before filtering with get_engineer or list_open_issues.'
• Add recovery guidance to error responses. Example: generate_image error 'Missing IMG_API_KEY' should suggest 'Set IMG_API_KEY in .env or environment variables, then retry.'
• Document parameter constraints explicitly. For list_open_issues, clarify: 'priority and assignee_id are both optional filters; omit both to list all issues. If both provided, returns issues matching both criteria (AND logic).'