Marriott MCP has 19 tools with explicit schemas and descriptions. Naming is verb-prefixed (marriott_*) and action-oriented. Most tools have 50-150 char descriptions, which is acceptable but could be more LLM-optimized. Input schemas are present for all tools with type definitions and property descriptions. However, several critical gaps: (1) output schemas are NOT documented, LLMs cannot predict response structure; (2) error handling lacks recovery guidance (e.g., 'sold_out' mentioned in instructions but not in tool responses); (3) destructive tools (marriott_reservation_*) lack explicit confirmation/dry-run patterns despite elicitation support; (4) parameter descriptions are sometimes vague (e.g., 'user_said' in marriott_book lacks format guidance); (5) no pagination guidance for tools returning lists (marriott_activity, marriott_stays). Tool composition is reasonable, each tool has one clear responsibility. Naming conventions are consistent (marriott_<action>). Security: passwords accepted as parameters in marriott_login (though env var alternative provided), which is a moderate risk.

• Document output schemas for all tools. At minimum, specify the top-level response structure (e.g., {signed_in: boolean, url: string, title: string, member_name: string} for marriott_status). Use JSON Schema format in tool definitions.
• Formalize the confirmation pattern for destructive tools. Define what confirm_token should contain, what the dry-run response looks like, and how the LLM should interpret user_confirmed. Consider a separate 'confirm_reservation' tool that returns a confirmation summary before execution.
• Clarify marriott_book parameters. Define the state machine: what values are valid for user_said? What does option_id reference? When is quote_id required vs optional? Add an enum or state diagram in the description.
• Enforce password injection via environment variables only. Remove the password parameter from marriott_login or mark it as deprecated. Document that MARRIOTT_EMAIL and MARRIOTT_PASSWORD must be set server-side.
• Add explicit pagination guidance. For marriott_activity and marriott_stays, document: 'Returns up to page_size results (default 20, max 100). Use property_contains to filter. If more results exist, call again with updated page_size or offset.' Return a next_cursor or has_more flag.