AI
LyftData can work with desktop assistants and managed AI clients through the Model Context Protocol (MCP). This is part of the normal LyftData client experience, not a separate server-side AI product: you run an MCP server locally with lyftdata mcp-server, your assistant connects to that local process, and the client talks to the LyftData server you already use.
What you can do with AI in LyftData
- Monitor a live environment and summarize warnings, recent notifications, or worker health.
- Troubleshoot a slowdown or failed rollout by inspecting traces, logs, deployment state, and recent events.
- Author or review job definitions with the assistant grounded in the current LyftData surface.
- Keep separate assistant sessions for different environments or duties, such as production monitoring versus non-production authoring.
Trust, permissions, and writes
LyftData does not create a parallel security system for AI access. MCP sessions reuse the same server URL, login state, and permissions you already use elsewhere in LyftData.
- The default posture is read-first.
- Mutating tools stay unavailable unless you start the MCP server with
--allow-write. - Even in write-enabled mode, the session still operates inside the normal LyftData permission model.
Live state and operator visibility
Assistants can consume recent notifications and (where supported) websocket-backed updates for live signals. Operator visibility into assistant tool activity is also available, but the current behavior matters: activity forwarding is opt-in, metadata-only, and best-effort. It appears only when the MCP server is started with --activity-forward, and it is designed as a review aid rather than a permanent full transcript.
How teams usually use it
Most teams end up with more than one assistant session:
- A read-only session that watches a production environment and answers operational questions.
- A separate session for authoring and testing against a safer environment.
- A tightly controlled write-enabled session used only when an operator wants help making a real change.
This separation is simple because the MCP server is part of the client: you can point different sessions at different LyftData servers, credentials, or profiles without inventing a second control plane.