gptqueue defines 6 tools with clear action verbs and reasonable descriptions (avg 150 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Parameter descriptions are adequate but lack format constraints (e.g., timeout range, message type enum values). Error handling is minimal; tools do not guide recovery. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (WRITE, DESTRUCTIVE). Composition is sound, tools chain well (register → send/receive → list/status). Security concern: no visible validation of agent names or message content against injection.

• Document output schemas for all tools. For list_agents, specify: {agents: [{name: string, description: string, role: enum, status: 'online'|'offline'}]}. For receive_message: {message: {id: string, from: string, content: string, type: enum, timestamp: ISO8601}, timeout: boolean}.
• Add tool annotations: register_agent and unregister_agent need destructiveHint=true; send_message needs idempotentHint=false (retries with backoff can cause duplicates); list_agents and get_queue_status need readOnlyHint=true.
• Constrain timeout parameter: add minimum=0.1, maximum=300 to receive_message timeout. Add pattern validation to agent names (alphanumeric + underscore, 1-64 chars) in register_agent description.
• Implement error recovery guidance. When send_message fails with 'Agent not found', return: {error: 'Agent "xyz" not found. Call list_agents() to discover available agents.'}. When receive_message times out, return: {timeout: true, message: null, hint: 'No messages in queue. Check get_queue_status() or wait for send_message() calls.'}.
• Add input validation in tool handlers. Sanitize agent names against Redis key injection. Validate message content length (e.g., max 64KB). Validate in_reply_to is a valid UUID format. Return actionable errors: 'Invalid agent name: must be 1-64 alphanumeric characters.'