Single tool 'explore_stays' has a well-structured schema with proper types, enums, and descriptions. Tool name uses verb_noun pattern (explore_stays). Description is clear and contextual (127 chars, within 10-1024 range). All parameters have type definitions and descriptions. However, output schema is not formally documented in the tool definition, only inferred from the ToolResult structured_content. Error handling is minimal (no recovery guidance for invalid city, missing stays, etc.). Tool annotations are present (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), which is good. The widget integration via Apps SDK meta is well-implemented but adds complexity. No pagination support despite potential for large result sets.

• Add formal output schema documentation to the tool definition. Document the structure of 'results' array (fields: id, name, city, rating, price_per_night, badges, amenities, summary) and 'selected' object. This enables LLMs to plan chained operations.
• Implement input validation with actionable error messages. E.g., if city is empty, return 'City cannot be empty. Available cities: New York, Los Angeles, Chicago, ...'. If min_rating < 0, return 'min_rating must be >= 0'.
• Add pagination: accept 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return 'total_count' and 'has_more' in response. Document in description: 'Results are limited to 20 per page. Use offset to paginate.'
• Clarify the 'selected_id' parameter. Either remove it (let the LLM filter results client-side) or document: 'If provided, returns only the matching stay in the selected field. Useful for fetching details after the user picks from a list.'
• Add error classification to responses. Return structured errors with 'error_code' (not_found, invalid_input, etc.) and 'recovery_hint' (e.g., 'Try a different city or remove the min_rating filter').