mrbilit-mcp

Overview Schema Source Related Servers Discussions Admin

Search trains

mb_search_trains

Read-onlyIdempotent

Search trains between two stations on a travel date, listing every class, price per adult, and live free seats so users can compare available options.

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

TableJSON Schema

Name	Required	Description	Default
`date`	Yes	Travel date YYYY-MM-DD, e.g. '2026-10-14'. Sales open about 18 days ahead.
`sort`	No	Order of the trains.	earliest
`limit`	No	Max trains.
`quota`	No	Seat quota: general (families, mixed), men only, women only, or car transport.	general
`origin`	Yes	Train station id from mb_find_place(mode='train'), e.g. 1 (Tehran) or 191 (Mashhad).
`destination`	Yes	Train station id from mb_find_place(mode='train'), e.g. 1 (Tehran) or 191 (Mashhad).
`available_only`	No	Hide sold-out classes and trains with no free seat.
`outbound_class_id`	No	Round 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).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, it discloses that seat counts are fresh (not cached), that price_toman is per adult, and how refund_penalties apply across classes. These are non-obvious behavioral traits an agent cannot infer from the schema or annotations.

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?

Front-loaded with what the tool returns, then dense but purposeful routing sentences; every clause points to a concrete alternative or behavioral fact. Slightly telegraphic in places but no dead weight.

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 search tool with an output schema and full coverage, the description covers selection guidance, output semantics, cross-tool routing, and round-trip composition. Nothing an agent needs 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning to outbound_class_id (return leg only, limits to the same rail company) and clarifies the per-adult pricing dimension. It's meaningful added context, though most parameters are still schema-documented.

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 ('Trains between two stations on a date') and enumerates the returned payload ('every class (wagon), its price per adult and free seats'). It also distinguishes itself from siblings by explicitly routing stops/pricing/calendar lookups elsewhere.

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 names alternatives with the condition that selects them: children/infants/whole-compartment pricing -> mb_train_price, stops/times -> mb_train_stops, sold-out days -> mb_train_price_calendar or mb_alternative_routes. It even spells out the round-trip pattern (two calls, return leg via outbound_class_id).

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