viajante

Overview Schema Source Related Servers Discussions Admin

Flexible-date flight search

search_flex

Read-onlyIdempotent

Search flights across a flexible +/-N-day window around a given date for an origin-destination route, then run one shopping query for a lower-fare travel day.

Instructions

Flex window of +/-N days around one date, then one shopping search on the cheapest day. route is ORIGIN-DEST; around is an ISO date. Use search_dates for a cheapest-week calendar; do not brute-force a date matrix. Currency and country as in search_flights. A markup_drift day is not no_results: do not invent a cheapest week. A named-date search_flights is allowed.

    deadline_seconds stops starting queries after that many seconds; unfinished
    queries are error code deadline (not loaded, not empty). See get_guide.

Input Schema

TableJSON Schema

Name	Required	Default
`top`	No
`via`	No
`bags`	No
`flex`	Yes
`sort`	No	ranked
`trip`	No	one-way
`cabin`	No	economy
`proxy`	No
`route`	Yes
`adults`	No
`around`	Yes
`nearby`	No
`nights`	No
`country`	No
`airlines`	No
`alliance`	No
`carry_on`	No
`children`	No
`currency`	No
`max_stops`	No
`price_cap`	No
`exclude_via`	No
`max_layover`	No
`min_layover`	No
`depart_after`	No
`max_duration`	No
`no_overnight`	No
`arrive_before`	No
`depart_window`	No
`baggage_buffer`	No
`infants_on_lap`	No
`infants_in_seat`	No
`deadline_seconds`	No
`exclude_airlines`	No
`exclude_airports`	No
`exclude_alliance`	No
`include_airports`	No
`require_overnight`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`empty_note`	Yes
`error_code`	Yes
`observed_at`	Yes
`retry_after`	Yes
`completeness`	Yes
`empty_reason`	Yes
`observed_at_basis`	Yes
`retry_after_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed40 schema fields changedv1.5.2Oct 19, 2026

removedInput schema / properties / adults / title
```
Removed value: -"Adults"
```
removedInput schema / properties / airlines / title
```
Removed value: -"Airlines"
```
removedInput schema / properties / alliance / title
```
Removed value: -"Alliance"
```
removedInput schema / properties / around / title
```
Removed value: -"Around"
```
removedInput schema / properties / arrive_before / title
```
Removed value: -"Arrive Before"
```
removedInput schema / properties / baggage_buffer / title
```
Removed value: -"Baggage Buffer"
```
removedInput schema / properties / bags / title
```
Removed value: -"Bags"
```
removedInput schema / properties / cabin / title
```
Removed value: -"Cabin"
```
removedInput schema / properties / carry_on / title
```
Removed value: -"Carry On"
```
removedInput schema / properties / children / title
```
Removed value: -"Children"
```
removedInput schema / properties / country / title
```
Removed value: -"Country"
```
removedInput schema / properties / currency / title
```
Removed value: -"Currency"
```

addedInput schema / properties / deadline_seconds

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

removedInput schema / properties / depart_after / title
```
Removed value: -"Depart After"
```
removedInput schema / properties / depart_window / title
```
Removed value: -"Depart Window"
```
removedInput schema / properties / exclude_airlines / title
```
Removed value: -"Exclude Airlines"
```
removedInput schema / properties / exclude_airports / title
```
Removed value: -"Exclude Airports"
```
removedInput schema / properties / exclude_alliance / title
```
Removed value: -"Exclude Alliance"
```
removedInput schema / properties / exclude_via / title
```
Removed value: -"Exclude Via"
```
removedInput schema / properties / flex / title
```
Removed value: -"Flex"
```
removedInput schema / properties / include_airports / title
```
Removed value: -"Include Airports"
```
removedInput schema / properties / infants_in_seat / title
```
Removed value: -"Infants In Seat"
```
removedInput schema / properties / infants_on_lap / title
```
Removed value: -"Infants On Lap"
```
removedInput schema / properties / max_duration / title
```
Removed value: -"Max Duration"
```
removedInput schema / properties / max_layover / title
```
Removed value: -"Max Layover"
```
removedInput schema / properties / max_stops / title
```
Removed value: -"Max Stops"
```
removedInput schema / properties / min_layover / title
```
Removed value: -"Min Layover"
```
removedInput schema / properties / nearby / title
```
Removed value: -"Nearby"
```
removedInput schema / properties / nights / title
```
Removed value: -"Nights"
```
removedInput schema / properties / no_overnight / title
```
Removed value: -"No Overnight"
```
removedInput schema / properties / price_cap / title
```
Removed value: -"Price Cap"
```
removedInput schema / properties / proxy / title
```
Removed value: -"Proxy"
```
removedInput schema / properties / require_overnight / title
```
Removed value: -"Require Overnight"
```
removedInput schema / properties / route / title
```
Removed value: -"Route"
```
removedInput schema / properties / sort / title
```
Removed value: -"Sort"
```
removedInput schema / properties / top / title
```
Removed value: -"Top"
```
removedInput schema / properties / trip / title
```
Removed value: -"Trip"
```
removedInput schema / properties / via / title
```
Removed value: -"Via"
```
removedInput schema / title
```
Removed value: -"search_flexArguments"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "completeness": {
+      "enum": [
+        "complete",
+        "partial",
+        "blocked"
+      ],
+      "type": "string"
+    },
+    "empty_note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "empty_reason": {
+      "anyOf": [
+        {
+          "enum": [
+            "provider_empty",
+            "filtered_out",
+            "not_loaded"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "error_code": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at_basis": {
+      "anyOf": [
+        {
+          "enum": [
+            "provider",
+            "fetch"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "retry_after": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "retry_after_seconds": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "status": {
+      "enum": [
+        "ok",
+        "no_results",
+        "rate_limited",
+        "blocked",
+        "timeout",
+        "failed"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "completeness",
+    "empty_reason",
+    "empty_note",
+    "error_code",
+    "retry_after",
+    "retry_after_seconds",
+    "observed_at",
+    "observed_at_basis"
+  ],
+  "type": "object"
+}

First observedv1.0.0Sep 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: deadline_seconds stops starting queries and returns error code deadline (not loaded, not empty), plus markup_drift semantics, and points to get_guide. Strong but not exhaustive (no pagination/rate-limit detail).

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?

Mostly tight and front-loaded: the core mechanic and sibling routing come first, with the deadline caveat and guide pointer afterward. A couple of sentences (markup_drift, allowed search_flights) are slightly fragmentary but each carries routing or failure-mode value.

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?

An output schema exists, so return-value explanation is rightly absent. However, for a 38-parameter tool with zero schema coverage, the description's parameter gap is a meaningful completeness shortfall; the routing and failure-mode guidance are good but do not fully equip the agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 38 parameters and 0% schema description coverage, the schema documents essentially nothing. The description only clarifies route (ORIGIN-DEST), around (ISO date), flex, and defers currency/country to search_flights. That leaves the vast majority of parameters (sort, trip, cabin, stops, layover windows, excludes, passengers, etc.) semantically undocumented in either place.

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?

States a specific verb and resource ('Flex window of +/-N days around one date, then one shopping search on the cheapest day') and names route/around formats. It clearly distinguishes itself from search_dates and search_flights, so an agent can select it without opening a schema.

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 routes to alternatives: 'Use search_dates for a cheapest-week calendar; do not brute-force a date matrix' and 'A named-date search_flights is allowed.' It also gives exclusion guidance on markup_drift days ('not no_results'), so when-to-use and when-not are fully covered.

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