Single tool 'fetch' has a clear, descriptive name and good description (158 chars), but critical gaps in parameter documentation and output schema definition. Input schema is present with Zod types, but parameter descriptions are minimal. No documented output schema, error handling guidance, or recovery paths. The tool lacks pagination, result limits, and structured response documentation, key patterns for web-fetching tools that return variable-length content.

• Document the output schema explicitly: 'Returns {markdown: string, url: string, title: string, contentType: "negotiated"|"browser"}'. Include field descriptions so LLM knows what each contains.
• Rewrite 'force_browser' description: 'If true, skip HTTP content negotiation and render the page in a headless browser. Use this for JavaScript-heavy sites that fail with plain HTTP fetch. Default false attempts fast HTTP first.'
• Add error handling guidance: 'If fetch fails due to network timeout, retry with force_browser=true. If markdown is empty or under 50 chars, the page may be JavaScript-only or blocked. If URL is invalid, return a clear error with the invalid URL and expected format (http/https).'
• Cap markdown output at 50KB and document in description: 'Returns up to 50KB of cleaned markdown. For longer pages, content is truncated. Use multiple fetches with URL fragments or query params to retrieve sections.'
• Add URL parameter description: 'A valid HTTP or HTTPS URL. Redirects are followed automatically. Max 2048 characters. Invalid or unreachable URLs return an error with the reason (DNS failure, timeout, 404, etc.).'
• Consider adding optional 'max_length' parameter (default 50000) to let agents control truncation for memory-constrained scenarios.