Single tool 'scrape_website' has a reasonable description (156 chars) and proper naming convention (verb_noun). Input schema is present with type definition for 'url' parameter, but lacks parameter-level description in the schema itself. Output is formatted text rather than structured JSON, limiting composability with downstream tools. No error handling guidance, no output schema documentation, and no tool annotations. The description is informative but could be more precise about what 'structured content blocks' means and what format the output takes.

• Add structured JSON output schema: {title: string, headings: {h1: [string], h2: [string], h3: [string]}, structured_blocks: [string], links: [{text: string, href: string}], body_text: string}. Document this in the tool description and/or return type comment.
• Add parameter description to input schema: {'url': {'type': 'string', 'description': 'Full HTTP/HTTPS URL to scrape. Must be publicly accessible. Examples: https://example.com, https://example.com/page. Max 2048 chars.'}}
• Implement error handling guidance: on timeout, return '{"status": "timeout", "error": "Request took >30s. The site may be slow or blocking scrapers. Try again in 60s or check if the URL is valid."}'. On 404, return '{"status": "not_found", "error": "URL returned 404. Check the link or try a different page."}'. On auth wall, return guidance to bypass or skip.
• Add readOnlyHint: true annotation to indicate the tool never modifies state, enabling safe caching and aggressive retries by clients.
• Reduce reliance on string formatting. Return structured JSON natively from scrape_website so LLMs can filter by heading level, select specific blocks, or extract just links without parsing text.
• Document expected response time and behavior: 'Typical: 3-8s. If site renders slowly (ads, tracking), may take up to 30s. Response includes first 8000 chars of body_text; for longer pages, use pagination or call multiple times for different sections.'