[P12] Operate a Site Remotely
Summary
The operator checks on a site and acts on it without signing in to it, usually through an AI assistant over MCP: status, version, configuration, recent errors, cache clearing and re-synchronising with EMS. Logs and metrics are already in the observability stack.
Actor & Context
Actor: Operator, through an AI assistant
Frequency: On demand; whenever something looks wrong
Precondition: The site is onboarded
Entry point: An MCP tool in EMS, or the observability dashboards
Main Flow
-
The operator asks for a site’s status; EMS calls the site’s remote-operation interface and returns version, connection health and recent errors.
-
The operator inspects the effective configuration (without secrets).
-
The operator clears the site’s caches or re-synchronises it with EMS.
Alternative Flows
-
AF-1: Site unreachable: EMS reports it, with the last telemetry received.
-
AF-2: Investigating a failure: the operator reads the site’s logs and metrics in the observability stack under the site’s identity, and follows a request’s trace from the site into EMS.
-
AF-3: Debug mode: the operator switches on debug mode for a limited time; every request is sampled and logged in detail until it switches itself off.
Acceptance Criteria
-
Status, configuration, errors, cache clear and re-sync are available remotely (PS-OB-02)
-
Usable over MCP with the operator’s permissions (PS-OB-03)
-
Rejections are recorded with context and without secrets (PS-OB-04)
API Surface
The calls below are named by purpose; their exact form is defined in the public site design.
| Call | Purpose |
|---|---|
Site: status, configuration, errors, cache clear, re-sync |
Authenticated remote operation |
EMS MCP server: site tools |
Operator access |
Design Anchors
-
Public Site Requirements — PS-OB-01 to 11