Four tools with complete input schemas and basic descriptions, but significant gaps in parameter documentation and output schema specification. All tools are read-only web-scraping operations with no state-modifying risk. Naming is clear (screenshot, metadata, pdf, text) but descriptions lack depth on when to use each tool vs. alternatives. Parameter descriptions are minimal (e.g., 'URL to capture' for screenshot.url). No output schemas documented, LLMs cannot predict response structure. Error handling is generic (JSON error field). Missing guidance on pagination, rate limits, or result limits for text extraction.

• Document output schemas for all tools. E.g., metadata returns {og: {title, image, ...}, twitter: {...}, favicon: url}. screenshot/pdf return base64-encoded binary. text returns {content: string, length: number, truncated: boolean}.
• Expand parameter descriptions to 50-200 chars. E.g., 'url: The webpage URL to capture. Must be http:// or https://. Relative URLs not supported.' Include format constraints and common failure modes.
• Add error recovery guidance in tool descriptions. E.g., 'If the URL is unreachable, try a different domain or ask the user for a valid URL. Timeouts may indicate the site is slow, retry after 5 seconds.'
• Document result limits and truncation behavior. E.g., 'text tool returns up to 10,000 characters of readable content. If truncated, the response includes truncated: true. For longer content, call multiple times with different URL fragments or use pdf tool.'
• Add tool selection guidance in descriptions. E.g., screenshot: 'Use to capture visual layout, screenshots for UI inspection, or visual verification.' pdf: 'Use for archival, printing, or sharing formatted documents.' This helps LLMs choose the right tool.