Single tool with minimal schema and weak description. The generate_text tool has a basic description (64 chars) that lacks actionable context for LLM tool selection. Input schema is minimal, only a 'prompt' parameter with a generic string type and no constraints, enums, format guidance, or validation rules. No output schema is documented, forcing LLMs to infer what fields to expect from the response (only a job_id is returned, but this is not formally declared). Error handling is absent, no guidance on retryability, failure modes, or recovery paths. The tool modifies state (enqueues jobs) but the description does not explicitly state this. Parameter descriptions are too generic. No resource descriptions visible in the provided code. The server exposes a 'job://{job_id}' resource but the get_job_status function lacks a formal schema definition for JobStatusResponse, we can infer it has 'status' and 'result' fields from the import, but the actual schema structure is not visible in the source code provided.

• Expand generate_text description to 80-150 chars: 'Enqueues an AI text generation job asynchronously and returns a job_id for status polling. Use this to generate text without blocking. Supports prompts up to 4096 characters.'
• Add input constraints: minimum 1 char, maximum 4096 chars for prompt parameter. Add to description: 'prompt: The input text (1-4096 characters). Longer prompts may take more time to process.'
• Document output schema explicitly in tool definition or description: 'Returns {job_id: string, queued_at: ISO-8601 timestamp, estimated_wait_seconds: number}' (or actual fields).
• Add error handling section to description or separate documentation: 'Errors: Redis unavailable (retryable), queue full (retryable), invalid prompt (user-fixable). If enqueue fails, retry after 5 seconds or contact admin.'
• Define and document JobStatusResponse schema with field descriptions: status (enum: queued|processing|completed|failed), result (string or null), error_message (string or null).
• Add resource description to get_job_status explaining when job results are available and what each status means: 'Retrieves the status and result of an enqueued job. Initially returns queued, then processing, then completed with result text or failed with error.'

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

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