Four tools with complete input schemas and descriptions. Naming follows verb_noun pattern (read_*, diagnose_*, extract_*). Descriptions are adequate (50-100 chars) but lack actionable context for LLM selection. Parameters are typed and mostly described, but lack constraints (enums, ranges, patterns). Output schemas are not documented, LLMs cannot predict response structure. No error handling guidance. Missing parameter relationships (e.g., success_selectors interaction with timeout/max_attempts). Tool composition is sound (single responsibility), but batch variant (read_public_urls) lacks clear distinction from single-URL variant in descriptions.

• Document output schemas for all tools. Example: read_public_url returns {success: bool, content: str, status_code: int, error?: str, attempt_count: int}. LLMs need typed response structures to plan downstream calls.
• Add parameter constraints: timeout (int, 5 - 120, default 25), max_attempts (int, 1 - 20, default 8 - 12), max_content_chars (int, 1000 - 500000, default 60k - 120k). Use JSON Schema minimum/maximum fields.
• Expand tool descriptions to 100 - 150 chars with actionable context. Example: 'Read a single public URL with retry logic and CSS selector validation. Use for one-off fetches; use read_public_urls for batches to reuse host sessions.'
• Add error handling guidance in descriptions. Example: 'Returns {success: true, content: ...} on success. On failure, returns {success: false, error: "<reason>", status_code: <int>}. Retryable errors: timeout, 429, 503. Non-retryable: 404, 403, invalid URL.'
• Document success_selectors parameter behavior: 'CSS selectors to validate content retrieval. If provided, tool fails if none match. Useful to detect paywalls or access blocks. Leave empty to accept any response.'