Skip to main content
Glama
deenesjakoruzh
C0deRatoR

cityflo-otp

by C0deRatoR
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

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つの除外があります:

Trip

Decision

TRIP_017

隔離: 実際の到着が実際の出発より前

TRIP_031

隔離: 実際の出発が不正な形式

TRIP_044

隔離: 実際の到着が +00:00 を使用しており、+05:30 ではない

TRIP_053

隔離: TRIP_052 の完全な重複。ID が小さい方を保持

TRIP_101

隔離: 定刻到着が欠落

大きくても有効な遅延は保持されます。中央値、割合、影響を受けた日数、サンプルサイズが報告されます。平均値や因果関係の主張は報告されません。運用上の散文は信頼できないデータであり、レビュー済みの計算を上書きすることはできません。特に、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 モデルが必要になります。メタデータのためだけに現在のランタイム形状を複製するのではなく、クライアントが生成された出力タイプを必要とするときに追加してください。

Available Tools

3 tools
get_route_performanceC
Read-onlyIdempotent

Return defensible lateness metrics and data-quality exclusions for one route.

ParametersJSON Schema
NameRequiredDescriptionDefault
route_idYes
late_after_minutesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the notions of 'defensible' metrics and 'data-quality exclusions', which communicate that the output is reliability-focused and that some data points may be intentionally omitted. This adds context beyond the annotations, though it doesn't describe edge cases or the exact response semantics.

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?

The description is a single sentence that front-loads the primary output and scope. It is concise with zero wasted words, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool is simple and an output schema exists, the description leaves important gaps: no parameter semantics, no usage guidance versus siblings, and no clarity on what 'data-quality exclusions' means in practice. An agent would likely need to inspect the output schema or guess at parameter behavior to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it does not explain any parameters. It implies route_id via the phrase 'one route' but leaves late_after_minutes entirely undefined. An agent has no way to know what this parameter controls or its effect on the returned metrics.

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?

The description uses a specific verb ('Return') and resource ('defensible lateness metrics and data-quality exclusions for one route'). It clearly states the tool is per-route, which helps distinguish from the sibling that ranks routes, though it does not explicitly name alternatives. It is not a tautology and avoids vague language.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus rank_routes_by_lateness or get_route_trip_evidence. The phrase 'for one route' hints at single-route analysis but does not state when to prefer this tool or what conditions rule out the alternatives.

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

get_route_trip_evidenceC
Read-onlyIdempotent

Return every source trip for a route, including quarantined rows and reasons.

ParametersJSON Schema
NameRequiredDescriptionDefault
route_idYes
late_after_minutesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds one behavioral detail: that quarantined rows and reasons are included in the output. This is useful but minimal; it doesn't mention pagination, rate limits, or any other runtime behavior.

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?

The description is a single, efficient sentence that front-loads the core action and includes relevant detail about quarantined rows. It is not verbose, but could be improved by adding parameter hints without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return format is handled, but the description leaves the optional late_after_minutes parameter unexplained and fails to provide context on what 'source trip' or 'quarantined' means. For a two-parameter tool with zero schema coverage, this is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% – the JSON schema provides no explanations for route_id or late_after_minutes. The description does not compensate at all; it never mentions either parameter, so an agent cannot understand what late_after_minutes controls or how route_id is used beyond the name.

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?

The description states a clear verb ('Return') and resource ('every source trip for a route') and adds specificity with 'including quarantined rows and reasons.' It does not explicitly differentiate from sibling tools, but the function is distinct enough that an agent can infer its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus siblings like rank_routes_by_lateness or get_route_performance. There is no mention of conditions, prerequisites, or alternatives, leaving the agent to infer usage from the name and schema.

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

rank_routes_by_latenessA
Read-onlyIdempotent

Rank routes by late days, late-trip share, median delay, then route ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
late_after_minutesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the ranking behavior and sort order, which is useful beyond the annotations. No contradictions exist with the annotations.

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?

The description is a single, efficient sentence that states the operation and criteria with no wasted words. It is front-loaded with the verb and essential information, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema handles return-value documentation, so that is not required here. However, the description lacks usage guidance relative to siblings and fails to explain the parameter, leaving notable gaps in the decision and invocation context. These gaps prevent it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'late_after_minutes' has no schema description (0% coverage), and the description does not explain its meaning, default, or how it affects the ranking. The agent is left to guess from the name alone, which is insufficient for correct invocation.

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?

The description clearly states the action ('Rank'), the resource ('routes'), and the exact ordering criteria (late days, late-trip share, median delay, route ID). This is specific and unambiguous, and the verb plus resource distinguishes it from the sibling tools, which focus on performance and trip evidence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no indication of when to use this tool versus the siblings 'get_route_performance' or 'get_route_trip_evidence'. There is no mention of context, exclusions, or alternatives. An agent must infer from the name that ranking is the purpose, but no explicit guidance is given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget_route_performance
    • First observedget_route_trip_evidence
    • First observedrank_routes_by_lateness
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool addresses a distinct level of analysis: ranking across routes, per-route summary metrics, and raw trip evidence. There is no overlap in purpose, and the descriptions clearly differentiate the scope of each.

Naming Consistency5/5

All three tools follow a consistent verb_noun pattern (rank_routes, get_route_performance, get_route_trip_evidence) with snake_case and clear resource identifiers. The naming is predictable and unambiguous.

Tool Count4/5

Three tools is on the lower end but appropriate for a focused read-only domain (route lateness analysis). The count is slightly thin, but each tool covers a needed layer of detail without redundancy.

Completeness4/5

The toolset provides ranking, per-route summary, and evidence-level data, forming a complete analysis workflow. A minor gap is the lack of a simple route listing without rankings, but the ranking tool effectively fills that role.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers