Examples and Workflows

This page focuses on tool sequences rather than prompt phrasing. The MCP surface is most useful when the client chains a small number of LyftData tools against the correct environment.

Read-only inventory patterns

Goal	Tool sequence	Result
List configured jobs	jobs_list -> job_show_rendered	Inventory the job set and inspect rendered job definitions
Find where a job runs	workers_with_job -> worker_connectivity_status_get	Identify attached workers and current connectivity
Inspect recent runtime evidence	workers_logs_recent -> job_notifications_recent	Pull logs and notification summaries without mutating anything
Check MCP process health	mcp_server_metrics	Confirm transport, write mode, timeout counts, and concurrency counters

Rollout or slowdown investigation

Use a read-only session for the entire sequence:

1. Call deployments_list or deployment_get to identify the deployment under discussion.
2. Call deployment_status_get for current desired vs observed state.
3. Call deployment_diff_since_last_apply to see what changed recently.
4. Call deployment_signals_list and deployment_lifecycle_warnings_get for current warnings and signal state.
5. Call workers_logs_recent and job_notifications_recent for recent evidence.
6. If the question is “did the slowdown start with the latest release?”, call job_slowdown_release_correlation.

This sequence avoids mutation while still grounding the answer in deployment state, worker evidence, and notification history.

Job authoring sequence

Run this against a non-production environment or an isolated authoring profile:

1. Use spec_search and spec_item_get to inspect the current DSL surface.
2. Use job_template_list and job_template_get to find a starting template.
3. Use job_auto_detect, job_auto_detect_sample, or job_auto_detect_file when the first draft should be inferred from sample data.
4. Use job_yaml_preview to render the draft output.
5. Use job_lint to validate the job before any staging or deployment step.
6. Use job_show_rendered to inspect the final rendered configuration the server will evaluate.

Controlled write sequence

Split analysis and mutation into separate processes:

1. In a read-only session, inspect the target with job_show_rendered, deployment_status_get, and any relevant notification or log tools.
2. In a separate --allow-write session, perform the approved mutation with the narrowest tool possible, such as job_stage, job_deploy, deployment_action_enqueue, or deployment_apply_with_refresh.
3. Re-run deployment_status_get, deployment_signals_list, and job_notifications_recent immediately after the change.
4. If activity forwarding is enabled, use the UI activity feed to review the recent tool metadata for that write-enabled session.

Trigger registry (dynamic tools)

If your environment has published Triggers with MCP enabled, your MCP client will discover additional tools named trigger_invoke__*. These calls dispatch real runtime messages, so they require a write-enabled MCP session.

1. Start MCP with --allow-write and refresh the tool list in your assistant.
2. Invoke a trigger tool, for example trigger_invoke__smoke_trigger, with its schema-defined parameters.
3. Use trigger_invocation_get with the returned invocation_id to poll until you see a terminal state.

Session split pattern

Session	Typical flags	Typical tools
Production read-only	--profile prod --stdio	deployments_list, deployment_status_get, workers_logs_recent, job_notifications_recent
Staging authoring	--profile staging --stdio	spec_search, job_template_list, job_yaml_preview, job_lint
Controlled change window	--profile ops --stdio --allow-write --activity-forward --activity-session-label ops-change-window	job_stage, job_deploy, deployment_action_enqueue, deployment_apply_with_refresh

This split keeps production inspection, authoring, and live mutation in separate trust domains even when all three sessions run on the same machine.