Skip to main content
Glama
FortripEngineering

Fortrip

Official
by FortripEngineering
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create booking payment link

create_booking
Idempotent

Creates or resumes a hotel booking from a chosen rate, collecting guest and contact details to return the amount, terms, and private payment link for user confirmation.

Instructions

Create or resume a booking for a user-selected rate from get_rates. Provide guests and contact details. Returns amount, currency, accepted terms and a private paymentUrl. Show terms and ask for confirmation before sharing paymentUrl exactly. Nothing is charged until the user pays on Fortrip/Stripe. Same user and stay resumes the same order; paid stays return 409. Does not cancel or modify bookings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roomsYes
adultsYesAdults per room
guestsYesAt least one guest per room; Latin letters as on passport; roomNo is 1-based
roomIdYesroomId from get_rates
checkInYesCalendar date in YYYY-MM-DD format; checkOut must be 1–15 nights after checkIn.
hotelIdYes
checkOutYesCalendar date in YYYY-MM-DD format; checkOut must be 1–15 nights after checkIn.
contactNameYes
childrenAgesNoAge in years of each child, 0–17; omit or use [] when no children are travelling.
contactEmailNo
contactPhoneYes
ratePlanCodeYesratePlanCode from get_rates
specialRequestsNoEnglish only; not guaranteed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / checkIn / description
      Added value: +"Calendar date in YYYY-MM-DD format; checkOut must be 1–15 nights after checkIn."
    • addedInput schema / properties / checkOut / description
      Added value: +"Calendar date in YYYY-MM-DD format; checkOut must be 1–15 nights after checkIn."
    • addedInput schema / properties / childrenAges / description
      Added value: +"Age in years of each child, 0–17; omit or use [] when no children are travelling."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial behavioral context beyond the annotations: return payload (amount, currency, accepted terms, private paymentUrl), the no-charge-until-payment guarantee, idempotent resume semantics keyed on same user and stay, and the 409 on paid stays. Annotations cover the safety profile (idempotentHint, destructiveHint=false) and the description layers on the operational details an agent needs at call time.

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?

Front-loaded with purpose, then packed with distinct behavioral facts, each sentence carrying its own weight. No filler, though the run-on delivery could be tightened slightly.

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 a 13-param mutation with no output schema, the description proactively discloses the return shape and the key failure/idempotency behavior. Parameter-level detail remains thin in places, but nothing critical for correct invocation is missing.

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 description coverage is 62%, and the description adds only a thin layer ('Provide guests and contact details') over parameters the schema already documents, such as ratePlanCode, roomId, checkIn/checkOut and the guests array. It does not clarify the remaining undocumented params (hotelId, contactName, contactPhone, rooms, adults) beyond what the schema structure implies.

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?

States a specific verb+resource ('Create or resume a booking') and ties it to the sibling that produces its inputs ('from get_rates'). The closing 'Does not cancel or modify bookings' explicitly fences it off from update/cancel operations, so an agent can distinguish it from siblings without opening a schema.

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?

Establishes the prerequisite chain clearly (rate comes from get_rates) and gives procedural guidance ('Show terms and ask for confirmation before sharing paymentUrl'). It does not name a competing alternative tool for the cancel/modify case, so routing guidance is inferred rather than enumerated.

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