Server has 9 tools with consistent naming (verb_noun pattern: run_workflow, update_library, scrape_metadata, etc.) and explicit Zod schemas. All tools have descriptions (avg ~120 chars, within baseline 34-392 range). However, critical gaps exist: (1) No output schemas documented, LLMs cannot predict return structure for chaining; (2) Parameter descriptions lack actionable constraints (e.g., 'scope' enum values not explained in descriptions, only in schema); (3) No error handling guidance, tools return fire-and-forget responses with no recovery hints; (4) Missing idempotency/confirmation patterns for destructive operations (rename, scrape, download all modify state); (5) Paths parameter marked optional but required when scope='path', undocumented dependency. Tools follow basic structure but lack production-grade polish for agent reasoning.

• Add structured output schemas to all tools. Return objects with fields like {status: 'queued'|'error', job_id: string, message: string, affected_count?: number} instead of plain strings. This enables chaining and progress tracking.
• Document parameter dependencies explicitly: 'paths: required when scope is "path", optional otherwise. Provide at least one path when using path-scoped operations.'
• Implement error handling that returns {error: string, code: string, recovery_hint: string}. E.g., 'Invalid scraper ID. Available: tmdb, tvdb, imdb. Try scrape_metadata with scraper="tmdb".'
• Add dry-run or confirmation support for destructive tools (rename_media, scrape_metadata). Return a preview of changes and require explicit confirmation before applying.
• Expand scope descriptions in parameter docs: 'all: scan all configured sources; new: only items added since last scan; unscraped: items without metadata; path: specific file/directory paths; dataSource: specific data source name.'