Skip to main content
Glama

Exact stay price

ot_price_quote
Read-onlyIdempotent

Calculate the exact price in Toman for an Otaghak room stay given dates and guests, including extra-guest and late checkout fees, and verify nightly availability and stay limits.

Instructions

Get the amount to pay (Toman) for a room, dates and guests: nights_total (the room page's payable amount for the base guests), the extra-guest charge, optional late checkout, and the total. nightly is the calendar breakdown (each discounted night is rounded to 1,000, so it can add up to a little more than nights_total; price_before_discount is absent when there is no discount).

Also checks that every night is free, the stay length is allowed and the room takes that many guests (available=false with a reason otherwise). Late checkout that cannot be booked keeps the quote, with late_checkout.available=false. Use before the user books on otaghak.com.

Input Schema

NameRequiredDescriptionDefault
guestsYesGuests, e.g. 4.
room_idYesRoom id (code), e.g. 2512254.
check_inYesArrival day YYYY-MM-DD, e.g. '2026-10-20'.
check_outYesDeparture day, e.g. '2026-10-23' (max 20 nights).
late_checkout_hoursNoLate checkout hours to add (offered rooms), e.g. 4.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.2.0
    • changedInput schema / properties / check_in / description
      Previous value: -"Arrival day, Gregorian YYYY-MM-DD, e.g. '2026-10-20'."New value: +"Arrival day YYYY-MM-DD, e.g. '2026-10-20'."
    • removedInput schema / properties / check_in / title
      Removed value: -"Check In"
    • changedInput schema / properties / check_out / description
      Previous value: -"Departure day, e.g. '2026-10-23'. At most 20 nights."New value: +"Departure day, e.g. '2026-10-23' (max 20 nights)."
    • removedInput schema / properties / check_out / title
      Removed value: -"Check Out"
    • changedInput schema / properties / guests / description
      Previous value: -"Number of guests, e.g. 4."New value: +"Guests, e.g. 4."
    • removedInput schema / properties / guests / title
      Removed value: -"Guests"
    • changedInput schema / properties / late_checkout_hours / description
      Previous value: -"Late checkout hours to add (offered rooms only, usually 4), e.g. 4."New value: +"Late checkout hours to add (offered rooms), e.g. 4."
    • removedInput schema / properties / late_checkout_hours / title
      Removed value: -"Late Checkout Hours"
    • removedInput schema / properties / room_id / title
      Removed value: -"Room Id"
    • removedInput schema / title
      Removed value: -"ot_price_quoteArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "ot_price_quoteDictOutput",
      -  "type": "object"
      -}New value: +null
  2. 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 annotations already covering readOnly/idempotent/non-destructive, the description adds substantial behavior: nightly rounding to 1,000, price_before_discount omitted when no discount, available=false plus reason on failed checks, and a partial-success path where unbookable late checkout keeps the quote with late_checkout.available=false.

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-loads the payoff (what amount is returned and its parts) then covers edge cases; every sentence carries information. It is dense with parentheticals and slightly long, keeping it just shy of a 5.

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

Completeness5/5

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

No output schema exists, so the description must explain return values, and it does so thoroughly (field names, rounding behavior, absent fields, failure shapes). For a 5-parameter quote tool this is complete enough to invoke correctly.

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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: nights_total is for the base guests, and late_checkout_hours is treated as optional and may silently return available=false. It does not add format or boundary detail 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?

States a specific verb+resource: 'Get the amount to pay (Toman) for a room, dates and guests', and enumerates the returned components (nights_total, extra-guest charge, late checkout, total). Its combined pricing-plus-availability scope functionally distinguishes it from siblings like ot_room_calendar and ot_search_rooms.

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?

Gives a clear usage trigger: 'Use before the user books on otaghak.com', establishing it as a pre-booking validation/quote step. It does not, however, name alternatives (e.g. why not ot_room or ot_search_rooms) or state when-not to use it.

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