Skip to main content
Glama
Sign In
marriott_mcp

marriott_mcp

by YHRen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_room_options

Retrieve hotel room and rate offers grouped by selected special rate categories, including cancellation, deposit, and eligibility details. Defaults apply unless overridden; no rate is auto-selected.

Instructions

Return all matching room/rate offers grouped in rateResults for each selected specialRates category, with cancellation policy, deadline, deposit terms and eligibility. Defaults come from MCP environment config; government scope defaults to federal-only. No rate is automatically selected or ranked. Missing terms remain unknown. usePoints supports only regular award inventory. Review options with the user before choosing an offerId.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hotelId": "<hotelId>",
      "checkIn": "<checkIn>",
      "checkOut": "<checkOut>"
    },
    "name": "get_room_options"
  }
}

Input Schema

NameRequiredDescriptionDefault
roomsNo
adultsNo
checkInYes
hotelIdYes
checkOutYes
childrenNo
rateTypeNoDeprecated alias. Do not combine with specialRates.
usePointsNo
specialRatesNoCategories to search separately. Overrides MARRIOTT_SPECIAL_RATES. All matching offers and cancellation terms are returned; none is selected automatically.
corporateCodeNoRequired for corporate_promo, or set MARRIOTT_CORPORATE_CODE.
governmentScopeNofederal (default) excludes state-only and unverified government eligibility; all includes all verified government/military categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that no rate is auto-selected or ranked, that missing terms remain unknown, that usePoints supports only regular award inventory, and that government scope defaults to federal-only. It also instructs to review options with the user before choosing an offerId. This is comprehensive for a read-only tool.

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

Conciseness5/5

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

The description is compact yet information-dense, with the core function stated first and key caveats following. Every sentence adds value, and it avoids redundancy. It is appropriately sized for the tool's complexity.

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

Completeness4/5

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

Given 11 parameters, no output schema, and no annotations, the description covers the essential behaviors, defaults, limitations, and workflow. It could be more detailed on the structure of rateResults or how to interpret cancellation terms, but it gives enough to call the tool correctly. The missing details are not critical for invocation.

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

Parameters4/5

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

Schema description coverage is only 36%, so the description must compensate. It adds meaning to specialRates (categories to search separately), usePoints (regular award inventory only), governmentScope (defaults to federal-only), and corporateCode (implied for corporate_promo). It does not explain rooms, adults, children, dates, or hotelId, but those are self-explanatory and covered by schema patterns. Overall, it adds value beyond the schema.

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

Purpose5/5

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

The description clearly states the tool returns all matching room/rate offers grouped in rateResults for each selected specialRates category, including cancellation policy, deadline, deposit terms, and eligibility. It is specific about the resource (room/rate offers) and the action (returning them), and it distinguishes itself from sibling tools like select_room by explicitly noting that no rate is automatically selected or ranked.

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?

The description provides clear context on how to use the tool, including that defaults come from MCP environment config, government scope defaults to federal-only, and that review with the user before choosing an offerId is required. It does not explicitly name alternatives (e.g., select_room) or state when not to use it, but the guidance is strong enough to orient an agent.

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

Deploy Server

Other Tools