[Journey] [Iteration 1] Incident Resolvement

## Epic

#6385

## Description

### Supporting usecases
- **Streamline downtime documentation:** Whenever an alarm occurs, the system prompts the operator to log the reason in natural language. The AI then automatically ties in the relevant timestamped data—like sensor readings and recent events—creating a comprehensive incident report. This makes it easy for operators to document issues thoroughly and ensures consistent, data-rich records for the maintenance team—enhancing both accountability and clarity.
- **Remote expert troubleshooting:** When an alarm is triggered, a maintenance expert receives a text alert and can reply with a simple query, like asking for the status of a specific sensor. The AI then instantly retrieves and reports the real-time data from that sensor, providing the expert with immediate insights. This allows knowledgeable personnel to remotely diagnose issues and guide on-site staff quickly and accurately, combining human expertise with AI-driven real-time data retrieval.

### Overview

Overview of the workflow we want to support by adding this MCP functionality:

### User journey

What this comes down to from an operators perspective is (in order):

1. `Operator` receives `alert` requiring investigation
1. [Optional] `Operator` configures `AI agent (FlowFuse expert)` configuration to use `MCP-server` dedicated to impacted machine/PLC
1. `Operator` prompts `AI agent (FlowFuse expert)` in an `environment natural to operators`
1. `AI agent (FlowFuse expert)` requests and receives required data from `MCP-server`
- Timeseries-sensor-data (temperatures, pressure, etc)
- Timeseries-metrics (e.a. OEE KPIs)
- Tribal knowledge (previous incident-reports, P&IDs, alarm-lists)
1. `AI agent (FlowFuse expert)` reports on `raw data` or even synthesises an `incident report` based on `Operator` original request-prompt
1. `Operator` enables taking corrective action

### Learnings

- Incident reports contain:
- Timeline ("Start time" and "end time")
- Definition of what happened (Tank was full and not emptying, leading to overflow)
- Corrective action (How to fix the problem/next steps: do something different/make software change/make hardware change).
- Root cause analysis (Often defined as TBD, as this is often defined after taking corrective action. Intermediate state is fine)
- The right paradigm to couple a MCP to would be a single machine in a factory. This fits the expected mental model and keeps research and subsequent incident reports tied to the right primitive from an operators perspective. We can expect MCPs to be defined this way for our ICP and design with that in mind.
- This means that if MCP selection is necessary for the FlowFuse expert to work well with MCPs, a selection per machine thus per MCP, rather than per tool will likely make the most sense.

### Which customers would this be available to

FlowFuse cloud users using hosted Node-RED instances