Skip to main content
Glama
sepehr071

otaghak-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Deals and discounts

ot_deals
Read-onlyIdempotent

Find current discounts on Iranian stays: tonight-style last-second rooms and top percent-off discounted listings, sorted by biggest savings. Filter by city, guests, and dates.

Instructions

Current discounts: the home page's last-second deals and the most discounted stays (biggest percent first).

last_second rooms are site-wide tonight-style deals shown 14:00-23:50 Iran time with undated prices; they are left out when city is given. most_discounted lists rooms of the 'discounted' collection (in city if given) that have a discount, sorted by percent; with dates the prices are for that stay. Next: ot_price_quote for the exact total.

Input Schema

NameRequiredDescriptionDefault
cityNoCity slug, e.g. 'ramsar'. Default: whole site.
limitNoRooms per list.
guestsNoGuests, e.g. 4; smaller rooms are left out.
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. Changed13 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 / city / anyOf
      Previous value: -[
-  {
-    "description": "Slug (letters, digits, -).",
-    "pattern": "^[A-Za-z][A-Za-z0-9-]{1,60}$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[A-Za-z][A-Za-z0-9-]{1,60}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / city / description
      Previous value: -"City slug to find its most discounted stays, e.g. 'ramsar'. Default: the whole site."New value: +"City slug, e.g. 'ramsar'. Default: whole site."
    • removedInput schema / properties / city / title
      Removed value: -"City"
    • 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"
    • changedInput schema / properties / limit / default
      Previous value: -10New value: +8
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / title
      Removed value: -"ot_dealsArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "ot_dealsDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description earns credit by adding the operational details those hints can't: the 14:00–23:50 Iran-time window, that last_second prices are undated, and that city-supplied calls silently drop that list. It stops short of describing result shape or any rate/refresh behavior.

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?

Three tight sentences, front-loaded with what the tool returns, then the per-list caveats, then the sibling handoff. Dense but every clause carries information; only mild redundancy in the opening 'Current discounts:' framing.

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 must carry the return-value burden and largely does: two named lists, their membership rules, ordering, and the date-dependence of prices. Minor gaps remain, e.g. that `limit` applies per list and whether results can be empty for a city with no discounted inventory.

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 description coverage is 100%, so the baseline is 3; the description goes beyond it by explaining what `city` actually does to the result set (excludes last_second) and how dates change pricing (prices are for that stay vs undated), which the schema alone does not convey.

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?

The description names a concrete resource and its two constituent lists ('last_second' deals and 'most_discounted' stays), plus the sort order (biggest percent first). An agent can tell exactly what comes back without opening any schema, and it distinguishes itself from ot_search_rooms/ot_search_filters by being a discounts view.

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

Usage Guidelines3/5

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

It gives real conditional guidance — last_second is omitted when `city` is supplied, and dated queries change the price semantics — and routes the agent forward to ot_price_quote for totals. What's missing is when NOT to use this tool versus ot_search_rooms or ot_search_filters for a general availability search; usage is implied rather than contrasted.

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