Deal Radar MCP Server

schedule_sweep_watcher

Schedules automated silent fare checks during low-contention windows and after hold expiration to catch reopened lower RBD buckets and alert when target price is met.

Instructions

Revenue Management Sweep Watcher: Schedules automated silent checks during low-contention windows (03:30 - 05:00 AM IST overnight GDS sweep and 20-min post-hold expiration) to catch re-opened lower RBD fare buckets.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "origin": "<origin>",
      "destination": "<destination>",
      "departureDate": "<departureDate>",
      "targetPrice": "<targetPrice>"
    },
    "name": "schedule_sweep_watcher"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Optional notes
`origin`	Yes	Origin airport or city
`destination`	Yes	Destination airport or city
`targetPrice`	Yes	Target price threshold in ₹ to trigger notification
`flightNumber`	No	Optional flight number
`departureDate`	Yes	Departure date in YYYY-MM-DD
`targetFareClass`	No	Optional target fare bucket code (e.g. "Q", "O")

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden and only partially delivers: it discloses that checks are 'silent' and time-boxed to low-contention windows, which is useful. It omits whether the schedule is recurring or one-shot, how long it persists, how the notification triggered by targetPrice is delivered, whether it can be cancelled, and any cost or rate implications of running GDS sweeps.

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

Conciseness3/5

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

It is a single sentence with no filler, but it opens by restating the title ('Revenue Management Sweep Watcher:') and then packs the informative part into a dense parenthetical of internal acronyms. Front-loading the actual effect on the user's watch instead of the title echo would make it easier to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A seven-parameter scheduling tool with no annotations and no output schema needs more than this: the description says nothing about what the caller gets back, how long the watcher lives, or how to stop it. The timing detail is genuinely useful, but the persistent-side-effect story is left incomplete.

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 all seven parameters including origin, destination, departureDate, targetPrice, and targetFareClass are already documented. The description adds no meaning beyond the schema - it does not explain how targetPrice and targetFareClass interact with the sweep windows, so it sits at the baseline for fully documented schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verbs 'Schedules automated silent checks' identify the action, but the object is wrapped in domain jargon ('RBD fare buckets', 'GDS sweep', 'post-hold expiration') that an agent may not map to a concrete effect. Nothing in the text distinguishes it from plausible siblings such as set_price_alert, set_flight_price_alert, or start_alert_poller, so the agent cannot tell which scheduling mechanism to pick.

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

Usage Guidelines2/5

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

The description explains when the watcher runs (03:30-05:00 IST, 20 min after hold expiration) but never when an agent should call this tool rather than an alternative. There are no stated prerequisites, no exclusions, and no mention of whether it replaces or complements the existing alert tools.

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