Run workflows and approve costs.

MCP execution requires the right graph context, inputs, authority and cost handling. An available balance is not approval, and an agent setting confirm_cost:true is not evidence that a person agreed.

#Keep approval attached to the prepared work

Preparation describes the intended work and its cost or uncertainty. Review the exact scope, provider and price terms before authorizing execution. Use the preparation and execution identifiers required by the tool. If preparation expires or terms change, prepare again and obtain any required renewed approval. Retain the run receipt and inspect it rather than submitting duplicate work.

The quote example binds targets A and B at editor revision 7. Changing the target to C or revision to 8 breaks that match and requires a fresh preview. An available balance remains separate from the person’s agreement.

#Choose a run path

Path	Tools and intent
Transient single node	run_node_by_type or run_node_by_search with explicit inputs
Persistent headless graph	start_node_run or start_graph_run for the working graph
Attached Studio graph	Listed start/run tools with explicit session and current revision

Scratch tools do not read Studio widgets, add persistent nodes, or save their transient graph. A missing required input returns guidance rather than permission to invent it. Search resolves Kaitoi catalog operations, not web results; ambiguity needs clarification.

#Read preflight before approving costs

The initial execution request performs the supported cost preflight. Potential provider, community, platform or unknown-priced work can require confirmation. Read the estimate, incomplete/unpriced warnings, target scope and intended settings. COST_PREFLIGHT_UNAVAILABLE starts no work; resolve that failure instead of bypassing it with a confirmation flag.

For headless costly execution, obtain real user approval and retain the logical idempotency key for the confirmed request. Compatibility helpers run_node/run_graph wait under the same admission rules; they are not a free alternate path.

#Prepare and commit an attached run

An attached first call returns or prepares costQuote, preparationId, revision, expiresAt, requiresConfirmation, and costPreview. If still pending, retain its actionId or resume the same preparation as the tool contract directs. Do not create duplicate preparations to escape uncertainty.

After approval, repeat the same public run tool with the same targets, revision and quoted context, cost_quote, confirm_cost:true, and a stable idempotency_key. The attached commit requires a key even when the preview has no confirmation-required costs. There are no separate public prepare_graph_run or commit_graph_run tools to invent.

#Keep the approval tied to the work

Preview: inspect the requested targets, pricing and unknown-work warnings; an unavailable preflight dispatches nothing. Approve: a person agrees to the particular terms; balance alone or an agent's flag is not approval. Commit: repeat the same attached run tool with the quote, current bound revision and stable logical key. Quotes expire and are not spending caps.

#Observe before retrying

Quotes expire and are context/pricing-bound; they are not spending caps. Refresh an expired or changed preparation and obtain approval for changed terms. A native consent/task UI can help when the client supports it, but host availability does not replace the server's quote and identity binding.

Keep action IDs, execution IDs and idempotency keys distinct. After an uncertain response, inspect the original action or execution before another attempt. Reusing a key is meaningful under that tool's current contract, not an unlimited guarantee across canceled, expired or changed work. See Results and cancellation.