mcp-route-master

Plan a bus trip

plan_bus_trip

Read-onlyIdempotent

Plan an intercity bus trip in India: resolve origin and destination, then get official booking links for your route and date, plus filter tips and anti-scam advice.

Instructions

Plan an intercity bus trip in India.

Resolves the two places, then returns booking links for this route and date on official sites (redBus, MakeMyTrip, Goibibo, AbhiBus, Cleartrip, FlixBus, IRCTC Bus), filter tips for the requested bus type and time, and anti-scam advice. It does not return live seats or fares: the user sees those on the linked site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "origin": "<origin>",
      "destination": "<destination>",
      "travel_date": "<travel_date>"
    },
    "name": "plan_bus_trip"
  }
}

Input Schema

Name	Required	Description	Default
`origin`	Yes	Where the traveller starts: a city or a known boarding point, as the user said it (e.g. 'Delhi', 'Bangalore', 'Kashmiri Gate').
`bus_type`	No	Seat/AC preference. 'sleeper' means a bed (berth); 'semi_sleeper' is a reclining seat.	any
`destination`	Yes	Where the traveller is going: a city or a known drop point.
`travel_date`	Yes	Departure date as YYYY-MM-DD in India time. Convert 'tomorrow' or 'next Monday' to a date before calling.
`government_only`	No	True when the user wants government (state RTC) buses only.
`departure_window`	No	Preferred departure time.	any

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Nov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds genuinely useful context beyond them: the two-step resolve-then-link behavior, the inclusion of filter tips and anti-scam advice, and the explicit warning that live seats and fares are absent, which prevents the agent from promising real-time availability.

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 sentences with the core action front-loaded, followed by return contents and then the limitation. Every sentence carries distinct information and nothing is repeated from the name or title.

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?

There is no output schema, so the description carries responsibility for describing return values, and it does so comprehensively: booking links, filter tips, anti-scam advice, plus the explicit absence of live seats and fares. Combined with a fully documented six-parameter schema and annotations covering the safety profile, an agent has everything needed to call it correctly.

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, travel_date, bus_type, departure_window, and government_only are already fully documented with examples and enum meanings. The description's only addition is signalling that place names are resolved internally and that bus type and time drive filtering, which is marginal beyond the schema.

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?

Uses a specific verb and resource ('Plan an intercity bus trip in India') and describes the actual output: resolved places, official-site booking links, filter tips, and anti-scam advice. It is clear what the tool produces, though it does not name or contrast itself with siblings such as rank_buses or check_booking_safety.

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?

The geographic scope ('intercity bus trip in India') and the explicit exclusion ('does not return live seats or fares: the user sees those on the linked site') tell the agent where this tool fits and what it will not answer. It stops short of naming alternatives for the excluded jobs, so no full when/when-not routing map is provided.

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

Deploy Server