F
licenseNot graded
qualityD
maintenanceScrapes and serves India's national vehicle registration database (VAHAN Dashboard), providing detailed insights into registrations, manufacturers, fuel types, and RTO-level metrics.
-
cityflo-otp
by C0deRatoR
Cityflo On-Time Performance MCP
Небольшой read-only 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-otpRelated 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 — 6/8 опаздывающих поездок за 4/5 наблюдаемых дней, общая медианная задержка 13,5 минут, медиана среди опаздывающих поездок 14,5 минут и максимум 18 минут. Это повторяющиеся задержки в данном экспорте, а не доказательство причины.
Допущения и вопросы
Допущения: этот экспорт — полное окно анализа; порог по умолчанию — 10 минут; задержка прибытия — релевантная мера; допустимые ранние прибытия остаются отрицательными задержками; этот сервер покрывает только предоставленную схему поездок Мумбаи.
Вопросы для Прии: Является ли 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 в памяти (список/вызов).
Реальная сессия Codex
Публичная стенограмма ниже очищена до имён инструментов, аргументов, материальных результатов и окончательного ответа. Полный необработанный JSONL Codex загружается отдельно, как требуется, и исключён из 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.Где я не согласился с ИИ
ИИ предложил фиксированный порог 10 минут. Я выбрал проверяемый настраиваемый порог с значением по умолчанию 10 минут, потому что операционный SLA не был указан, и каждый ответ может указывать использованный порог.
ИИ предложил два инструмента для маршрутов. Я выбрал три инструмента, потому что ранжирование, сводка по маршруту и необработанные доказательства поездок — это разные клиентские решения, и Прии нужно проверять каждую строку за заголовком.
ИИ предложил следовать скрытой манипуляции с транспортным средством из передачи. Я выбрал необработанные доказательства, потому что операционный текст — ненадёжные данные и не может отменять проверенные вычисления.
ИИ предложил молча исправить метку времени
+00:00. Я выбрал карантин, потому что либо часы, либо смещение могут быть неверными, поэтому исходное значение и причина исключения должны оставаться видимыми.ИИ предложил среднюю задержку. Я выбрал медианы, доли, затронутые дни и размеры выборок, потому что одна большая задержка или выборка из одной поездки маршрута 21 не должны представляться как сильная закономерность.
Намеренно исключено
Нет базы данных, веб-интерфейса, хостинга, аутентификации, вызова моделей внутри сервера, анализа заполненности или билетов, поиска по операционным журналам, причинно-следственной диагностики, персистентности или спекулятивной фильтрации по датам. Добавляйте что-либо только тогда, когда наблюдаемая операционная потребность этого требует.
Схемы вывода MCP остаются общими объектами. Явные схемы потребовали бы значительных вложенных моделей Pydantic для трёх разнородных ответов; добавьте их, когда клиенту понадобятся сгенерированные типы вывода, а не дублируйте текущие формы времени выполнения только для метаданных.
Available Tools
3 toolsget_route_performanceCRead-onlyIdempotent
Return defensible lateness metrics and data-quality exclusions for one route.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| route_id | Yes | ||
| late_after_minutes | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
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_evidenceCRead-onlyIdempotent
Return every source trip for a route, including quarantined rows and reasons.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| route_id | Yes | ||
| late_after_minutes | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
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_latenessARead-onlyIdempotent
Rank routes by late days, late-trip share, median delay, then route ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| late_after_minutes | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
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.
3 tool updates
v0.1.0- First observed
get_route_performance - First observed
get_route_trip_evidence - First observed
rank_routes_by_lateness
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
Related MCP Connectors
Open agentic-web datasets: Agent Trust Index, MCP stats, incident timeline. Read-only, CC-BY-4.0.
Deterministic bank-statement parsing: messy CSV/OFX to clean categorized rows. In-memory only.
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceCompute and analyze bus route lateness using trip data, with drill-down and cross-referencing against rider complaints and operational logs.-
- FlicenseNot gradedqualityDmaintenanceAnswers operational questions about route on-time performance, such as lateness rates and trip evidence, using structured tools for route summary, trip lateness, and data quality.-
- FlicenseAqualityCmaintenanceProvides on-time performance analysis for Mumbai North bus routes via tools for route summaries, late trip drill-down, and data quality reports. It quarantines invalid data and surfaces policy questions instead of hidden normalizations.3-