mrbilit-mcp

Overview Schema Source Related Servers Discussions Admin

Search buses

mb_search_buses

Read-onlyIdempotent

Search intercity buses by origin, destination, and date to compare departure times, ticket prices, free seats, bus types, stops, and refund penalties.

Instructions

Intercity buses on a date: company, terminal, times, price per seat, free seats, bus type, stops, refund penalties.

A city id covers all its terminals; a terminal id only that terminal. price_toman is per seat (a party pays it once per seat). refund_penalties apply to every bus unless a bus lists its own: until_hours_before = the step applies until that many hours before departure (null = up to departure); free_cancel_minutes = free cancellation within that many minutes after purchase. Next: mb_bus_seats with a bus_id for seat numbers and women/men seats; other days: mb_bus_price_calendar.

Input Schema

Name	Required	Description	Default
`date`	Yes	Departure date YYYY-MM-DD, e.g. '2026-10-20'.
`sort`	No	Order of the buses.	earliest
`limit`	No	Max buses.
`origin`	Yes	Bus city or terminal id from mb_find_place(mode='bus'), e.g. 11320000 (Tehran, all terminals) or 31310000 (Mashhad).
`vip_only`	No	Only VIP buses.
`companies`	No	Only these company ids, from `companies` of a result or mb_companies(mode='bus'), e.g. [4, 16].
`destination`	Yes	Bus city or terminal id from mb_find_place(mode='bus'), e.g. 11320000 (Tehran, all terminals) or 31310000 (Mashhad).
`depart_after`	No	Local time HH:MM, e.g. '18:00'.
`depart_before`	No	Local time HH:MM, e.g. '18:00'.
`include_sold_out`	No	Also list buses with no free seat.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.3.0Oct 17, 2026
- removedInput schema / properties / companies / title
```
Removed value: -"Companies"
```
- 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 / include_sold_out / title
```
Removed value: -"Include Sold Out"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / origin / title
```
Removed value: -"Origin"
```
- removedInput schema / properties / sort / title
```
Removed value: -"Sort"
```
- removedInput schema / properties / vip_only / title
```
Removed value: -"Vip Only"
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_search_busesDictOutput",
-  "type": "object"
-}New value: +null
```
First observedv0.1.0Oct 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real domain behavior beyond that: a city id spans all its terminals while a terminal id is exclusive, price_toman is per seat, and refund penalties apply per bus unless overridden. Auth requirements and result pagination are not addressed, keeping it below a 5.

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?

Dense and front-loaded: the first sentence states exactly what comes back, then constraints, then next steps. The refund_penalties sentence is long and slightly run-on, but every clause carries distinct information, so there is no filler.

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?

With 10 parameters, no output schema, and several domain-specific terms (price_toman, refund_penalties, city vs terminal ids), the description supplies exactly the missing context an agent needs: return field inventory, id semantics, and the refund-penalty field meanings. Nothing essential is left undocumented.

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

Parameters5/5

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

Schema description coverage is 100%, so a 3 is the baseline, but the description genuinely clarifies parameter meaning beyond the schema: origin/destination take either a city id (all terminals) or a terminal id (that terminal only), which is the single most error-prone input decision. It also clarifies the price_toman unit semantics.

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?

Opens with a specific verb+resource and scope ('Intercity buses on a date') and enumerates the returned fields (company, terminal, times, price per seat, free seats, bus type, stops, refund penalties). It also distinguishes itself from mb_bus_seats and mb_bus_price_calendar, so an agent can tell it apart from siblings without opening their schemas.

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?

Explicitly routes follow-on needs: 'Next: mb_bus_seats with a bus_id for seat numbers and women/men seats; other days: mb_bus_price_calendar.' That covers adjacent alternatives clearly, but it never states when NOT to use this tool (e.g. vs mb_search_taxis or mb_alternative_routes for the same route), so it falls short of full when/when-not guidance.

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

Search buses

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools