/motherduck-create-flight

name: motherduck-create-flight
description: Create, run, schedule, or debug MotherDuck Flights, Python jobs executed on MotherDuck compute.
license: MIT

Create and Manage MotherDuck Flights

Source Of Truth

• **Non-negotiable ordering:** when MotherDuck MCP is available, call `get_flight_guide` before `create_flight`, `update_flight`, or `edit_flight_source`. The guide defines the current authoring contract, runtime limits, and tool semantics.
• `get_flight_guide` also surfaces conventions from the reserved `flights` Guide topic. Apply those conventions when they fit the requested workload.
• Prefer current MotherDuck Flights docs over memory. Verify lifecycle status, runtime limits, and tool semantics instead of preserving them as durable prompt claims.
• Without MCP, the same operations exist as SQL functions (`MD_CREATE_FLIGHT`, `MD_RUN_FLIGHT`, `MD_LIST_FLIGHTS()`, ...) that execute server-side on a MotherDuck connection. Parameter names differ slightly between the two surfaces; see the naming table in `references/FLIGHTS_GUIDE.md`.

Default Posture

• One Flight = one single-file Python script with `def main(): ...` and `if __name__ == "__main__": main()`. No CLI args — every knob comes from env vars via `config` (non-secret) or `TYPE flights` secrets (sensitive).
• Connect with `duckdb.connect("md:")`; the runtime injects `MOTHERDUCK_TOKEN` automatically. Never hardcode a token in source, config, or requirements.
• Always pin dependencies in `requirements_txt`. Resolve the highest MotherDuck-supported DuckDB version from `https://motherduck.com/docs/duckdb-versions.json` before authoring a new Flight; use the tested pin in the included templates only when reproducing those examples. An unpinned or unsupported `duckdb` can fail at connect.
• Each secret param is injected under a stable namespaced `<secret_name>_<PARAM>` key and, when safe, a bare `<PARAM>` convenience alias. Prefer namespaced keys in deployed Flight code; bare aliases can collide, be overridden by config, and are withheld for reserved runtime keys.
• Bulk-load, never row-by-row: stage to `/tmp/` and `read_csv_auto`/`read_json_auto`/`read_parquet`, or one CTAS / `INSERT ... SELECT`. No `executemany()` against MotherDuck.
• Make every run idempotent: `CREATE OR REPLACE TABLE` full refresh, partition `DELETE` + `INSERT`, or dlt `write_disposition="merge"` with a primary key. Bootstrap with `CREATE DATABASE IF NOT EXISTS` / `CREATE SCHEMA IF NOT EXISTS` so the first run succeeds on a fresh account.
• Validate any config-supplied identifier (database, schema, table names) against `[A-Za-z_][A-Za-z0-9_]*` before interpolating it into DDL; bind all data values as `?` parameters.
• Create the flight **without** a schedule first, trigger one on-demand run, read the logs, and only then attach `schedule_cron` (5-field cron, UTC).
• Set and validate `max_runtime_sec` when the workload needs an explicit cap; read the current plan limit from `get_flight_guide` instead of hardcoding it.
• For production, use a service-account token via `access_token_name` and keep its database permissions as narrow as the workload allows.
• Treat a Flight as orchestration and light processing, not a place to crunch large tables in Python memory. Push heavy compute into SQL and verify runtime capacity with `get_flight_guide` before sizing disk- or memory-intensive work.
• Keep the default size (`F16`) for dbt, dlt, and multi-step Python. Choose `F4` for light jobs that mostly call APIs or send SQL, since SQL over `md:` runs on a Duckling, not the Flight. Move to `F32` (Business and Enterprise) only when runs still fail from memory after reducing peak memory. Set it with `instance_type` on `create_flight`/`update_flight` or `MD_CREATE_FLIGHT`/`MD_UPDATE_FLIGHT`.
• When a Flight touches only one or a few databases, connect with `duckdb.connect("md:<db>?attach_mode=single")` and attach the others explicitly; attaching the whole workspace slows every run's startup.
• For classification, extraction, or embeddings inside a Flight, call `prompt_jev()`, `prompt()`, or `embedding()` in SQL over the existing connection instead of adding an LLM SDK.
• To let teammates, a role, or a Dive's viewers start a Flight, the owner grants `run` (`grant_access` over MCP, or `GRANT RUN ON FLIGHT '<flight_id>' TO ROLE <role>`). Recommend the grantees and grant only after the user confirms; a request to share a Dive is not that confirmation. Prefer a role over `ORGANIZATION`, which includes service accounts. Every run uses the owner's token and secrets, so validate each config value a caller can pass as untrusted input.
• Instrument every new Flight for the Flight Explainer by default: a `# @flight` Mermaid step chart plus a `mark()` helper that prints `@flight-run <step> <status>` lines (see the templates). It costs a few lines and cannot be added to a run after it starts, so skip it only when the user asks. Call `get_flight_viz_guide` for fan-out, branches, or child Flights, and use `view_flight_run` to show a run as a step diagram instead of pasting raw logs.
• Ask the user to create Flight secrets in the MotherDuck UI (Settings, Secrets) so values never pass through chat; check existence with `SELECT name FROM duckdb_secrets() WHERE type = 'flights'`.

Workflow

1. Classify the job: ingestion, transformation/refresh, export or alerting, or admin automation. If the job is interactive analysis or a one-off query, use `motherduck-query` instead — no Flight needed. 2. Call `get_flight_guide` (MCP) and confirm which database the flight writes to with `motherduck-explore`. 3. Reuse a matching template in `references/FLIGHT_EXAMPLES.md` when it fits; otherwise write a focused script that preserves the runtime, secrets, and idempotency contracts. 4. Create any required `TYPE flights` secret first, then `create_flight` with `name`, `source_code`, pinned `requirements_txt`, `config`, and secret names — no `schedule_cron` yet. 5. `run_flight`, poll `get_fligh