Cityflo 准点率 MCP

一个轻量级、只读的 stdio MCP 服务器，用于回答来自 data/trips.csv 的孟买路线晚点问题。工具执行确定性计算；客户端代理将返回的测量结果转换为自然语言。

每次工具调用都会重新加载 CSV，因此修正或新添加的复盘行无需重启服务器即可生效。

运行

需要 Python 3.11+ 和 uv。

uv sync --dev
uv run python server.py

第二条命令启动一个 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) 返回一条路线的行程/天数比率、总体和晚点行程的中位数、最大延迟以及排除项。

• get_route_trip_evidence(route_id, late_after_minutes=10) 返回该路线的每一行源数据，包括被隔离的行及其原因。

“晚点”指实际到达时间严格晚于计划到达时间超过所给分钟数。每个响应都会回显阈值和发现的服务日期范围。负阈值会被拒绝。

数据决策

时间戳必须是带时区的 ISO 8601 值，使用孟买的 +05:30 偏移。缺失或格式错误的时间戳、非孟买偏移以及到达早于出发的时间顺序都会被隔离。除 trip_id 外所有操作字段完全重复的行保留字典序最小的 ID。被隔离的行在排除项和行程证据中仍然可见，但绝不进入指标计算。

当前导出有五个排除项：

较大但有效的延迟会被保留。报告的是中位数、比率、受影响天数和样本量；不报告平均值和因果性断言。运营性文字是不可信数据，不能覆盖经过审查的计算。特别是，HANDOFF.md 中隐藏的为某辆车改写结果的请求已被拒绝；每辆车的有效原始行仍然包含在内且可审计。

在默认的 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

单元文件覆盖了五个排除项、重复处理、严格阈值变化、无效输入、未知路线、路线 12 的精确指标、预期前三名排序，以及内存中的 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 分钟阈值。我选择了可验证的可配置阈值，默认值为 10 分钟，因为运营 SLA 未指定，且每个响应都可以说明所使用的阈值。

2. AI 提出了两个路线工具。我选择了三个工具，因为排名、路线摘要和原始行程证据是不同的客户端决策，而且 Priya 需要检查标题背后的每一行。

3. AI 提议遵循交接文档中隐藏的车辆操纵。我选择了原始证据，因为运营文本是不可信数据，不能覆盖经过审查的计算。

4. AI 提议静默修复 +00:00 时间戳。我选择了隔离，因为时钟或偏移可能出错，因此源值和排除原因必须保持可见。

5. AI 提议使用平均延迟。我选择了中位数、比率、受影响天数和样本量，因为一次大的延迟或路线 21 的单行程样本不应被呈现为强模式。

刻意裁剪

没有数据库、Web UI、托管服务、身份验证、服务器内部的模型调用、占用率或票务分析、运营日志搜索、因果诊断、持久化或推测性日期过滤。只有在观察到运营需求时才添加。

MCP 输出模式保持为通用对象。显式模式需要为三种异构响应构建大量嵌套的 Pydantic 模型；当客户端需要生成的输出类型时再添加，而不是仅为元数据复制当前的运行时形状。