Two tools with basic schemas and descriptions, but significant gaps in parameter documentation, error handling guidance, and output schema clarity. stripe-detector has a minimal 1-param schema; stripe-filter accepts complex nested objects but lacks per-item error handling. Neither tool description explains when to use one vs. the other, what the confidence/details fields contain, or how to interpret results. No error recovery guidance. Descriptions are adequate length (60 - 90 chars) but lack actionable context for LLM selection.

• Add explicit output schema documentation to both tools. Example for stripe-detector: 'Returns {stripe_enabled: boolean, confidence: 0-100 integer, details: {payment_methods: [string], checkout_url?: string}, error?: string}'.
• Enhance parameter descriptions with format and validation rules. For 'url': 'A publicly accessible HTTP(S) URL (max 2048 chars). Must resolve within 10 seconds.' For 'products': 'Array of 1 - 100 products, each with required url and optional name.'
• Add error recovery guidance. Example: 'If error contains "timeout", the URL may be slow or unreachable, try again or check the domain. If error contains "invalid_url", verify the URL is valid HTTP(S).'
• Document the confidence score range and interpretation. Example: 'confidence: 0 - 100 integer. 90+ = Stripe detected with high certainty. 50 - 89 = Possible Stripe integration (may be third-party payment processor). <50 = No Stripe detected.'
• Add a tool selection guide in descriptions. Example for stripe-detector: 'Use this to check a single product URL. For bulk checking, use stripe-filter.' For stripe-filter: 'Use this to filter a list of products. For detailed analysis of a single product, use stripe-detector.'