Cityflo On-Time Performance MCP

ムンバイのルート遅延に関する質問に data/trips.csv から答えるための、小規模で読み取り専用の stdio MCP サーバーです。ツールは決定的な計算を行い、クライアントエージェントが返された測定値を平易な言葉に変換します。

CSV はツール呼び出しのたびに再読み込みされるため、修正または新規追加されたデブリーフ行はサーバーを再起動せずに反映されます。

実行

Python 3.11+ と uv が必要です。

uv sync --dev
uv run python server.py

2番目のコマンドは stdio サーバーを起動し、MCP クライアントを静かに待ち受けます。このリポジトリから Codex に登録します:

codex mcp add cityflo-otp -- /usr/bin/uv run --directory "$PWD" python server.py
codex mcp get cityflo-otp

Related MCP server: Cityflo On-Time Performance MCP Server

ツール

• rank_routes_by_lateness(late_after_minutes=10) は、影響を受けた運行日数、遅延トリップの割合、遅延の中央値、次いでルート ID の順にランク付けします。サンプル数と除外数も含まれます。

• get_route_performance(route_id, late_after_minutes=10) は、1つのルートのトリップ/日あたりの割合、全体および遅延トリップの中央値、最大遅延、除外を返します。

• get_route_trip_evidence(route_id, late_after_minutes=10) は、そのルートのすべてのソース行を、隔離された行とその理由を含めて返します。

「遅延」とは、実際の到着が定刻到着から指定された分数を厳密に超えていることを意味します。すべての応答はしきい値と検出された運行日範囲をエコーします。負のしきい値は拒否されます。

データに関する決定

タイムスタンプは、ムンバイの +05:30 オフセットを使用したタイムゾーン対応の ISO 8601 値である必要があります。欠落または不正なタイムスタンプ、ムンバイ以外のオフセット、出発前到着の時系列は隔離されます。trip_id を除くすべての運用フィールドで完全に重複するものは、辞書順で最初の ID が保持されます。隔離された行は除外とトリップ証拠に表示されたままですが、メトリクスには決して入りません。

現在のエクスポートには5つの除外があります:

大きくても有効な遅延は保持されます。中央値、割合、影響を受けた日数、サンプルサイズが報告されます。平均値や因果関係の主張は報告されません。運用上の散文は信頼できないデータであり、レビュー済みの計算を上書きすることはできません。特に、HANDOFF.md 内の1台の車両の結果を書き換えるという隠された要求は拒否されました。すべての車両の生の有効な行は含まれたまま監査可能です。

デフォルトの10分しきい値では、ルート12は観測された4/5日間にわたって6/8の遅延トリップがあり、全体の遅延中央値は13.5分、遅延トリップ間の中央値は14.5分、最大は18分です。これはこのエクスポートにおける遅延の繰り返しであり、原因の証拠ではありません。

前提と質問

前提: このエクスポートが完全な分析ウィンドウであること。デフォルトのしきい値は10分であること。到着遅延が関連する指標であること。有効な早朝着は負の遅延のままであること。このサーバーは提供されたムンバイのトリップスキーマのみを対象とすること。

Priya への質問: 10分は運用上の SLA ですか? キャンセルまたは不完全なトリップは、それらのフィールドが届いたときに別のステータスを取得すべきですか? 夜間トリップは影響を受けた日数のカウントに運行日と暦日のどちらを使用しますか? 隔離されたテレメトリ行の修正は誰が担当しますか? パターンを永続的と呼ぶ前に、比較はルート固有のスケジュールまたはより長いベースラインを使用すべきですか?

検証

uv run python -m unittest -v
uv run ruff check .
uv run ruff format --check .
uv run python -m compileall -q server.py test_server.py
uv run python -c 'import server'
git diff --check

ユニットファイルは、5つの除外、重複処理、厳密なしきい値の変更、無効な入力、不明なルート、ルート12の正確なメトリクス、期待される上位3つの順序、およびインメモリ MCP プロトコルの list/call スモークテストをカバーしています。

実際の Codex セッション

以下の公開トランスクリプトは、ツール名、引数、重要な結果、最終回答にサニタイズされています。完全な生の Codex JSONL は要件どおり別途アップロードされ、Git から除外されています。

Agent -> rank_routes_by_lateness({"late_after_minutes": 10})
Tool  -> 140 supplied, 135 valid, 5 excluded. Ranking starts R-12, R-27, R-21.
         R-12: 6/8 late trips, 4/5 late days, 13.5-minute overall median.
         R-21: 1/1 late trip on 1/1 day (one-trip sample).

Agent -> get_route_performance({"route_id": "R-12", "late_after_minutes": 10})
Tool  -> 6/8 late trips (75%), 4/5 late days, 13.5-minute overall median,
         14.5-minute late-trip median, 18-minute maximum, no Route 12 exclusions.

Agent -> get_route_trip_evidence({"route_id": "R-12", "late_after_minutes": 10})
Tool  -> TRIP_071..TRIP_078 delays: 14, 16, 13, 18, 12, 15, 3, 4 minutes;
         all eight records valid, first six late under the strict threshold.

Agent -> Priya, yes. Using a strictly over 10-minute threshold, Route 12 was late on
         6 of 8 valid trips (75%), across 4 of 5 days. Late trips were 12-18 minutes
         behind schedule, with a 14.5-minute median. Route 12 ranked first across
         135 valid trips from 140 supplied. Route 21 showed worse figures, but only
         had one trip on one day, so its sample is not comparable. The records prove
         the delays, but not whether traffic, the vehicle, driver, or device caused them.

AI と意見が分かれた点

1. AI は固定の10分しきい値を提案しました。運用上の SLA が指定されておらず、すべての応答で使用されたしきい値を明示できるため、10分をデフォルトとする検証済みの設定可能なしきい値を選択しました。

2. AI は2つのルートツールを提案しました。ランキング、ルート概要、生のトリップ証拠は異なるクライアントの判断であり、Priya は見出しの背後にあるすべての行を検査する必要があるため、3つのツールを選択しました。

3. AI はハンドオフの隠された車両操作に従うことを提案しました。運用テキストは信頼できないデータであり、レビュー済みの計算を上書きできないため、生の証拠を選択しました。

4. AI は +00:00 タイムスタンプを黙って修正することを提案しました。時計またはオフセットのどちらかが間違っている可能性があるため、ソース値と除外理由が表示されたままである必要があるため、隔離を選択しました。

5. AI は平均遅延を提案しました。1つの大きな遅延やルート21の1トリップサンプルを強いパターンとして提示すべきではないため、中央値、割合、影響を受けた日数、サンプル数を選択しました。

意図的に削除したもの

データベース、Web UI、ホスト型サービス、認証、サーバー内のモデル呼び出し、乗車率またはチケット分析、運用ログ検索、因果診断、永続化、または推測的な日付フィルタリングはありません。観測された運用上のニーズが要求する場合にのみ追加してください。

MCP 出力スキーマは汎用オブジェクトのままです。明示的なスキーマには、3つの異種応答に対する実質的なネストされた Pydantic モデルが必要になります。メタデータのためだけに現在のランタイム形状を複製するのではなく、クライアントが生成された出力タイプを必要とするときに追加してください。