Marriott MCP has well-structured tool definitions with complete input schemas and reasonable descriptions. All 6 tools have descriptions (10 - 200 chars) and typed parameters with enums where appropriate. However, output schemas are not documented, LLMs cannot predict what fields to expect from responses. Parameter descriptions are functional but generic; many lack format hints, constraints, or dependency documentation. Error handling is absent from tool definitions. Tool composition is reasonable (search_hotels, plan_stay, scan_dates are distinct), but no guidance on chaining or required follow-up calls.

• Document output schemas for all tools. E.g., search_hotels should specify: returns array of {hotel_id, name, brand, price_per_night, amenities, distance_km, rating}. This enables LLMs to chain calls and extract the right fields.
• Add format and range constraints to date parameters. E.g., 'checkInDate: YYYY-MM-DD format, must be today or later. Defaults to today + 30 days if omitted.'
• Clarify when to use get_operations/call_operation vs. domain tools. Add a note: 'Use search_hotels for typical hotel searches. Use call_operation only if you need a custom GraphQL query not covered by the domain tools.'
• Add error recovery hints to tool descriptions. E.g., 'If no hotels found, try expanding radiusKm or relaxing amenity filters. If dates are invalid, check that checkInDate < checkOutDate.'
• Document parameter dependencies. E.g., 'nights and checkOutDate are mutually exclusive; if both provided, nights takes precedence.' or 'corporateCode requires a valid Marriott corporate account; omit if unknown.'