Query China’s realtime bus and metro data, including arrivals, vehicle positions, stops, schedules, and transit routes.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent — or use 1-click editor setup below.
This server is confirmed live — we successfully called its tools/list endpoint directly (see the verified badge above). We haven't yet sandbox-tested the stdio install command below specifically, which is a separate, ongoing check.
💡 Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Inspect callable tools, capabilities, and parameters exposed to AI agents by Chelaile MCP.
bus_list_citiesList cities supported by the realtime bus data service. Args: - hot_only (boolean, default true): return only the upstream's curated 'hot' set (~20 cities). Set false to dump the full ~480-city list (token-heavy, use sparingly). - response_format ('markdown' | 'json'): defaults to 'markdown' Returns (json): { "cities": [ { "cityId": "034", "cityName": "上海", "pinyin": "ShangHai", "supportSubway": true, "hot": true }, ... ] } Use when: the user mentions a city name and you don't have its ID. The hot set covers the top-tier cities the user almost certainly means.
bus_get_city_configGet a city's runtime config: max poll interval and "arriving" time threshold. This is mostly relevant if you are deciding how aggressively to refresh — not for end-user questions about lines or stops. Args: - city_id (string, required): e.g. '034' (Shanghai), '027' (Beijing) - response_format ('markdown' | 'json') Returns (json): { "maxInterval": 30, "arrivingStationLimitSeconds": 180, "busDisplayConfig": { "lineDetail": "time#order#distance", "other": "time#order" } }
bus_reverse_geocodeConvert WGS-84 lat/lng to a Chinese postal address (province, city, district, township, formatted address). Useful when you have raw GPS coordinates and need a human-readable place name, or the citycode/adcode to pass to other tools. Args: - lat (string, required): WGS-84 latitude, decimal, e.g. '31.230416' - lng (string, required): WGS-84 longitude, decimal, e.g. '121.473701' - response_format ('markdown' | 'json') Returns (json): { "formatted": "上海市黄浦区...", "province": "上海市", "city": "上海市", "district": "黄浦区", "township": "南京东路街道", "citycode": "021", "adcode": "310101" } For municipalities (Shanghai/Beijing/Tianjin/Chongqing) the upstream emits an empty 'city' value; this tool back-fills it with 'province' so the field is always a usable string.
bus_get_my_locationResolve the caller's approximate location from their public IP — useful when the user asks something like "what's near me" without providing coordinates. **Precision is city-level (typically a few kilometres).** Good enough to identify the city and seed bus_get_nearby_stops with a starting guess. NOT precise enough to find the user's actual bus stop — for that, ask for a landmark/address and resolve it via bus_search. Caveats: - Resolves via ip-api.com (free tier; rate-limited but no auth). - VPN / corporate proxy → result reflects the proxy exit IP, not the user. - Cellular IPs often land on a provincial centroid. Args: - ip (string, optional): a specific IPv4/IPv6 to look up. Omit to use the mcp server process's own outbound IP (= the caller's machine when running locally). - response_format ('markdown' | 'json') Returns (json): { "lat": 31.2222, "lng": 121.4581, "gpsType": "wgs", "city": "上海", "region": "上海市", "country": "中国", "ip": "116.236.0.1", "isp": "China Telecom", "precision": "city-level (~10 km); not suitable for stop-level queries" } **Suggested workflow**: 1. Call this tool to identify the user's city (match 'city' field against bus_list_cities to get a cityId). 2. Pass lat/lng into bus_get_nearby_stops for a rough nearby list, OR ask the user to confirm a landmark and use bus_search.pois for sharper coordinates.
bus_searchSearch inside a city by keyword. Returns matching lines, stations, and POIs in one call. Use this as the primary entry point when the user gives a line number, station name, or destination name without IDs. **Keyword tip**: plain "71", "71路", "地铁2号线", "陆家嘴" all work — the upstream is reasonably forgiving. If a short numeric returns empty, try appending "路". **Coordinate systems**: - 'pois' coords are GCJ-02 (use directly with bus_plan_transit) - 'stations' coords are WGS-84 (use with bus_get_nearby_stops / bus_get_line_realtime) Both are also marked with a 'gpsType' field. Args: - city_id (string, required): e.g. '034' - keyword (string, required) - response_format ('markdown' | 'json') Returns (json): { "highlightKey": "71路", "lines": [ { "name": "71", "lineNo": "r95817", "isSubway": false, "directions": [ { "direction": 0, "lineId": "21283603183", "startSn": "延安东路外滩", "endSn": "申昆路枢纽站" }, { "direction": 1, "lineId": "21283603182", "startSn": "申昆路枢纽站", "endSn": "延安东路外滩" } ], // Compat top-level fields mirror directions[0] (or first available). "lineId": "21283603183", "direction": 0, "startSn": "延安东路外滩", "endSn": "申昆路枢纽站" }, ... ], "stations": [{ "sId":"...", "sn":"西藏中路", "lat":31.231006, "lng":121.474316, "gpsType":"wgs", "physicalStId":"...", "namesakeStId":"...", "isSubway":false }, ...], "pois": [{ "name":"71路", "address":"...", "tag":"公交线路", "district":"黄浦区", "lat":31.233021, "lng":121.49073, "gpsType":"gcj" }, ...] } **Line folding**: each entry in 'lines' is one logical line (e.g. "71路"). The two travel directions live in 'directions[]'. Pick the lineId matching your desired direction. **Subway hint**: when 'isSubway' is true, the entry carries a 'hint' field — bus_get_line_detail will return empty for these lineIds. Use bus_get_stop_detail (metros field) or bus_plan_transit instead. **Follow-ups**: - directions[i].lineId → bus_get_line_detail (full stop list, first/last/price) — non-subway only - stations[*].physicalStId + namesakeStId → bus_get_stop_detail (NOTE: a few stations lack physicalStId — typically metro-only entries with subwayV2=1. For those, use bus_get_nearby_stops to resolve the bus platform IDs nearby.) - pois[*].lat/lng (GCJ) → bus_plan_transit as origin/destination
bus_search_morePaginated 'see more' for one category from bus_search. Args: - city_id (string, required) - keyword (string, required): same keyword used in bus_search - type ('1'|'2'|'3'): 1=more lines, 2=more stations, 3=more POIs (default '1') - response_format ('markdown' | 'json') Returns: same shape as bus_search but only the requested category is populated.
PeanutSplash/chelaile-mcp MCP server connects an MCP client to Chelaile transit data for cities in China. It covers both bus and metro use cases, including supported-city discovery, line and station search, nearby stop lookup, vehicle positions, arrival estimates, line schedules, and public-transit route planning.
The tool set supports several common workflows:
No login, account, or credential configuration is required according to the project documentation.
Start with bus_list_cities when the city ID is unknown. bus_search then resolves a line number, station, or destination into internal line and stop identifiers. Those identifiers feed into detail and realtime tools such as bus_get_line_detail, bus_get_stop_detail, and bus_get_line_realtime.
Location handling needs attention. bus_reverse_geocode accepts WGS-84 coordinates and returns a Chinese address plus city and administrative codes. bus_get_nearby_stops also expects WGS-84. bus_plan_transit instead expects GCJ-02 coordinates, which can be obtained from the POIs returned by bus_search. IP-based location from bus_get_my_location is only city-level and is not precise enough to identify an actual bus stop.
Every tool accepts response_format as markdown or json; markdown is the default. JSON is the useful choice when an agent needs coordinates, identifiers, vehicle arrays, or structured route segments.
Run the published npm package with npx:
The README documents configurations for Claude Desktop and Cursor, and also provides a Claude Code command. For Claude Desktop, add the command and package as a server entry, then restart the client. The project’s examples use the server name chelaile.
PeanutSplash/chelaile-mcp MCP server has no documented environment variables or API key settings. Its IP-location feature calls the free tier of ip-api.com, which may be rate-limited. VPNs, proxies, and some cellular networks can reduce location accuracy.
The available capabilities include:
bus_get_line_detail is the preferred source for first and last service times and live vehicles. Subway results from bus_search should be handled through nearby-stop or transit-planning tools rather than the bus line-detail endpoint.
Realtime values come from the upstream service and can be missing or unknown. In particular, bus_get_line_realtime normally provides an ETA only for the nearest bus heading toward the selected stop; farther vehicles may have positions but no ETA. bus_list_line_buses is intended for imminent arrivals and may return only one or two vehicles, while line detail provides the broader live roster.
The timetable endpoint often returns a fixed interval instead of individual departures, especially for Shanghai lines. Route geometry is for map drawing and may omit a terminal stop, so the authoritative ordered stop list comes from line detail. The full city list is large and token-heavy, making the default hot-city list preferable unless a complete list is needed.
PeanutSplash/chelaile-mcp MCP server is licensed under MIT. Its transit coverage and data freshness depend on the upstream Chelaile service, and the supplied material does not specify a guaranteed availability level.
Factual signals from GitHub, npm, and our automated checks — not a rating.
No reviews yet — be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/peanutsplash-chelaile-mcp)<a href="https://allmcps.com/mcp/peanutsplash-chelaile-mcp"><img src="https://allmcps.com/api/badge/peanutsplash-chelaile-mcp?style=directory" alt="Chelaile MCP on AllMCPs" /></a>