Single tool 'triage_url' has a clear, action-oriented name and reasonable description (127 chars). Input schema is properly defined with Zod validation (z.httpUrl()). However, output schema is undocumented, the tool returns JSON-serialized TriageResult but the structure is not visible in the MCP registration. Parameter description is adequate but generic. No error handling guidance, no recovery paths, and no documentation of what TriageResult fields mean or when to use each recommendation (USE_LLMS_TXT vs FETCH_RAW vs HEADLESS_REQUIRED). Tool is read-only and simple, but lacks the depth expected for production use.

• Document the TriageResult output schema explicitly in the tool description or as a structured response type. Include field names, types, and what each recommendation means: 'Returns {recommendation: string, reason?: string, headers?: object}. Recommendations: USE_LLMS_TXT (robots.txt or llms.txt found), FETCH_RAW (simple HTML, no JS), HEADLESS_REQUIRED (JS-heavy), WAF_BLOCKED (403/429), ERROR_UNREACHABLE (timeout/DNS).'
• Add error handling guidance to the description: 'On network timeout, returns ERROR_UNREACHABLE. On invalid URL format, returns error with constraint details. Retryable errors include timeouts; non-retryable include malformed URLs.'
• Expand parameter description: 'Absolute http(s) URL (max 2048 chars). Must start with http:// or https://. Relative URLs, data: URIs, and file: URIs are rejected with a validation error.'
• Add a 'When to use' section: 'Call this before fetching any URL to avoid WAF blocks, unnecessary headless rendering, or token waste on binary/non-text content. Recommended for all web-scraping agents.'
• Consider adding optional parameters for advanced use: timeout_ms (default 5000), follow_redirects (default true), or custom_headers (for auth). Document defaults and constraints.