Framesleuth has 8 tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (analyze_video, get_report, list_reports). Descriptions range from 80 - 180 chars, meeting the 10 - 1024 baseline. However, parameter descriptions are sparse or missing context. Output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is absent from descriptions. The analyze_video tool lacks guidance on prerequisites (repo_root requirement). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Document output schemas for all tools. For get_report, specify: {job_id: string, classification: string, evidence: [...], code_candidates: [...], timestamp: ISO8601}. For list_reports, specify: {reports: [{job_id, created_at, status}], total: int}.
• Add tool annotations via FastMCP. Mark analyze_video, get_video_gif, render_html_video with destructiveHint=true. Mark all READ_ONLY tools with readOnlyHint=true. This enables agents to reason about side effects.
• Enhance parameter descriptions with constraints. E.g., 'max_frames: integer, 1 - 500 (default 30). Higher values increase GIF size and encoding time.' For relative_file: 'Relative path within report directory, no parent traversal (..) allowed.'
• Add error recovery guidance. E.g., analyze_video: 'If analysis fails, check that repo_root is a valid git repository and video is readable. Call list_reports to see prior successful analyses.'
• Document tool dependencies and sequencing. E.g., 'Call list_reports first to discover available job_ids. Then call get_report(job_id) to retrieve full analysis. Call suggest_actions(job_id) to see recommended next steps.'