Scout MCP has 8 well-named tools with complete input schemas and descriptions. All tools follow verb_noun naming (scout_search, scout_scrape, etc.) and descriptions are concise (50 - 150 chars). However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are minimal (e.g., 'The search query' lacks guidance on length, format, or examples). No error handling guidance is visible; handlers return JSON via ok() but do not document failure modes or recovery paths. Tool composition is sound (each does one thing), but missing output documentation and error patterns prevent higher scores.

• Document output schemas for all 8 tools. Include field names, types, and nesting. Example: scout_search returns {results: [{title, url, snippet, rank}], total_count, next_cursor}. This enables LLMs to extract IDs and chain tools.
• Expand parameter descriptions to 50 - 150 chars with constraints and guidance. E.g., 'Search query (1 - 500 chars). Use depth="deep" for multi-step agentic searches (slower, more thorough); default "standard" for quick results.'
• Add error handling guidance to tool descriptions. E.g., 'If the URL is invalid or unreachable, returns {error: "..."}. Retry with a different URL or use scout_search to find a valid page.'
• For scout_search, clarify depth trade-offs: 'shallow: fast, 5 - 10 results; standard: balanced, 10 - 20 results; deep: agentic, multi-step, 20+ results, slower, higher cost.'
• For scout_extract and scout_answer, specify URL limits (e.g., max 10 URLs), objective/question format (plain language, 10 - 500 chars), and expected output structure (JSON object with extracted fields or answer text).