Author and Deploy Workflows with MCP

Use this path when one job is insufficient and the desired result needs branching, a durable stage boundary, or different placement groups.

Availability and release

This guide targets LyftData 3.0.0-beta.5 and requires a licensed environment with Deployments enabled. The beta.5 inventory includes the named preview, authoring, publication, group, deployment, plan, and apply tools. Community Edition can use MCP but cannot complete this Deployments lifecycle.

Keep six decisions separate

Before authoring, write down:

Control	Question
Dispatch	Which branch receives each event?
Transport	How does an event cross each edge and recover?
Placement	Which worker group may run each step?
Replicas	How much desired concurrency is requested?
Ownership	Which consumer owns each input partition or record?
Evidence	What proves intent, apply, runtime, and destination effect?

The assistant must not infer ownership or recovery merely from a replica count.

1. Inspect session authority

   Call mcp_server_metrics, tool_inventory, and tool_get. Confirm URL, tenant, environment, identity, tool tier, and the live schemas for every named mutation. Start in read_only.

2. Recommend the topology

   Call workflow_recommend and workflow_scaling_advice. State the required branches, transports, state, ordering, credentials, placement constraints, ownership contract, expected counts, and teardown boundary. Unknown safety facts are blockers, not defaults.

3. Preview all authored material

   Preview each proposed job or blueprint and then call workflow_authoring_preview for the complete graph. Review generated dispatch, edge transports, imports, bindings, warnings, and the proposal identity. This is the effect-free gate.

4. Save the unchanged reviewed proposal

   In the separate write-tier session, call workflow_authoring_upsert with the same content and preview identity. If the content changes, preview it again. Record the mutable draft identity.

5. Publish an immutable workflow version

   Call workflow_authoring_publish only after validation succeeds. Record the workflow name and exact published version. Future changes create a new draft/version; they do not rewrite this artifact.

6. Prepare bounded placement

   Preview the worker group with deployment_group_preview, then use deployment_group_create only if a reviewed run-owned group is required. Confirm membership, worker connectivity, capacity, credentials, source and destination reachability, local/shared storage, and any co-location rules.

7. Create a draft deployment and plan it

   Call deployment_create with the immutable workflow identity. Then call deployment_plan_preview. Review generated jobs and channels, placement, replica intent, warnings, destructive changes, and whether the preview is still fresh. Record the deployment and plan identities.

8. Apply explicitly

   Call deployment_apply_with_refresh only for the unchanged reviewed plan. Do not blindly retry an interrupted apply. First inspect deployment status, events, proposal identity, and the current desired/observed difference; the correct action may be to wait, re-plan, or recover through an approved product path.

9. Prove outcomes in layers

   Wait for assignment/readiness, then inspect deployment status, lifecycle events, worker logs, notifications, metrics, traces, and per-branch counts. Finally, perform destination-side readback for every claimed external effect. Plan success is not apply success; apply success is not readiness; runtime success is not external acceptance.

10. Correct or tear down exact identities

    Preview a retarget or cleanup action before applying it. Remove only the recorded deployment, generated jobs, channels, group, workflow draft, and external fixtures owned by this run. Re-list each surface and verify zero residue. If ownership is ambiguous, stop and leave the resource intact.

Fan-out-specific review

For a clone branch, prove that the full-archive count equals valid input and that each filtered branch matches its predicate. For round-robin, prove total conservation across outputs; do not claim key affinity. For conditional routing, enumerate the static field-to-port mapping and an explicit unmatched case. See Routing and Fan-out.

Evidence record

Keep a sanitized record of the release checksum, client version, session scope/tier, proposal identity, published workflow version, group, deployment, plan, generated artifacts, expected/observed counts, external receipt when used, and cleanup result. Do not include tokens, raw credentials, customer payloads, or full MCP request/response bodies.

For a deterministic practice run, use the local fan-out tutorial.