Single tool 'query_papers' has a well-structured description (186 chars) explaining WHAT it does and WHEN to use it, meeting the 10-1024 char baseline. Input schema is present with two parameters: 'question' (string, described) and 'mode' (string with enum-like default, described). However, the output schema is completely undocumented, no return type, fields, or structure specified. This violates the critical rule that 'LLMs need to know what fields to expect so they can plan downstream tool calls.' The tool name 'query_papers' is clear and verb-noun compliant. Parameter descriptions are adequate but lack format constraints (e.g., question length limits, mode enum values not formally declared). No error handling guidance provided. Risk classification (READ_ONLY) is present but not integrated into the description.

• Add complete output schema documentation: specify return type (object/array), field names (e.g., papers[], answer, confidence, citations), types, and descriptions. Example: {papers: [{title, authors, year, relevance_score}], answer: string, source_count: int}
• Declare mode parameter as formal JSON Schema enum: {"type": "string", "enum": ["hybrid", "local", "global", "naive"], "default": "hybrid"}
• Add error handling guidance to description: 'If no papers match the question, returns empty results with explanation. If retrieval fails, returns error with retry guidance.'
• Specify question parameter constraints: minimum length (e.g., 10 chars), maximum length (e.g., 500 chars), and format (e.g., 'natural language research question')
• Extend description to explain output structure and next steps: 'Returns ranked papers with relevance scores. Use paper IDs for follow-up queries or citations.'