Skip to main content
Glama

HotelRefund Price Tracker

by net.hotelrefund
OverviewDiscussionsAdmin

Start tracking a hotel price

track_hotel_price
Idempotent

Today is 2026-09-24 (UTC) — never infer the date from the conversation or from training data. Stay dates are calendar days in the hotel's local time zone, which in Asia is already ahead of UTC, so check_in must be 2026-09-23 or later; an earlier check_in is rejected, not silently accepted. Start tracking one hotel (agoda_hotel_id from search_hotels) for one stay (check_in to check_out, YYYY-MM-DD). This is the tool that creates lasting state: from now on the Agoda price is checked automatically several times a day and every observed price is recorded, so the same tracking_id can be asked about days or weeks later with get_price_history. Free, anonymous and public; no account. If the same hotel and dates are already tracked, the existing tracking is returned instead of a duplicate, so it is safe to call again. The response includes tracking_id, booking_url (the Agoda page for this hotel via a HotelRefund redirect) and track_page_url (the booking-decision page: price chart, timing read and a book button; in the language given by language, with track_page_urls for all four). Used both before booking (to catch a drop) and after booking a refundable rate (to see when rebooking would pay off).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
check_inYesCheck-in date, YYYY-MM-DD (today up to 540 days ahead).
currencyNoOptional ISO currency for recorded prices: KRW, JPY, USD, EUR, TWD, HKD, CNY, SGD, THB, GBP, AUD or VND. Defaults by language.
languageNoOptional locale for the tracked rate: ko-kr, ja-jp, en-us, zh-cn, zh-tw or zh-hk (default en-us).
check_outYesCheck-out date, YYYY-MM-DD (after check_in, stay of 60 nights or less).
agoda_hotel_idYesHotel id from search_hotels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond annotations: idempotent duplicate handling, automatic periodic price checks, lasting state, timezone-aware check_in validation, and the fact that it is free/anonymous/public. This aligns with and enriches the idempotentHint, openWorldHint, and readOnlyHint=false annotations.

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?

The description is long but every section earns its place: the date/timezone caveat prevents avoidable errors, the stateful behavior explanation is essential for correct use, and the response URL semantics aid later steps. It could be tightened, but it is well-organized and not padded.

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?

For a stateful tool with no output schema, the description fully covers what an agent needs: required inputs, response fields (tracking_id, booking_url, track_page_url), idempotence, side effects, and usage context. Nothing critical is missing.

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. The description adds meaningful semantic detail: check_in must be 2026-09-23 or later because of Asia timezone lead, agoda_hotel_id must come from search_hotels, and language influences track_page_url. This goes beyond the schema's basic field descriptions.

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?

Description states a specific verb and resource: 'Start tracking one hotel ... for one stay' using agoda_hotel_id from search_hotels. It clearly differentiates itself from siblings by emphasizing it creates lasting state and produces tracking_id, which get_price_history later consumes.

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 says this is the tool that creates lasting state and can be queried later with get_price_history, and that agoda_hotel_id comes from search_hotels. It also covers when to use it: before booking to catch a drop and after booking a refundable rate to see when rebooking pays off.

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

All HotelRefund Price Tracker toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources