mrbilit-mcp

Overview Schema Source Related Servers Discussions Admin

Search intercity taxis

mb_search_taxis

Read-onlyIdempotent

Find private intercity taxi offers by origin, destination and date, returning whole-car prices, car classes and departure time slots for up to 3 passengers.

Instructions

Private door-to-door intercity taxis (whole car, up to 3 passengers) for a date, one offer per pick-up slot.

price_toman is for the whole car. Many city pairs have no taxis (e.g. Tehran-Mashhad).

Input Schema

Name	Required	Description	Default
`date`	Yes	Departure date YYYY-MM-DD.
`limit`	No	Max offers.
`origin`	Yes	City id from mb_find_place(mode='taxi'), e.g. 11320000 (Tehran).
`car_class`	No	Car class.	any
`destination`	Yes	City id from mb_find_place(mode='taxi'), e.g. 11320000 (Tehran).
`depart_after`	No	Local time HH:MM, e.g. '18:00'.
`depart_before`	No	Local time HH:MM, e.g. '18:00'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.5.0Nov 7, 2026

changedInput schema / properties / car_class / description

Previous value: -"Car class: economy (Samand/Peugeot), vip, formal (top cars)."New value: +"Car class."

changedInput schema / properties / date / description

Previous value: -"Departure date YYYY-MM-DD, e.g. '2026-10-20'."New value: +"Departure date YYYY-MM-DD."

removedInput schema / properties / depart_after / anyOf

Removed value: -[
-  {
-    "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / depart_after / pattern
```
Added value: +"^([01]\\d|2[0-3]):[0-5]\\d$"
```
addedInput schema / properties / depart_after / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / depart_before / anyOf

Removed value: -[
-  {
-    "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / depart_before / pattern
```
Added value: +"^([01]\\d|2[0-3]):[0-5]\\d$"
```
addedInput schema / properties / depart_before / type
```
Added value: +[
+  "string",
+  "null"
+]
```

changedInput schema / properties / destination / description

Previous value: -"City id from mb_find_place(mode='taxi'), e.g. 11320000 (Tehran) or 54310000 (Rasht)."New value: +"City id from mb_find_place(mode='taxi'), e.g. 11320000 (Tehran)."

changedInput schema / properties / origin / description

Previous value: -"City id from mb_find_place(mode='taxi'), e.g. 11320000 (Tehran) or 54310000 (Rasht)."New value: +"City id from mb_find_place(mode='taxi'), e.g. 11320000 (Tehran)."

removedInput schema / title

Removed value: -"mb_search_taxisArguments"

Changed8 schema fields changedv0.3.0Oct 17, 2026
- removedInput schema / properties / car_class / title
```
Removed value: -"Car Class"
```
- 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 / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / origin / title
```
Removed value: -"Origin"
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_search_taxisDictOutput",
-  "type": "object"
-}New value: +null
```
First observedv0.1.0Oct 5, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's job is to add operational context, and it does: whole-car pricing, a 3-passenger capacity ceiling, one offer per pick-up slot (result granularity), and sparse city-pair coverage. It does not explain what fields an offer contains beyond price.

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?

Two short sentences with no filler, and the core definition comes first with the coverage caveat second. Slightly clipped phrasing ('for a date, one offer per pick-up slot') costs a little clarity.

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 7-parameter tool with no output schema, the description covers what the tool returns only at the level of price semantics and one-offer-per-slot; it doesn't describe the offer record (company, car class, departure time) an agent would need to present results. Adequate but with a clear gap.

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 origin/destination/date/limit/car_class/time windows are already documented with formats and examples. The description only clarifies that the price is whole-car, which relates to a return field rather than any input parameter, so it adds little parameter-level meaning.

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?

States a specific resource and shape: 'Private door-to-door intercity taxis (whole car, up to 3 passengers) for a date, one offer per pick-up slot.' The mode distinction from the bus/train/flight siblings is implicit in 'taxis' rather than named, but an agent can tell what it retrieves.

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?

The note that 'Many city pairs have no taxis (e.g. Tehran-Mashhad)' usefully warns when the tool returns nothing, which hints at falling back to another mode, but it never names an alternative such as mb_search_buses or mb_alternative_routes, nor states prerequisites beyond what the schema implies.

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

Search intercity taxis

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools