Skip to main content
Glama
sepehr071

otaghak-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Room details

ot_room
Read-onlyIdempotent

Retrieve a single room's details—capacity, beds, amenities, house rules, check-in/out times, cancellation policy, host, location, photos, and nightly price—with optional dates for average pricing.

Instructions

Get one room: description, capacity, rooms and beds, amenities, house rules, check-in/out times, cancellation policy, host, nearby places, approximate location, photos and nightly price.

With check_in/check_out the price is the average night for those dates, even when they are booked (ot_price_quote or ot_room_calendar tells whether they are free); without, an undated starting price. instant_on_some_nights is the room-level flag: instant booking can differ per night, so for given dates read instant in ot_price_quote or ot_room_calendar. Use after ot_search_rooms or ot_find_place. Next: ot_price_quote (exact total), ot_room_calendar (free nights), ot_reviews, ot_host (host response and acceptance rates), ot_similar_rooms.

Input Schema

NameRequiredDescriptionDefault
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).
full_textNoReturn long texts in full instead of clipped.
max_photosNoPhoto URLs to return.

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"
    • addedInput schema / properties / full_text
      Added value: +{
+  "default": false,
+  "description": "Return long texts in full instead of clipped.",
+  "type": "boolean"
+}
    • removedInput schema / properties / max_photos / title
      Removed value: -"Max Photos"
    • removedInput schema / properties / room_id / title
      Removed value: -"Room Id"
    • removedInput schema / title
      Removed value: -"ot_roomArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "ot_roomDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds non-obvious behavior the schema does not: the nightly price is an average for the given dates even when those dates are booked, and instant_on_some_nights is only a room-level flag whose per-night truth lives in ot_price_quote/ot_room_calendar. That is real disclosure beyond structured fields.

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?

Field list is front-loaded and each sentence carries information, but the middle paragraph is long and parenthetically dense, requiring a careful read. Slightly more compact phrasing would preserve all the value.

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 does the work of describing return contents by enumerating the returned fields, which is strong. It leaves minor gaps such as how clipping interacts with full_text and how approximate location is expressed, but an agent can call this tool 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 goes further by explaining what check_in/check_out actually change (date-specific average price vs. undated starting price) and that they do not indicate availability. That is meaning beyond the schema's format hints.

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 ('Get one room') plus the resource and enumerates the exact payload it returns (description, capacity, beds, amenities, house rules, price, etc.). That is far more than a restatement of the title and lets an agent know precisely what a single-room fetch yields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states prerequisites ('Use after ot_search_rooms or ot_find_place') and names the correct follow-on tools for each intent (ot_price_quote for exact total, ot_room_calendar for free nights, ot_reviews, ot_host, ot_similar_rooms). Both when-to-use and what-to-use-next are covered.

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