Three tools with complete schemas and descriptions, but significant gaps in error handling, output documentation, and composition patterns. Tool names are clear (verb_noun style), descriptions are adequate (150-250 chars), and all parameters have types and descriptions. However, no documented output schemas, missing error recovery guidance, and the async polling pattern (harness_research → harness_status) lacks idempotency guarantees and retry semantics. No tool annotations (readOnlyHint/destructiveHint). harness_research is marked WRITE risk but lacks confirmation/dry-run pattern.

• Add explicit output schemas to all tools. harness_research should return {task_id: string, topic: string, estimated_duration_seconds: number}. harness_status should return {task_id: string, status: 'running'|'completed'|'failed', progress_percent?: number, output_files?: {html?: string, docx?: string, pdf?: string}, error?: string}. harness_search should return {results: [{title, url, source, snippet, published_date}], total_count: number}.
• Implement request deduplication for harness_research using a content hash of (topic, provider, model, formats). Return the existing task_id if an identical request is already running, preventing duplicate 8-12 minute jobs.
• Add tool annotations: mark harness_research with destructiveHint=true (creates files, runs expensive LLM calls), harness_search with readOnlyHint=true, harness_status with readOnlyHint=true.
• Enhance error messages with recovery guidance. E.g., 'Missing TAVILY_API_KEY and BRAVE_API_KEY. At least one search provider is required. Run: npx harness-research-mcp setup' instead of generic 'Missing API keys.'
• Return structured JSON from harness_search instead of formatted text. Clients can render results; LLMs can extract fields without parsing. Include result count and pagination (limit, offset) for large result sets.