mrbilit-mcp

Overview Schema Source Related Servers Discussions Admin

Search flights

mb_search_flights

Read-onlyIdempotent

Search flights by date to find bookable options with prices, seat availability, baggage allowance, and schedules for one-way or round trips.

Instructions

Search flights for a date: every bookable flight with price, seats left, baggage and times.

price_toman is one adult's fare (taxes included); total_toman the whole party. Domestic round trips come back as two lists (outbound, return, separate tickets); international ones as packages priced for both ways (flight_id names both legs). International flights from Tehran can leave from IKA when THR is asked (segments show the real airports). Flights not on sale are counted in not_on_sale. Next: mb_flight_fare_details with the flight_id (refunds, exact baggage, rules); to pick the day first, mb_flight_price_calendar.

Input Schema

Name	Required	Description	Default
`date`	Yes	Gregorian date YYYY-MM-DD, e.g. '2026-10-20'.
`sort`	No	Order of the flights.	cheapest
`cabin`	No	Cabin class filter (applied here; the API itself ignores it).	any
`limit`	No	Max flights per list.
`adults`	No	Adults (12+).
`origin`	Yes	IATA airport or city code from mb_find_place(mode='flight'), e.g. 'THR', 'MHD', 'IKA' or 'ISTALL' (all Istanbul airports).
`infants`	No	Infants (under 2).
`airlines`	No	Only these airline codes, e.g. ['IR', 'W5'] (codes from results or mb_companies).
`children`	No	Children (2-11).
`destination`	Yes	IATA airport or city code from mb_find_place(mode='flight'), e.g. 'THR', 'MHD', 'IKA' or 'ISTALL' (all Istanbul airports).
`direct_only`	No	Only flights without a connection.
`return_date`	No	Return date YYYY-MM-DD for a round trip, e.g. '2026-10-23'; omit for one-way.
`depart_after`	No	Local time HH:MM, e.g. '06:00'.
`depart_before`	No	Local time HH:MM, e.g. '06:00'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.3.0Oct 17, 2026
- removedInput schema / properties / adults / title
```
Removed value: -"Adults"
```
- removedInput schema / properties / airlines / title
```
Removed value: -"Airlines"
```
- removedInput schema / properties / cabin / title
```
Removed value: -"Cabin"
```
- removedInput schema / properties / children / title
```
Removed value: -"Children"
```
- removedInput schema / properties / date / title
```
Removed value: -"Date"
```
- removedInput schema / properties / depart_after / title
```
Removed value: -"Depart After"
```
- removedInput schema / properties / depart_before / title
```
Removed value: -"Depart Before"
```
- removedInput schema / properties / destination / title
```
Removed value: -"Destination"
```
- removedInput schema / properties / direct_only / title
```
Removed value: -"Direct Only"
```
- removedInput schema / properties / infants / title
```
Removed value: -"Infants"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / origin / title
```
Removed value: -"Origin"
```
- removedInput schema / properties / return_date / title
```
Removed value: -"Return Date"
```
- removedInput schema / properties / sort / title
```
Removed value: -"Sort"
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_search_flightsDictOutput",
-  "type": "object"
-}New value: +null
```
First observedv0.1.0Oct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses real hidden behavior: international flights from Tehran may actually depart IKA when THR is requested (segments show real airports), off-sale flights are counted in not_on_sale, and domestic round trips return two separate ticket lists while international ones return a two-way package whose flight_id names both legs. These are non-obvious traits an agent could not infer from the schema.

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 sentences, front-loaded with the core purpose and no filler; each clause carries information. The middle sentence is dense with parenthetical asides (outbound/return, flight_id leg naming, IKA/THR), which costs some parseability but every clause earns its place.

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?

There is no output schema, so the description must explain return values, and it does: fare fields, the two-list vs. package round-trip shapes, and the not_on_sale bucket. Combined with the forward routing to fare details and the calendar, nothing essential for correct invocation 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 description coverage is 100%, so the schema already carries parameter meaning and the baseline is 3. The description goes slightly further by explaining that price_toman is one adult's fare with taxes while total_toman covers the whole party, which clarifies how the adults/children/infants parameters affect pricing.

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 ('Search flights for a date') and immediately enumerates what the result set contains (price, seats left, baggage, times), which no sibling such as mb_search_trains or mb_search_buses provides. An agent can distinguish this from the train/bus/taxi/hotel searchers without opening any schema.

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

Usage Guidelines4/5

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

It routes the agent forward explicitly: use mb_flight_fare_details with the returned flight_id for refunds/baggage/rules, and mb_flight_price_calendar if the day must be chosen first. That is clear conditional guidance, but it never states when this tool is the wrong choice (e.g. vs. the calendar or fare-details tools as entry points) and gives no prerequisites.

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

Search flights

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools