General Bikeshare Feed Specification (GBFS) information provider. Level 3 server with vehicle type information and multi-system comparison support. Caches MobilityData's systems.csv at startup and allows querying world-wide GBFS systems by system_id.
Server defines 8 tools with complete JSON Schema input definitions and descriptions. All tools follow verb_noun naming convention (get_*, find_*, list_*, compare_*). Descriptions are present and moderately detailed (averaging ~120 chars, within production range). However, output schemas are NOT documented, the tool descriptions state what they 'return' in natural language but provide no structured output schema definition. This is a critical gap for LLM composition: agents cannot predict response structure to plan downstream calls. Parameter descriptions are concrete (e.g., 'ISO 2 文字の国コード'), but several lack explicit format/constraint documentation. Error handling is minimal, no recovery guidance is included in responses. The codebase shows thoughtful implementation (Haversine distance, caching, language selection in GBFS autodiscovery), but the MCP surface omits output schemas entirely.
複数の GBFS システムを横断比較する。各システムの基本情報・ステーション数・車種・リアルタイム在庫状況を並べて返す。
指定した緯度・経度から近い順にステーション一覧を返す。静的情報とリアルタイム在庫を結合し、距離(km)付きで返す。
全ステーションの静的情報(名称・位置・収容台数など)を取得する。ステーション ID をキーとした辞書形式で返す。
全ステーションのリアルタイム在庫情報を取得する。利用可能な自転車台数・空きドック数・稼働状態などを返す。
システム障害・メンテナンス情報を取得する。GBFS フィードに system_alerts が存在しない場合はその旨を返す。
バイクシェアシステムの基本情報を取得する。システム名・オペレーター・サービスエリア・言語・タイムゾーンなどを返す。
MobilityData の systems.csv から利用可能な世界中の GBFS システム一覧を返す。国コード・都市名・システム名でフィルタリング可能(オプション)。返す情報: system_id, name, location, country_code, url。
Output schemas not documented. Tool descriptions state what is returned in prose (e.g., 'returns system_id, name, location, country_code, url') but no structured JSON Schema is provided for responses. This prevents LLMs from understanding response structure for composition and increases hallucination risk.
No error handling or recovery guidance. Tools can fail (network timeout, invalid system_id, GBFS feed missing fields) but no error responses document what went wrong or what the LLM should do next. Example: 'system_id not found, try get_systems() first' would guide recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
バイクシェアシステムで利用可能な車種情報を取得する。vehicle_type_id・名称・形状(bicycle/scooter 等)・推進方式(human/electric 等)・最大航続距離を返す。フィードが存在しないシステムはその旨を返す。
Numeric parameters lack explicit bounds. 'limit' defaults to 5 or 50 but no min/max specified. LLMs may pass unrealistic values (limit=999999) causing API overload or context window exhaustion.
Parameter 'system_id' with fallback to 'gbfs_url' overloads one parameter with two purposes. Description acknowledges backward compatibility ('system_id が見つからない場合は gbfs_url として直接解釈される') but does not clarify when an agent should pass a raw URL vs. a canonical system ID. This ambiguity can cause incorrect tool invocation.
Missing pagination guidance for potentially large results. 'get_station_info' and 'get_station_status' fetch ALL stations without documented limits. A city with 500 stations could return massive responses, exceeding context windows. No offset/limit/next_cursor pattern documented.