otaghak-mcp

Overview Schema Source Related Servers Discussions Admin

Search stays

ot_search_rooms

Read-onlyIdempotent

Search villas, cottages, and apartments by city, province, or dates to compare nightly prices and total stay costs for your guest count.

Instructions

Search Otaghak stays (villas, cottages, apartments, eco-lodges) in a city, province or collection.

With check_in/check_out every room is available on those dates and carries the stay price: price_per_night (average after discount) and stay_total for guests (incl. extra-guest charges; estimate, can be a few Toman off). Without dates prices are undated starting prices. Get slugs from ot_find_place, filter codes from ot_search_filters. Next: ot_room for details, ot_price_quote for the exact total, ot_room_calendar for other dates.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`city`	No	City slugs from ot_find_place, e.g. ['ramsar'] or ['ramsar', 'chalus'] (any of them).
`name`	No	Words of the room name, e.g. 'نرگس'.
`page`	No	Zero-based page number.
`sort`	No	Order. cheapest/most_expensive use the nightly price after discount; with dates, cheapest then re-sorts each page by stay_total (extra-guest charges included).	recommended
`limit`	No	Rooms per page.
`prime`	No	Only 'prime' (premium) rooms.
`guests`	No	Number of guests, e.g. 4. Rooms that cannot take that many are left out.
`filters`	No	Amenity, rule, region and feature codes from ot_search_filters, exactly as returned, e.g. ['attributeValues=130202\|130201\|130101\|130102\|130103\|AGG1'] (pool) or ['ruleValues=10101\|10103\|10102'] (pets). All must match.
`instant`	No	Only instant booking (no host approval).
`bedrooms`	No	Minimum bedrooms, e.g. 2.
`check_in`	No	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.
`city_tag`	No	City theme page slug with `city`, e.g. 'beach' or 'cottage' (from ot_travel_guide related pages).
`province`	No	Province slug, e.g. 'mazandaran'.
`check_out`	No	Departure day, Gregorian YYYY-MM-DD, e.g. '2026-10-23' (3 nights). At most 20 nights after check_in.
`max_price`	No	Highest nightly price in Toman (after discount), e.g. 8000000.
`min_price`	No	Lowest nightly price in Toman (after discount), e.g. 3000000.
`collection`	No	Collection (landing) code from ot_destinations, e.g. 'beach', 'jungle', 'villapool', 'discounted', 'lastsecond'.
`min_rating`	No	Minimum rating: 3, 4 or 5.
`rent_types`	No	Rent type: whole_place (دربست), semi_private, shared.
`room_types`	No	Room type ids from ot_search_filters, e.g. [138] villa, [154] cottage, [137] apartment.
`district_id`	No	District id (near a landmark) from ot_search_filters, used with `city`, e.g. 230.
`include_nearby`	No	Also include rooms around the city.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the read-only, idempotent, open-world profile, so the description is free to add the non-obvious behavior: prices are undated starting prices without dates, and with dates they are estimates that 'can be a few Toman off' while including extra-guest charges. That estimate caveat is genuinely valuable context an agent cannot get from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight paragraphs: scope first, then date/pricing semantics, then the tool chain. For a 22-parameter tool this is efficiently front-loaded with no filler sentences.

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?

An output schema exists, so return values need not be explained, yet the description still clarifies the two price fields' meaning. Given the tool's complexity, the definition covers scope, pricing duality, dependencies and follow-ons adequately; only explicit when-not guidance 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 100%, so every parameter is already documented in structured form; baseline 3 applies. The description adds cross-parameter semantics (check_in/check_out together drive availability and pricing) but no per-parameter detail beyond what the schema already carries.

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?

Opens with a specific verb and resource ('Search Otaghak stays') and enumerates the property types and the three scoping axes (city, province, collection). It is clearly distinguishable from siblings like ot_room (single stay details) or ot_find_place (slug lookup).

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?

Explicitly routes to prerequisites ('Get slugs from ot_find_place, filter codes from ot_search_filters') and names the follow-on tools (ot_room, ot_price_quote, ot_room_calendar) with their conditions. It lacks any 'when not to use this' guidance relative to siblings like ot_deals or ot_similar_rooms, so not a full 5.

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

Deploy Server