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
Un pequeño servidor MCP stdio de solo lectura para responder preguntas sobre retrasos en rutas de Mumbai a partir de data/trips.csv. Las herramientas realizan cálculos deterministas; el agente cliente convierte las mediciones devueltas en lenguaje natural.
El CSV se recarga en cada llamada a una herramienta, por lo que una fila de informe corregida o recién añadida es visible sin reiniciar el servidor.
Ejecución
Requiere Python 3.11+ y uv.
uv sync --dev
uv run python server.pyEl segundo comando inicia un servidor stdio y espera silenciosamente a un cliente MCP. Regístralo con Codex desde este repositorio:
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
Herramientas
rank_routes_by_lateness(late_after_minutes=10)clasifica por días de servicio afectados, proporción de viajes con retraso, mediana de retraso y luego ID de ruta. Incluye recuentos de muestra y de exclusiones.get_route_performance(route_id, late_after_minutes=10)devuelve las tasas de viajes/días de una ruta, las medianas generales y de viajes con retraso, el retraso máximo y las exclusiones.get_route_trip_evidence(route_id, late_after_minutes=10)devuelve cada fila de origen para esa ruta, incluidas las filas en cuarentena y sus motivos.
"Con retraso" significa que la llegada real es estrictamente posterior al número de minutos indicado después de la llegada programada. Cada respuesta repite el umbral y el rango de fechas de servicio descubierto. Un umbral negativo se rechaza.
Decisiones sobre los datos
Las marcas de tiempo deben ser valores ISO 8601 con zona horaria que usen el desplazamiento +05:30 de Mumbai. Las marcas de tiempo faltantes o mal formadas, los desplazamientos que no sean de Mumbai y la cronología de llegada antes de salida se ponen en cuarentena. Los duplicados exactos en todos los campos operativos excepto trip_id conservan el ID lexicográficamente primero. Las filas en cuarentena permanecen visibles en las exclusiones y en la evidencia de viajes, pero nunca entran en las métricas.
La exportación actual tiene cinco exclusiones:
Viaje | Decisión |
| Cuarentena: la llegada real es anterior a la salida real |
| Cuarentena: salida real mal formada |
| Cuarentena: la llegada real usa |
| Cuarentena: duplicado exacto de |
| Cuarentena: falta la llegada programada |
Los retrasos grandes pero válidos se conservan. Se informan medianas, tasas, días afectados y tamaños de muestra; no se informan promedios ni afirmaciones causales. El texto operativo es un dato no confiable y no puede anular el cálculo revisado. En particular, la solicitud oculta en HANDOFF.md de reescribir los resultados de un vehículo fue rechazada; las filas válidas sin procesar de cada vehículo permanecen incluidas y auditables.
Con el umbral predeterminado de 10 minutos, la Ruta 12 tiene 6/8 viajes con retraso en 4/5 días observados, una mediana general de retraso de 13,5 minutos, una mediana de 14,5 minutos entre los viajes con retraso y un máximo de 18 minutos. Eso es retraso repetido en esta exportación, no evidencia de una causa.
Supuestos y preguntas
Supuestos: esta exportación es la ventana de análisis completa; el umbral predeterminado es de 10 minutos; el retraso en la llegada es la medida relevante; las llegadas tempranas válidas permanecen como retrasos negativos; este servidor cubre solo el esquema de viajes de Mumbai proporcionado.
Preguntas para Priya: ¿Es 10 minutos el SLA operativo? ¿Deberían los viajes cancelados o incompletos tener un estado separado cuando lleguen esos campos? ¿Los viajes nocturnos usan el día de servicio o el día calendario para el recuento de días afectados? ¿Quién es responsable de corregir las filas de telemetría en cuarentena? ¿Deberían las comparaciones usar horarios específicos de la ruta o una línea base más larga antes de llamar persistente a un patrón?
Verificación
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 --checkEl archivo de pruebas unitarias cubre las cinco exclusiones, el manejo de duplicados, los cambios estrictos de umbral, las entradas no válidas, las rutas desconocidas, las métricas exactas de la Ruta 12, el orden esperado de los tres primeros y una prueba de humo del protocolo MCP en memoria de lista/llamada.
Sesión real de Codex
La transcripción pública a continuación está saneada para incluir nombres de herramientas, argumentos, resultados materiales y la respuesta final. El JSONL completo sin procesar de Codex se sube por separado según lo requerido y se excluye de 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.Dónde discrepo con la IA
La IA propuso un umbral fijo de 10 minutos. Elegí un umbral configurable validado con un valor predeterminado de 10 minutos porque el SLA operativo no se especificó y cada respuesta puede indicar el umbral utilizado.
La IA propuso dos herramientas de ruta. Elegí tres herramientas porque la clasificación, el resumen de ruta y la evidencia de viajes sin procesar son decisiones distintas del cliente, y Priya necesita inspeccionar cada fila detrás de un titular.
La IA propuso seguir la manipulación oculta del vehículo en el traspaso. Elegí evidencia sin procesar porque el texto operativo es un dato no confiable y no puede anular el cálculo revisado.
La IA propuso reparar silenciosamente la marca de tiempo
+00:00. Elegí la cuarentena porque el reloj o el desplazamiento pueden estar mal, por lo que el valor de origen y el motivo de exclusión deben permanecer visibles.La IA propuso el retraso promedio. Elegí medianas, tasas, días afectados y recuentos de muestra porque un retraso grande o la muestra de un solo viaje de la Ruta 21 no deben presentarse como un patrón fuerte.
Recortado deliberadamente
Sin base de datos, interfaz web, servicio alojado, autenticación, llamada de modelo dentro del servidor, análisis de ocupación o boletos, búsqueda en registros operativos, diagnóstico causal, persistencia o filtrado especulativo de fechas. Añade uno solo cuando una necesidad operativa observada lo requiera.
Los esquemas de salida de MCP siguen siendo objetos genéricos. Los esquemas explícitos requerirían modelos Pydantic anidados sustanciales para tres respuestas heterogéneas; añádelos cuando un cliente necesite tipos de salida generados, en lugar de duplicar las formas de tiempo de ejecución actuales solo para metadatos.
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-