Skip to main content
Glama
Sign In
mrbilit-mcp

mrbilit-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Train price calendar

mb_train_price_calendar
Read-onlyIdempotent

Compare daily train fares to pick the next bookable day for a route, showing only dates with enough free seats; then search trains.

Instructions

Cheapest train ticket per day (one adult) for a route, only days with free seats.

Use to find the cheapest or the next bookable day, then mb_search_trains for that day. Train sales open only about 18 days ahead, so later days are missing.

Input Schema

NameRequiredDescriptionDefault
daysNoNumber of days to cover.
quotaNoSeat quota: general (families, mixed), men only, women only, or car transport.general
seatsNoSeats needed; days without that many free seats are left out.
originYesTrain station id from mb_find_place(mode='train'), e.g. 1 (Tehran) or 191 (Mashhad).
start_dateNoFirst day YYYY-MM-DD, e.g. '2026-10-10'; default today.
destinationYesTrain station id from mb_find_place(mode='train'), e.g. 1 (Tehran) or 191 (Mashhad).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.3.0
    • removedInput schema / properties / days / title
      Removed value: -"Days"
    • removedInput schema / properties / destination / title
      Removed value: -"Destination"
    • removedInput schema / properties / origin / title
      Removed value: -"Origin"
    • removedInput schema / properties / quota / title
      Removed value: -"Quota"
    • removedInput schema / properties / seats / title
      Removed value: -"Seats"
    • removedInput schema / properties / start_date / title
      Removed value: -"Start Date"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_train_price_calendarDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: only days with free seats are returned, and sales open only ~18 days ahead, so later days are absent. That explains partial results an agent would otherwise misread as an error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short lines with zero waste; the core purpose and the free-seat constraint are front-loaded, and the sequencing hint plus sales-window caveat follow compactly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description conveys the return shape (per-day cheapest fare for a route) and the data-coverage limit, which is the main thing an agent needs to interpret results. Only the relationship to mb_train_price is left unaddressed.

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 the six parameters including the quota enum, seats, days and station-id hints are already fully documented. The description adds only the '(one adult)' framing and does not clarify how seats interacts with the free-seat filtering, so the baseline 3 applies.

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 scope: cheapest train ticket per day for a route, restricted to days with free seats. It clearly reads as a calendar-style tool distinct from mb_search_trains, but it never distinguishes itself from the sibling mb_train_price (single-day price), which an agent would need to choose between.

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 states when to use it ('find the cheapest or the next bookable day') and routes the agent to mb_search_trains for the chosen day. It stops short of naming the alternative price tool or any when-not condition, so it is strong but not fully closed-loop.

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