Examples and Playbooks

Applies to LyftData 3.0.0-beta.5

Use tool_inventory and tool_get to confirm the live schema before calling a named tool. Tool visibility depends on release, feature availability, session scope, maximum tier, server RBAC, and runtime readiness.

Choose a playbook

Goal	Start at	Maximum tier	Stop condition
Attach a client and inspect scope	MCP quickstart	read_only	Inventory and metrics match the target
Investigate a rollout	Deployment/status, signals, logs, notifications	read_only	Evidence identifies the failing boundary
Draft and deploy one job	Author Jobs	write after preview	Runtime and any destination receipt agree
Build a multi-job graph	Author and Deploy Workflows	write after preview	Plan, apply, readiness, counts, cleanup recorded
Invoke a published Trigger	Triggers	write	Invocation reaches a terminal state
Diagnose MCP itself	MCP Troubleshooting	Begin read_only	Release, scope, tier, RBAC, or readiness cause found

Read-only rollout investigation

1. Identify the deployment with the list/get tools.
2. Inspect desired versus observed status and the latest plan/apply difference.
3. Read lifecycle warnings, signals, worker logs, and notifications.
4. Correlate evidence with the same deployment, worker, and time window.
5. State what the evidence does not prove before recommending a change.

Keep this session read-only. If a change is warranted, open a separate named write-tier session and review the mutation’s live schema.

Dynamic Trigger tools

A Trigger published for MCP appears as trigger_invoke__<slug> when the current identity may invoke it. Invocation is a real runtime action and needs --max-tool-tier write. Pass the Trigger’s schema-defined arguments, record the returned invocation_id, and inspect it with trigger_invocation_get.

Clients commonly cache tool lists. Reconnect after publishing or revising a Trigger. Use an idempotency key when the Trigger contract supports it; do not assume a client retry is harmless.

Evidence ladder

For every playbook, name the strongest level actually proved:

1. Intent: previewed job, workflow, or plan.
2. Accepted change: server returned an immutable or lifecycle identity.
3. Applied state: desired state was committed.
4. Observed runtime: assigned work became ready and emitted correlated logs, metrics, traces, or counts.
5. External acceptance: the destination returned a correlated receipt or readback.

Never report a lower level as a higher one. See Runtime Evidence and Receipts.