Skip to main content
Glama
Sign In
otaghak-mcp

otaghak-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Similar rooms

ot_similar_rooms
Read-onlyIdempotent

Find alternative rooms in the same city and type when a room is full or too expensive, repriced for your dates and guest count.

Instructions

Get 4-5 alternatives to a room (same city and type), as the room page shows them (or, while that list is empty upstream, a search of the room's city and type up to 1.5x its price; note says so).

Without dates prices are undated starting prices (not tonight's). With check_in/check_out the rooms are re-priced for that stay; rooms that are booked or too small for guests are listed in not_available. Use when the user's room is full or too expensive. Next: ot_room, ot_price_quote.

Input Schema

NameRequiredDescriptionDefault
guestsNoGuests, e.g. 4; smaller rooms are left out.
room_idYesRoom id (code), e.g. 2512254.
check_inNoArrival day YYYY-MM-DD, e.g. '2026-10-20' (not past, in the open calendar).
check_outNoDeparture day YYYY-MM-DD, e.g. '2026-10-23' (max 20 nights).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.2.0
    • changedInput schema / properties / check_in / description
      Previous value: -"Arrival day, Gregorian YYYY-MM-DD, e.g. '2026-10-20'. Not in the past; calendars open only to the end of next Jalali month."New value: +"Arrival day YYYY-MM-DD, e.g. '2026-10-20' (not past, in the open calendar)."
    • removedInput schema / properties / check_in / title
      Removed value: -"Check In"
    • changedInput schema / properties / check_out / description
      Previous value: -"Departure day, Gregorian YYYY-MM-DD, e.g. '2026-10-23' (3 nights). At most 20 nights after check_in."New value: +"Departure day YYYY-MM-DD, 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. Rooms that cannot take that many are left out."New value: +"Guests, e.g. 4; smaller rooms are left out."
    • removedInput schema / properties / guests / title
      Removed value: -"Guests"
    • removedInput schema / properties / room_id / title
      Removed value: -"Room Id"
    • removedInput schema / title
      Removed value: -"ot_similar_roomsArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "ot_similar_roomsDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Adds behavior well beyond the annotations: the upstream-empty fallback (search up to 1.5x price, flagged in `note`), the pricing semantics (undated starting prices without dates, re-priced with dates), and the not_available handling for booked/too-small rooms. Annotations only cover the safety profile, so this is genuinely additive.

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 the core purpose and scoped follow-ups (pricing, availability, usage) in a tight four-sentence block. The first sentence's nested parenthetical is slightly dense but not wasteful.

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?

With no output schema, the description carries the return-format burden and does name key fields (not_available, `note`). The structure of the primary alternatives list itself is left implicit, a minor gap for a no-output-schema tool.

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 baseline is 3, but the description adds real semantics: `guests` determines which rooms land in not_available rather than merely filtering, and check_in/check_out change pricing versus the undated starting prices. It doesn't clarify date-range limits beyond what the schema already says.

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 and resource: 'Get 4-5 alternatives to a room (same city and type)', plus the fallback scope while the upstream list is empty. An agent can distinguish this anchored-to-a-room lookup from the broader ot_search_rooms from the text alone.

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 trigger ('Use when the user's room is full or too expensive') and names follow-on tools ('Next: ot_room, ot_price_quote'). It stops short of an explicit when-not or a contrast against ot_search_rooms, so it falls just below the top band.

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