Deal Radar MCP Server

poll_passive_inventory

Search live flight inventory and GDS fare classes without triggering live pricing, seat-hold calls, or Look-to-Book quota penalties.

Instructions

Zero-Footprint Flight Inventory Search: Queries live flight inventory and GDS fare classes without triggering live pricing/seat-hold calls or Look-to-Book quota penalties.

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>"
    },
    "name": "poll_passive_inventory"
  }
}

Input Schema

Name	Required	Description
`origin`	Yes	Origin airport or city code (e.g. "IDR", "DEL")
`cabinClass`	No	Cabin class
`destination`	Yes	Destination airport or city code (e.g. "BLR", "BOM")
`flightNumber`	No	Optional flight number to filter (e.g. "6E-1117")
`departureDate`	No	Departure date in YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does contribute one genuinely useful behavioral fact: this call does not trigger live pricing, seat holds, or Look-to-Book quota penalties. However, it says nothing about required credentials, rate limits, whether it can be polled safely and how often, or what the response contains (availability only vs. fares), which are significant gaps for an unannotated tool.

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?

A single sentence with the differentiating constraint (no live pricing/quota penalty) front-loaded after the descriptive label. The 'Zero-Footprint Flight Inventory Search:' prefix is a title-like restatement, but it frames the sentence efficiently and no words are wasted.

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

Completeness3/5

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

For a five-parameter, no-annotation, no-output-schema tool, the definition covers the core differentiator but leaves too much unstated: no guidance on how results differ from a live-pricing search, no indication of return shape or volume, and no polling or auth caveats. Adequate to identify the tool, not adequate to call it confidently.

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%, with each of the five parameters already documented including examples and a cabinClass enum, so the description adds no parameter-level meaning and the baseline 3 applies. It does not explain, for instance, whether flightNumber plus departureDate narrows the result to a single record.

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

Purpose4/5

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

Names a specific verb and resource: queries live flight inventory and GDS fare classes. The phrase 'without triggering live pricing/seat-hold calls' implicitly separates it from a live-pricing sibling such as search_flights, but no sibling is named explicitly, so the differentiation is inferential rather than stated.

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?

Usage is only implied: the zero-footprint and no-Look-to-Book-penalty framing suggests 'use this when you don't want to consume quota,' but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the routing rule from the benefit statement.

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