Inspiration
On a large urban rail network, each line has its own control centre. An Integrated Control Centre (ICC) adds a network-wide view so teams can coordinate disruptions that cross lines and transport modes.
During an incident, an operator must check many sources at once: alarms, train movements, delays, passenger queues, power, available driver capacity, network connections, and the right procedure. The operator may also need to ask other teams for missing information. Finding and checking all of this takes time, and the difficulty depends partly on the operator's experience.
What Paris ICC does
Paris ICC is a complete, runnable railway decision-support application for the 21-line Paris Metro and RER network. It turns the operational web page into a shared workspace for a human operator and an AI agent.
The application supports an end-to-end workflow:
monitor the network through an interactive map with semantic zoom; locate simulated trains, delays, incidents, and affected areas; rank active incidents by their current passenger-queue impact; inspect one coded incident and retrieve its matching procedure; review evidence, expected effects, duration, and operator checks; approve procedure steps one by one; record every approved action and receipt in a persistent operations log; configure the agent's analysis focus for nine incident types; and prepare an editable end-of-shift report from the complete persisted log.
Paris ICC also includes passenger flow, procedures, delays and regulation, traction power, SCADA, bus replacement services, rolling stock, D-1 schedules and drivers, an operations log, and simulation data views. It is a coherent operational product, not a standalone tool-call screen.
Why WebMCP is essential
Without contextual decision support, the operator has to move between alarm screens, operational views, procedures, staff information, and conversations with other teams before deciding what to do. An experienced operator may know where to look first; a less experienced operator may need more time to assemble the same picture.
With WebMCP, the agent can read the current, carefully limited context exposed by the page. It brings the relevant facts together, finds the matching procedure, and proposes grounded next steps inside the incident workflow. This can reduce the time spent searching and cross-checking, while the operator still reviews the evidence and makes the decision.
The page publishes 21 typed WebMCP tools:
13 read-only tools for current operational and procedural evidence; 2 non-committing analysis/staging tools; and 6 guarded operational actions that affect only the simulation.
For an incident decision, the server-hosted OpenAI agent must follow this exact read-only WebMCP chain:
inspect_incident_decision_context search_operational_procedures get_operational_procedure
The server validates each call and forces the final recommendation into a strict structured schema. The model may cite only step IDs from the exact retrieved document. The evidence view keeps the incident code, decision revision, procedure revision, SHA-256 integrity hash, and cited steps visible to the operator.
The result is more than an assistant beside a dashboard: the human and agent work from the same application state and the same versioned evidence.
Human authority and safety boundaries
The agent finds and explains. The procedure defines. The operator decides.
The model never receives the procedure-application tool during incident analysis. When the operator selects an executable step, the page builds one exact request and displays a visible, one-use confirmation. Before accepting it, the application rechecks:
the current incident and decision revision; the procedure ID, revision, and content hash; the cited step and its mapped capability; that the incident remains active; that the target is the local simulation; and that the request has not become stale, duplicated, or invalid.
A successful action creates a receipt, advances the applicable revision, and appears in the persistent shift log. A stale recommendation cannot silently change a newer situation.
How we used AI
The OpenAI Responses API powers the constrained incident-decision agent, passenger-impact explanations, procedure-editor feedback, and the editable end-of-shift report. Agent instructions can be configured for nine incident types, but they cannot override verified evidence, the retrieved procedure, the structured output contract, or human approval.
The application also has a deterministic procedure-based fallback. If model analysis is unavailable, it still performs the same inspect, search, and retrieve flow and proposes only unfinished mandatory steps from that document.
OpenAI text-to-speech was used for the disclosed English narration in the demo video.
How we built it
The browser application uses React, TypeScript, Vite, SVG, and the browser WebMCP API. The page registers tools with document.modelContext.registerTool(...) for native discovery. A clearly labelled in-page compatibility bridge uses the same definitions, schemas, validation, and approval path when native browser support is unavailable.
An authenticated Node service owns mutable simulation state, the server-authoritative clock, agent calls, and session boundaries. Embedded SQLite persists operational snapshots, events, idempotent command receipts, procedure execution progress, the shift log, and the report. An optional IDFM PRIM connector supplies read-only passenger-information evidence and never sends railway commands.
Codex was used as an implementation and verification partner: refining scope, designing typed WebMCP contracts, implementing and debugging the React and Node application, hardening authorization and revision guards, expanding automated tests, checking browser behaviour, documenting boundaries, and preparing the demonstration.
Challenges
The hardest challenge was enabling useful agent action without confusing recommendation with authorization. A user-supplied confirm: true would not be meaningful, so approval is held outside tool input, shown visibly, bound to frozen arguments, and consumed once.
A second challenge was grounding recommendations in a changing operational state. Paris ICC binds the incident revision to an immutable procedure identity and content hash, then refreshes evidence after each approved step.
A third challenge was presenting a dense 21-line railway network without losing context. Semantic zoom keeps the overview calm, then reveals missions, trains, delays, passengers, provenance, and decision detail as the operator investigates.
Accomplishments
A complete incident-to-recovery-and-handover product workflow. 21 real, typed page tools instead of a single generic agent endpoint. A multi-call, procedure-grounded evidence chain. Passenger-impact prioritisation from the current page state. Visible human approval and revision-bound simulated actions. Persistent receipts, operations history, and shift reporting. A native 21-line network schematic with 390 canonical stations and 467 physical interstations. Reproducible unit, integration, browser, native WebMCP, build, and deployment checks. Honest separation between simulated operational data and optional read-only passenger information.
What we learned
WebMCP is especially valuable when a page contains changing, structured context and actions whose consequences must remain visible. Agent-native does not have to mean agent-autonomous. Typed tools let the model handle information-heavy analysis while the application keeps authority, evidence, and safety boundaries understandable to the person responsible.
Potential impact
The target users are traffic controllers and network supervisors coordinating incidents across Metro and RER lines. Paris ICC helps them understand a disruption, focus on the incident with the greatest current passenger impact, follow a traceable procedure, and preserve a clear handover record.
The product is designed to support, not replace, operators with different levels of experience. It can reduce the time spent looking for information and checking it across several systems, while procedures and human judgement remain authoritative.
For passengers, better-informed coordination can support more regular service, clearer incident handling, and less crowding.
Although demonstrated on the Paris Metro and RER, the approach is designed to be transferable to other rail networks and multimodal transport systems in major metropolitan areas. Each deployment can connect its own network topology, supervision data, incident codes, operating procedures, roles, and authorization rules while retaining the same WebMCP-based human-agent decision loop, traceability, and human approval model.
Beyond transport, this approach could also be explored for browser-based industrial HMI and SCADA systems used in energy sites, factories, water networks, and other infrastructure. If those pages expose carefully limited WebMCP tools, an agent could help operators bring together alarms and context, find the relevant procedure, explain possible next steps, and prepare a traceable incident record. Any real use would require integration with each site's systems, strong cybersecurity, authorized procedures, and independent safety validation. Paris ICC only demonstrates this decision-support approach in a rail simulation.
Paris ICC could also support the training of new operators. In the simulator, trainees could practise incident scenarios without affecting a real network. The agent could review the actions taken during an exercise, point out missed checks or topics that need more practice, and suggest areas for improvement. This feedback would support the instructor and would not replace the instructor's assessment.
Testing and evidence
The public repository includes the complete source, MIT license, architecture, operational boundaries, test suites, browser validators, and reproducible WebMCP validation commands.
To test the main flow:
Open the live application and use the access code supplied privately in the judge-only Devpost field. Zoom the network overview to inspect trains and select an incident. Open Passenger flow to see active incidents ranked by waiting-passenger impact. Open the highest-ranked incident and observe the three-call WebMCP procedure chain. Review the procedure revision, integrity hash, cited evidence, and operator checks. Select an executable step and inspect its one-use approval request. Approve it to create a simulation receipt and shift-log entry. Open Configuration to inspect the nine incident-specific instruction profiles. Draft the end-of-shift report from the persisted operations log.
Limits and responsible-use statement
Simulated environment — no real railway system connected.
Paris ICC is not a safety-certified signalling or railway-control product. The bundled procedures are synthetic project documents, not official RATP or IDFM instructions. All train movements, incidents, passenger queues, crews, power state, and operational actions shown in the demonstration are simulated.
A real deployment would require authorised controlled procedures, organisational access controls, approved system integrations, independent safety review, and a certified audit environment. Third-party map artwork, public data, names, and trademarks are documented separately and are not relicensed under the project's MIT license.
Links
Live application: https://icc-webmcp-demo.hackinvent.com/ Public source: https://github.com/HackInvent/icc-webmcp-demo Demo video: https://www.youtube.com/watch?v=WfHbRbEwiow
Built With
- chromium
- node.js
- openai-responses-api
- react
- sqlite
- typescript
- vite
- vitest
- webmcp