# MotherDuck CLI: query, pipelines, and dashboards from your terminal > Source: > Published: 2026-08-27 00:00:00+00:00 2026/08/25 - Jordan Tigani MotherDuck Acquires Tower to power Data Agents[Read](https://motherduck.com/blog/motherduck-acquires-tower/) - 9 min read BYOne prompt and 45 seconds of CLI time. That's what it took an agent to sign up for MotherDuck, load a dataset into a pipeline, and publish a dashboard on top of it. That's the session I'll walk through in this post, with Claude Code driving the new MotherDuck CLI. Since launching our MCP server in November 2025, we've been investing in making MotherDuck work well with AI. But agents don't all live in chat windows anymore. A big chunk of them run in coding tools, CI jobs, and sandboxes where the natural interface is a shell. And a shell is where the rest of your infrastructure already lives: your CI, your deploy scripts, your Makefiles. So we built a [CLI](https://motherduck.com/docs/getting-started/interfaces/motherduck-cli/). Use it to give your agent a MotherDuck environment it can operate directly, or use it on your own to deploy and manage MotherDuck resources as code. Same commands either way. With the MotherDuck CLI, creating an org, a pipeline, and a dashboard is a handful of commands, whether a human or an agent is typing them: ``` curl -s https://install.motherduck.com | sh # install the CLI motherduck login # existing user? browser login motherduck new # or: free org, no signup needed motherduck query "FROM 's3://bucket/data.parquet' LIMIT 10" motherduck flight push my_pipeline --run # publish + run a Python pipeline motherduck dive push my_dashboard # publish a hosted dashboard ``` In this post, I'll walk through why we built it, run a real end-to-end session with Claude Code driving the CLI (with actual timings from my terminal), and explain when to reach for the CLI vs our existing MCP server. MCP has been great for getting started. You go to the Claude or ChatGPT connector directory, authenticate to MotherDuck in a few clicks, and your agent gets a bunch of tools. That flow works well when the agent lives in a chat client. A CLI puts the work where the agent already lives. MCP tools are remote calls: every result comes back through the model. A CLI runs in the agent's local environment, next to grep, git, and the filesystem. `motherduck flight push hn_flight` does the same thing whether a human types it, a CI job runs it, or Claude Code calls it, and the agent only spends tokens on the decision, not on the execution. It also keeps the work outside the context window. Every MCP tool result lands in the context, and you pay tokens for it. With a CLI, the agent can pipe `motherduck query` into a file, grep the three rows it cares about, or diff two dive sources on disk, and only the relevant part ever reaches the model. DuckDB runs locally too, so file-shaped work (authoring code, staging data) happens on the machine and ships to the cloud in one call. Fewer round trips through the model means [fewer tokens burned](https://motherduck.com/docs/getting-started/interfaces/motherduck-cli/agents/#why-the-cli-costs-fewer-tokens-for-file-shaped-work). And since it's a plain command, it's scriptable. The same CLI you hand to an agent is the one you put in a Makefile or a GitHub Action to deploy flights and dives as code. No AI required. Second reason: setup with no browser. An agent running in a CI job or a sandbox can't click through an OAuth screen. (You can run the MCP server with a token too, but the CLI makes it the default path.) With the CLI, one curl command and the agent has everything it needs. If you already have an account, `motherduck login` gets you in. If there's a `MOTHERDUCK_TOKEN` in the environment (the CI case), the CLI picks it up automatically. If neither, `motherduck new` creates a [temporary org](https://new.motherduck.com/) for free, no signup, and stores the token. You also get a claim URL to attach that org to a human account later, so the agent can do the work first and you take ownership after. Third: one surface. MotherDuck started as a DuckDB extension, which meant installing DuckDB first. The CLI ships with DuckDB inside, so `motherduck query` works locally and against the cloud from one install. Admin operations live in a [REST API](https://motherduck.com/docs/sql-reference/rest-api/motherduck-rest-api/). The CLI puts queries, pipelines, dashboards, and account management behind a single interface to manage all your MotherDuck resources and assets, for humans and agents alike. ``` Can you use the motherduck cli to analyze this dataset : https://us.data.motherduck.com/hacker_news/parquet/hacker_news_2021_2022.parquet ``` This is a minimalist prompt on purpose. I gave it to Claude Code and let it figure out the rest. The dataset is 3.87M Hacker News items (stories, comments, polls). Here's what the agent did, with the wall-clock timings from my session. The agent searches for the install command and finds: ``` curl -s https://install.motherduck.com | sh ``` This installs the [MotherDuck CLI](https://motherduck.com/docs/getting-started/interfaces/motherduck-cli/). In my case a token was already present, so the CLI connected straight to my org. Before writing any pipeline code, the agent inspected the data with `motherduck query` , reading the parquet straight from our public datasets host (zero credential setup): `DESCRIBE` for the schema: 1.8sHere's the schema inspection, exactly as it ran: ``` motherduck query "DESCRIBE SELECT * FROM 'https://us.data.motherduck.com/hacker_news/parquet/hacker_news_2021_2022.parquet'" column_name column_type null key default extra ----------- ----------- ---- --- ------- ----- title VARCHAR YES url VARCHAR YES text VARCHAR YES dead BOOLEAN YES by VARCHAR YES score BIGINT YES time BIGINT YES timestamp TIMESTAMP YES type VARCHAR YES id BIGINT YES parent BIGINT YES descendants BIGINT YES ranking BIGINT YES deleted BOOLEAN YES ``` And the row breakdown that told the agent what it was dealing with: ``` motherduck query "SELECT type, count(*) AS n FROM 'https://us.data.motherduck.com/.../hacker_news_2021_2022.parquet' GROUP BY type ORDER BY n DESC" type n ------- ------- comment 3530415 story 334153 pollopt 1123 job 915 poll 134 ``` That exploration pass paid off: the pipeline SQL that came out of it quoted the reserved `"by"` column, filtered on the `dead` and `deleted` flags, and picked the `timestamp` column over the raw epoch one. The agent found the sharp edges before they became bugs. This is my favorite part. The CLI ships its own agent-facing docs: ``` motherduck flight guide motherduck dive guide ``` Each prints a full authoring guide: supported APIs, runtime limits, gotchas like pinning the duckdb version or converting BigInt values before charting. If your org has authored its own flight or dive guidance, the CLI appends it here too. They run locally, so the agent gets everything it needs without a single web search. In my session, both the pipeline and the dashboard worked on the first try, and I credit the guides for that. A [Flight](https://motherduck.com/docs) is a Python data pipeline that runs on MotherDuck, on demand or on a cron schedule. The agent scaffolded one locally, wrote the ingestion logic, and shipped it: ``` motherduck flight init hn_flight --name hn_ingest # 0.04s motherduck flight push hn_flight # 8.9s motherduck flight run hn_flight # 3.0s to submit ``` The run itself ingested all 3.87M rows into three aggregate tables (daily activity, top domains, top stories) in 11.5 seconds of server-side compute. The agent then checked the exit code with `flight list-runs` and verified the output tables with one more query (2.0s) before moving on. A Dive is an interactive dashboard authored as a single React file and hosted on MotherDuck. The agent wrote one `index.tsx` querying the tables the flight produced: KPI tiles, a daily time series with a metric toggle, a top domains chart, and a top stories table. ``` motherduck dive init hn_dive --title "Hacker News 2022 Pulse" # 0.04s motherduck dive push hn_dive # 2.2s ``` Push returns a live URL. Since the dive reads the flight's output tables, re-running the flight refreshes the dashboard for free. The dive created: *(placeholder: dive demo video goes here in the final post)* End to end: one prompt, about 45 seconds of CLI time, from no account to a scheduled-ready pipeline plus a hosted dashboard. A few design choices make the CLI pleasant for agents specifically: `init` , `guide` , `--help` ) run instantly with no network call.`-o json` for programmatic parsing: ``` motherduck flight list-runs hn_flight -o json ``` `flight list-runs` returns exit codes and `flight logs` returns what the run printed. When a pipeline fails, the agent reads the logs, fixes the source, and pushes again. Versions are tracked on every push, so nothing is lost.`flight push --run` collapses publish and execute into one call, which saves a round trip in tight loops.Both let an agent work with MotherDuck. The deciding question is whether the agent has a shell and a filesystem. If there's a local environment with compute available, the CLI is your best friend: it keeps big results out of the context window and lets the agent filter locally. If there's no shell (Claude or ChatGPT on the web), MCP is the way in: With the CLI, agents get a smooth way to set up and use MotherDuck: one curl to install, one command for a free org, built-in guides so they don't guess, and JSON output so they don't parse tables. The CLI is the same tool either way: paste the prompt above into your favorite agent (and try it with your own dataset), or wire the commands into your CI. Both get a predictable MotherDuck experience. Watch the ducking magic happen. 2026/08/25 - Jordan Tigani 2026/08/26 - Jordan Tigani Today Duck Labs, the developers of DuckDB, announced they are being acquired by Amazon. This is big news in the duck-iverse, and many people are wondering what this will mean for everyone’s favorite duck-powered database, MotherDuck.