mcptube presents 20 tools with generally clear names and solid descriptions. All tools have explicit descriptions (100-400 chars typically), and all parameters have type definitions and descriptions. However, output schemas are largely undocumented, the codebase shows return types in docstrings but no formal schema documentation that LLMs can parse. Tool names follow verb_noun patterns well (add_video, list_videos, wiki_search). Several tools are passthrough/analysis tools that delegate decision-making to the user ('Returns data for YOU to...'), which reduces the pattern alignment. Error handling is basic: VideoAlreadyExistsError and VideoNotFoundError are caught, but recovery guidance is minimal. Parameter defaults are reasonable (text_only=False, limit=10, page_type=None). Some tools like 'wiki_ask' and 'synthesize' have powerful multi-tool composition potential but lack detailed output schema documentation. The server follows a coherent domain model (Library → Wiki → Frame extraction → Analysis), and tool names clearly distinguish concerns (add_video vs list_videos vs get_info). However, passthrough tools (classify_video, generate_report, ask_video) blur the boundary between tool and UI logic, reducing clarity on what the tool guarantees vs. what the user must do.

• Document output schemas formally. For each tool, specify the return type with field names, types, and descriptions. E.g., 'Returns: { video_id: str, title: str, duration_seconds: int, transcript: str, frames: [{timestamp: float, url: str}], ...}'. This enables LLMs to plan chained calls and extract the right data.
• Refactor analysis tools. Instead of 'Returns data for YOU to write a report', make tools that return actionable data with a clear schema (e.g., 'generate_report returns { highlights: [str], transcripts: [str], key_frames: [{timestamp, summary}] }') so LLMs know what they can do with it.
• Add comprehensive error handling. Catch FrameExtractionError and other exceptions. Return typed errors: { error: 'not_found' | 'already_exists' | 'extraction_failed', message: str, recoveryHint: str }. E.g., 'video_id not found. Call list_videos() to see available IDs.'
• Support human-friendly video lookup. Add optional parameters: get_info(video_id: str | None = None, video_title: str | None = None). If title is provided, search for it and resolve to ID. Reduces discovery overhead.
• Add pagination to list_videos() and wiki_list(). Parameters: page: int = 1, limit: int = 20 (max 100). Return: { items: [...], total: int, page: int, has_more: bool }. This scales to large libraries.
• Document wiki_search result ordering and maximum. State whether results are ordered by relevance and whether a limit of 50 is hardcoded as a guard. Include total_results in response so LLMs know if there are more.