Chelaile MCP

Get first-stop departure predictions (incl. late-evening trips)

bus_get_timetable

Read-onlyIdempotent

Get first-stop bus departure times for a line and find the next departure after a chosen time, including late-evening service from previous days' schedules.

Instructions

Per-trip departures from the line's FIRST stop — answers "when does the next bus leave the origin terminal".

Today's predicted departures are a rolling window covering only roughly the next two hours, so the last trip of the service day is never included. This tool therefore also returns yesterdayDepartures / dayBeforeDepartures, the previous two service days' complete actual schedules, and resolves nextDeparture against them so late-evening queries still get an answer.

Pass at_time ("HH:MM", Beijing time) to ask "what is the next departure after 19:10" instead of using the current clock.

Args:

city_id (string, required)
line_id (string, required)
line_no (string, required): rider-facing short name from bus_search.lines[].name (e.g. '71'). NOT the internal lineNo like 'r95817'.
direction ('0'|'1'): the line direction
at_time ('HH:MM', optional): reference clock; defaults to now in Asia/Shanghai
response_format ('markdown' | 'json')

Returns (json): { "line": { "lineId":"...", "name":"71", "direction":1, "startSn":"...", "endSn":"..." }, "mode": "scheduled", "nextDeparture": "20:00", "nextDepartureSource": "yesterday-actual", "lastPredictedDeparture": "20:00", "firstStopDepartures": ["06:30", "06:45", "..."], "segments": [{ "fromTime":"06:30", "toTime":"10:00", "intervalMin":18, "departures":[...] }, ...], "yesterdayDepartures": ["06:30", ..., "21:00"], "dayBeforeDepartures": ["06:30", ..., "20:59"], "depTitle": "首站发车预测" }

Some lines run at a fixed headway with no per-trip data (mode='interval'); for those use bus_get_line_detail to read firstTime/lastTime.

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": {
      "city_id": "<city_id>",
      "line_id": "<line_id>",
      "line_no": "<line_no>",
      "direction": "<direction>"
    },
    "name": "bus_get_timetable"
  }
}

Input Schema

Name	Required	Description	Default
`at_time`	No	Answer 'what is the next departure after this time' instead of using the current clock. Useful for planning a later trip, e.g. '19:10'.
`city_id`	Yes
`line_id`	Yes
`line_no`	Yes	Rider-facing short name (search.lines[].name), e.g. '71'. NOT the internal lineNo like 'r95817'.
`direction`	Yes
`response_format`	No	Output format: 'markdown' for human-readable text, 'json' for full structured data	markdown

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.0Nov 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: the ~2-hour rolling prediction window, why the last trip of the day is missing, the yesterdayDepartures/dayBeforeDepartures fallback, and how nextDepartureSource resolves the answer. The interval-mode caveat is exactly the kind of disclosure an agent needs before trusting the output.

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 purpose, then a behavior paragraph, then Args and Returns sections — a structure that scans well. The Returns JSON block is long but justified because no output schema exists; the quoted rider question is slight redundancy against the following sentence.

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?

Given six parameters, no output schema, and non-trivial fallback logic, the description covers the mechanics, the return shape, and the failure mode well. Remaining gaps are minor: the meaning of direction values and where city_id/line_id are sourced from are left implicit.

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?

At 50% schema coverage, the description restates what the schema already documents for line_no and at_time without adding format detail, and describes direction only as "the line direction" with no explanation of what '0' versus '1' means. city_id and line_id get no explanation in either the schema or the description, though the returns block does clarify output shape.

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 and resource: "Per-trip departures from the line's FIRST stop," and immediately glosses it as answering "when does the next bus leave the origin terminal." The FIRST-stop scoping plus the mention of the interval-mode sibling distinguishes it from bus_get_line_realtime and bus_get_line_detail without opening either schema.

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?

Gives clear routing for one case: interval-mode lines without per-trip data should use bus_get_line_detail instead. It also explains the at_time use case ("ask 'what is the next departure after 19:10'"). It does not distinguish itself from bus_get_line_realtime, a sibling that plausibly answers an overlapping question, so the routing is not exhaustive.

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

Deploy Server