Skip to main content
Glama
sepehr071

mrbilit-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Search trains

mb_search_trains
Read-onlyIdempotent

Search trains between two stations on a given date, and compare every class, adult price, and free seats.

Instructions

Trains between two stations on a date with every class (wagon), its price per adult and free seats.

Seat counts are fresh (not cached). price_toman is per adult; for children, infants or a whole compartment call mb_train_price with the class_id. refund_penalties apply to every class unless a class lists its own. Stops and times: mb_train_stops. No seats left: try mb_train_price_calendar for other days or mb_alternative_routes. A round trip is two calls: the return leg with outbound_class_id.

Input Schema

NameRequiredDescriptionDefault
dateYesTravel date YYYY-MM-DD, e.g. '2026-10-14'. Sales open about 18 days ahead.
sortNoOrder of the trains.earliest
limitNoMax trains.
quotaNoSeat quota: general (families, mixed), men only, women only, or car transport.general
originYesTrain station id from mb_find_place(mode='train'), e.g. 1 (Tehran) or 191 (Mashhad).
destinationYesTrain station id from mb_find_place(mode='train'), e.g. 1 (Tehran) or 191 (Mashhad).
available_onlyNoHide sold-out classes and trains with no free seat.
outbound_class_idNoRound trip, return leg only: the class_id chosen on the outbound leg, e.g. 9847134 (limits the return to the same rail company, as the site does).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.3.0
    • removedInput schema / properties / available_only / title
      Removed value: -"Available Only"
    • removedInput schema / properties / date / title
      Removed value: -"Date"
    • removedInput schema / properties / destination / title
      Removed value: -"Destination"
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / origin / title
      Removed value: -"Origin"
    • removedInput schema / properties / outbound_class_id / title
      Removed value: -"Outbound Class Id"
    • removedInput schema / properties / quota / title
      Removed value: -"Quota"
    • removedInput schema / properties / sort / title
      Removed value: -"Sort"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_search_trainsDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile, and the description adds real behavioral context beyond them: seat counts are fresh (not cached), price_toman is per adult, refund_penalties apply to every class unless overridden, and round-trip return legs are constrained to the same rail company.

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 but front-loaded: the core capability leads, followed by routing and round-trip mechanics. Nearly every sentence earns its place, though the compressed multi-clause routing block is slightly hard to parse.

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?

For an 8-parameter, no-output-schema search tool, the description covers the return shape (class, price per adult, free seats, refund penalties), data freshness, and cross-tool routing. Nothing needed to invoke it correctly 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?

With 100% schema description coverage, baseline is 3, but the description adds meaning beyond the schema — it explains the per-adult basis of pricing, the refund_penalty inheritance rule, and the company-locking behavior of outbound_class_id, which the schema only states mechanically.

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 precise verb+resource+scope: trains between two stations on a date, returning every class with price per adult and free seats. It is clearly distinguishable from siblings like mb_train_price, mb_train_stops, and mb_search_buses.

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?

Explicit routing: children/infants/whole compartments go to mb_train_price with class_id, stops and times to mb_train_stops, sold-out dates to mb_train_price_calendar or mb_alternative_routes, and round trips are described as two calls using outbound_class_id. When-to-use and alternatives are both spelled out.

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

Deploy Server

Other Tools