Two tools with clear, documented schemas and good naming. However, output schemas are not formally documented, error handling could be more granular, and parameter descriptions lack depth on constraints and usage patterns. Baseline comparison: tool descriptions average 194 chars (rubric p50); both tools here are 130-180 chars, which is acceptable. Param annotation baseline is 72 chars; these average ~50 chars. Schema completeness is good (all params have types and descriptions), but return types are undocumented.

• Document return types explicitly: 'web_parse returns { success: boolean, url: string, selector: string, method: string, data: Record<string, unknown>, format: string }' and 'discover returns { success: boolean, url: string, selectors: string[], sample: Record<string, string> }'.
• Enhance 'attribute' parameter description: 'HTML attribute name to extract (e.g., href, src, data-id). Only used when method="attribute". Will return empty if attribute does not exist on selected elements.'
• Add recovery guidance to error responses. When WebParseLiteError occurs, suggest: 'Could not parse URL. Verify URL is accessible and not rate-limited. Try discover() first to inspect page structure.' or 'Invalid CSS selector. Run discover() to see valid selectors for this page.'
• Clarify when to use each tool in descriptions. web_parse: 'Extract specific data from a web page. Call discover() first to identify valid CSS selectors.' discover: 'Analyze page structure and identify common CSS selectors. Call this first to plan web_parse() calls.'
• Add constraint documentation to discover: 'Returns up to 20 most common CSS selectors and sample text. Use web_parse() to extract data at scale.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry