marriott_mcp

Overview Schema Source Related Servers Discussions Admin

checkout

Verify booking details and prepare a checkout preview. Confirm with token after reviewing total and terms; handle special rate eligibility.

Instructions

Prepare a verified checkout preview for the selected offerId. Review total, terms and guest details with the user. Only after explicit user approval call again with the returned confirmationToken. A token-only call uses the saved parameters. Changed price/terms require new approval. Government offers require governmentEligibilityConfirmed; other special rates require specialRateEligibilityConfirmed. Never retry an unknown submission outcome.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "checkout"
  }
}

Input Schema

Name	Required	Description	Default
`email`	No
`phone`	No
`rooms`	No
`adults`	No
`checkIn`	No
`hotelId`	No
`offerId`	No
`checkOut`	No
`children`	No
`lastName`	No
`roomCode`	No
`firstName`	No
`specialRequests`	No
`confirmationToken`	No
`governmentEligibilityConfirmed`	No
`specialRateEligibilityConfirmed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 9, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the two-step nature, the requirement for explicit user approval, the effect of changed price/terms, and the eligibility confirmation conditions. It also warns against retrying unknown outcomes, which is a key behavioral constraint. It does not mention side effects like booking finalization, but the token flow implies that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact yet information-dense, front-loading the purpose and then logically sequencing the workflow, conditions, and a warning. Every sentence adds value, and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 16 parameters and no output schema. The description explains the two-step process and key flags, but it omits details on which parameters are needed in each call, error handling beyond unknown outcomes, and what the preview response contains. An agent might not know exactly what to supply for the first call without additional inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It explains confirmationToken, governmentEligibilityConfirmed, and specialRateEligibilityConfirmed, which are critical. However, it does not clarify the roles of the other 13 parameters (email, phone, dates, guest counts, etc.) beyond the general phrase 'guest details.' It does not indicate which are required for the first call versus the token-only call, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool prepares a checkout preview for a given offerId, which is a specific verb-resource pair. It distinguishes itself from siblings like select_room or add_extras by focusing on the checkout step, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit workflow guidance: call once to get a token, then call again with that token after user approval. It also specifies conditions for eligibility flags and warns against retrying unknown outcomes. However, it does not state when to prefer this over other booking tools or what precedes it in the flow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server