Two tools with strong, detailed descriptions (194 - 250 chars each) and comprehensive parameter documentation. Both tools have complete input schemas with types and descriptions. Tool naming is clear and verb-based (watch, get_frames). However, output schemas are documented only in docstrings, not as formal JSON Schema. Error handling guidance is present but could be more structured (e.g., explicit recovery steps for common failures). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite both being read-only operations.

• Add formal JSON Schema output definitions to both tools. For watch(), document the structure: {video_id: string, duration: string, events: [{timestamp: string, type: string, description: string}], cost: {usd: number, prompt_tokens: number, completion_tokens: number, model: string, calls: number} | null}. For get_frames(), return {frames: [{timestamp: string, jpeg: string (base64)}]} instead of a mixed list.
• Declare mode parameter as an enum in the schema: enum=['sample', 'manual', 'full']. Remove runtime ValueError and let the schema enforce validity.
• Add readOnlyHint: true to both tool definitions in FastMCP to signal that these tools do not modify state and are safe to cache/retry.
• Expand error handling documentation. Document failure modes: 'If video_path is invalid or unsupported, the tool returns an error with the reason (e.g., "Private video", "Unsupported host"). If timeout is exceeded, the tool returns a TimeoutError with the current progress percentage and stage name, use this to narrow the clip with start/end or increase timeout.'
• Add parameter constraints to schema. For timeout, specify minimum: 0 and note that 0 disables the timeout. For max_frames, specify minimum: 1, maximum: 100 (or the server's hard cap). For start/end, document the MM:SS format with a regex pattern or example.