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
Section titled “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
Section titled “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 at the default
read_onlytier. A reviewed session can opt into--max-tool-tier write; beta.5 also defines a separatedestructivetier. - Every tier still operates inside the normal LyftData permission model.
Live state and operator visibility
Section titled “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
Section titled “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-tier session used only when an operator wants help making a reviewed 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.