Five tools with clear, domain-specific descriptions (10-30x token efficiency, cost transparency). All tools have input schemas with URL parameters and descriptions. However, schemas are minimal (single required param per tool), output schemas are undocumented, and error handling lacks recovery guidance. Tool naming is verb-forward (read, shot, demo) but lacks specificity, 'read' vs 'read_js' distinction relies on description rather than name clarity. No parameter validation constraints (min/max for width), no pagination, no structured error responses. Descriptions are good (100-150 chars) but lack WHEN-to-use guidance and dependency hints.

• Document output schemas for all tools. E.g., read/read_js return {title, byline, markdown, token_estimate, chars, fetched_at, final_url}; shot returns {image_base64, width, height, fetched_at}. Include in tool descriptions or separate schema docs.
• Add min/max constraints to shot's width parameter in JSON Schema: {type: 'number', minimum: 320, maximum: 1920}. Remove from description; let schema enforce it.
• Rename read_js to read_rendered or read_spa to clarify when to use it vs read. Add to read description: 'Use read_static for static HTML pages. If content is sparse, try read_rendered for JavaScript-heavy SPAs.'
• Enhance error messages with recovery guidance. E.g., 'URL rejected: private IP 192.168.1.1. Only public HTTP(S) URLs allowed. Check the domain is publicly accessible.' Include error classification (retryable: false, user_fixable: true).
• Add cost-benefit guidance to descriptions. E.g., read_js: 'Use only if read returns <100 tokens, rendering costs 2.5x more.' Helps LLMs choose efficiently.