Server has two tools with good naming conventions and solid parameter documentation. generate_image has comprehensive schema with detailed parameter descriptions following verb_noun pattern. get_models is simpler but appropriately named. Both tools have clear descriptions in the 150-200 char range. However, output schemas lack formal documentation, responses are returned as text JSON and structuredContent without explicit schema definitions in the registration. Error handling is basic (input validation present but no recovery guidance). The schemas use Zod for validation but not declared in the tool registration's outputSchema field.

• Add explicit outputSchema objects to both tool registrations. For generate_image, document the image object structure (imageURL, imageUUID, cost fields). For get_models, document the returned model array structure with fields (name, airId, pricing, description, collection).
• Add Zod refinements to generate_image parameters: .refine(w => w % 64 === 0, 'width must be divisible by 64'), .min(1).max(100) for steps, .min(0).max(50) for cfgScale. Make numeric constraints machine-parseable, not just text descriptions.
• Enhance error messages with actionable recovery guidance. E.g., 'Image generation failed: {reason}. Try: 1) Reduce image dimensions, 2) Decrease steps count, 3) Check API quota with get_models tool.' or 'Prompt too long (X chars > 3000 max). Shorten description and try again.'
• Add optional parameters to get_models for filtering: collection ('popular'|'best'), sortBy ('price'|'name'), limit (default 20, max 100). Return paginated results with model count and next cursor to prevent massive unstructured responses.
• Add enum constraint to model parameter in generate_image. Pre-populate from popular_models.json and best_models.json, or document pattern (runware:XXX@Y, civitai:XXXXX@YYYYY) with validation logic.
• Add tool annotations: mark generate_image with destructiveHint=true (calls external API, incurs cost), mark get_models with readOnlyHint=true.