Five tools with complete input schemas and descriptions, but significant gaps in output documentation and error handling. Tool names follow verb_noun pattern (docs.discover, docs.read, docs.search, docs.extract, docs.map) which is good. Descriptions are present (avg ~80 chars) but lack actionable context for LLM selection. No documented output schemas, pagination guidance, or error recovery paths. Parameters are typed and described, but lack constraints (enums, ranges, format specs). All tools are READ_ONLY, reducing risk, but composition and chaining support is unclear.

• Document output schemas for all tools. E.g., docs.discover returns {url: string, title: string, snippet: string, type: 'html'|'openapi'|'pdf'|'llms_txt', source: 'probe'|'search'}. Include this in the tool definition so LLMs can plan chaining.
• Add parameter constraints: docs.read max_length should declare min=100, max=100000. docs.extract method is already an enum (good); add enums or patterns to 'tag' and 'search' if they have known valid values.
• Integrate error guidance into tool definitions. Instead of inline error handling in code, declare error cases in the schema: 'Returns error NO_RESULTS if no docs found. Suggest: try docs.search with broader query.'
• Add pagination to docs.discover and docs.map. Include limit (default 20, max 100) and offset parameters. Return total_count so LLMs know if more results exist.
• Document tool dependencies in descriptions. E.g., docs.read: 'Requires a documentation URL. Use docs.discover to find URLs first.' This guides multi-step planning.