ATA Travel

create_provisional_booking

Secure a reservation or create a host-approval enquiry on behalf of a traveler. policyAcknowledged is required as an explicit boolean and must be true for financially binding flows after the exact total, payment schedule, and cancellation terms are shown; identity verification is not consent. A host-approval enquiry may pass false because payment is not due unless accepted. Also requires guest name/email plus travelerAssertion or approved internal BOOKING_HOLD agentHandoffId. If verification is needed, keep internal tool details private; tell the traveler only to confirm their email, check their inbox, and click the secure ATA link. If instant book is enabled and payment is ready, creates an inventory-holding provisional booking and returns payment/manual-payment next steps. If instant book is disabled or Stripe checkout is not ready, creates an enquiry hold for host approval/payment follow-up.

Input Schema

TableJSON Schema

Name	Required	Description
`notes`	No	Optional traveler comments, questions, or requests for the host. Especially useful for host-approval enquiries.
`adults`	Yes
`roomId`	Yes
`checkIn`	Yes
`checkOut`	Yes
`children`	No
`guestName`	Yes
`guestEmail`	Yes
`guestPhone`	No
`ratePlanId`	No	Rate plan ID. If omitted, the system auto-selects the default active rate plan per night, then the cheapest active auto-selectable fallback.
`priceAudience`	No
`propertyToken`	Yes
`agentHandoffId`	No	Approved ATA traveler handoff ID from start_traveler_handoff/get_traveler_handoff_status. Required for third-party agents before inventory-holding booking actions.
`displayCurrency`	No	Optional 3-letter currency for approximate traveler-facing display conversion. Native property currency remains authoritative.
`internalAgentKey`	No
`selectedRoomCount`	No	For direct-booking room-count configurations, the number of rooms the traveler selected. Use defaultSelectedRoomCount from availability results.
`travelerAssertion`	No	Signed traveler email verification assertion from ATA.
`policyAcknowledged`	Yes	Explicit policy-consent state. Set true only after the traveler agrees to the exact price, payment schedule, and cancellation terms. Required before creating either an instant-book hold or a host-approval enquiry.

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only signal non-read-only, non-idempotent behavior. The description adds substantial behavioral context beyond that: identity verification is not consent, internal tool details must be kept private, the traveler should only be directed to confirm email/inbox/secure ATA link, and the tool either creates an inventory-holding provisional booking or an enquiry hold. This is exactly the kind of context an agent needs and does not contradict the annotations.

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 dense but front-loaded with the core purpose, and every sentence contributes a real prerequisite or behavioral nuance. It is one long paragraph with multiple conditionals, which could be restructured into bullets, but the length is justified by the complexity of the tool.

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?

For an 18-parameter mutating tool with no output schema, the description covers the main decision branches, consent requirements, privacy constraints, and what type of result to expect in each branch. It does not explain every required parameter or provide a return shape, but it gives an agent enough operational context to invoke the tool correctly in the primary flows.

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 only 39%, so the description carries extra responsibility. It adds strong semantics for policyAcknowledged, travelerAssertion/agentHandoffId, and guest name/email requirements. However, several required and behaviorally important parameters such as propertyToken, roomId, checkIn, checkOut, and adults are not explained in the description and rely on self-evident schema naming, so the description only partially compensates for the low schema coverage.

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 opens with a concrete, specific action: 'Secure a reservation or create a host-approval enquiry on behalf of a traveler.' It clearly distinguishes the two possible outcomes based on instant-book availability, making the tool's purpose unambiguous and separable from list/search/quote siblings.

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 gives explicit decision context: when instant book is enabled and payment is ready, versus when instant book is disabled or Stripe checkout is not ready. It also specifies when policyAcknowledged may be false (host-approval enquiry) and names the required authentication prerequisites. It does not explicitly mention alternative sibling tools or list 'when not to use,' but the situational guidance is clear and actionable.

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

All ATA Travel tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation3/5

Multiple search tools (search_buildings, search_property_catalog, search_network_availability) and detail tools (get_building_details, get_property_details, get_stays_in_building) have overlapping boundaries, though descriptions clarify date and availability distinctions. The verification/handoff tools are more clearly separated but still numerous.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (create_*, get_*, search_*, start_*, verify_*). There are no mixed casing conventions or vague generic verbs, making the set predictable and easy to scan.

Tool Count3/5

With 22 tools, the server is on the heavy end of a typical MCP scope, though each tool has a defined purpose. Several narrow status and discovery helpers inflate the count, but the overall count is not yet extreme.

Completeness2/5

The booking lifecycle is incomplete: create_quote and create_provisional_booking exist, but there is no cancel, update, or explicit payment action, and get_reservation_status explicitly cannot change or cancel a reservation. Search and verification are well covered, but missing booking mutations will cause agent dead ends.

Resources

Need Help?