Stream AI, ML and LLMs MotherDuck Features SQL

Agents That Build Tables, Not Just Query Them

Q: What does the query_rw tool in MotherDuck's MCP server do?

The query_rw tool in MotherDuck's MCP server gives AI agents write access to your database. Before this, the MCP only supported read queries. With query_rw , an agent can create tables, insert rows, update data, and save views. The two tools, query and query_rw , are separate so you can default to read-only and only enable writes when you actually need them. Claude and other MCP-compatible tools also let you disable specific tools at the admin level, so you can cut off write access entirely without disconnecting the server.

Q: Can I call other AI models from SQL in MotherDuck?

Yes. MotherDuck has a built-in prompt() function that calls external AI models directly from SQL. In the demo, it calls GPT-4 in parallel across every row of a table. MotherDuck routes these requests through Azure's OpenAI layer, so you can use GPT-4 and other OpenAI models without managing API keys yourself. A thousand-row table finishes quickly given the parallelism. You can also pass model parameters like temperature and model variant.

2026/03/17Featuring:

Jerel Navarrete

Jacob Matson

The problem this solves

Most agent workflows hit a wall: the agent computes something useful and then has nowhere to put it. The analysis lives and dies in a chat window. The query_rw tool in MotherDuck's MCP server closes that loop by letting agents create tables, insert data, and save views — not just query.

What the demo builds

Jacob Mattson walks through a wine list dataset in Claude Web with the MotherDuck connector attached. Three operations run back-to-back, each writing results to MotherDuck:

Enrich with AI content. MotherDuck's built-in prompt() function calls GPT-4 in parallel for every row, generating a wine description from country, region, producer, vintage, and score. The results land in a new column.

Clean with SQL. Claude spots data quality issues — invalid vintage years, non-standard price formats — and generates a cleaned table using regex normalization. No manual query writing needed.

Build a recommendation engine. Claude generates 512-dimensional vector embeddings for each description, stores them in a new table, then writes a cosine similarity query to match wines to a plain-English search phrase.

What makes agentic writes safe

Four MotherDuck features keep things under control when an agent has write access:

Zero-copy cloning lets you work on a shared dataset without touching production. Time travel restores tables if an agent drops something. Hyper-tenancy isolates your compute from other users, so a runaway query only affects your instance. And query and query_rw are separate MCP tools, so you can disable write access at the admin level without losing read access.

Sonnet vs. Opus for SQL work

Sonnet handles most SQL tasks well and costs less than Opus. The demo uses Opus mainly because it was already the default in that session. For SQL generation and data analysis, Sonnet is fine. Opus is worth the extra credits when you need more creativity: writing product descriptions, working through complex logic, or generating output that needs more nuance. If you're mostly querying and transforming data, stick with Sonnet.

For setup and configuration, see the MCP workflows docs.

Transcript

1:02Hey there, everyone. Welcome to our live stream on Agents That Build Tables, Not Just Query Them. We'll be talking about MotherDuck's new MCP feature where you can both read and write to MotherDuck. I'm joined by Jacob Mattson, DevRel at MotherDuck.

1:55MotherDuck is building infrastructure for answers. We're a cloud data warehouse that lets you ask questions and get answers in whatever way you want — whether you are a human or an agent — using SQL or natural language. MotherDuck is built on DuckDB, giving you fast analytics in a serverless cloud setup.

3:35All right. We're going to do this demo in Claude Web. I'm going to use Claude Web with the MotherDuck connector. This works on desktop, works anywhere. There's an MCP. You can use Cursor. It really just depends on what your favorite tool is.

4:53I'm using a dataset called WineList. I'm going to give Claude a prompt to look at the data in mydb.me.winelist. It's smart enough to know that's a request to look into the MotherDuck MCP.

6:00It runs some queries, lists the tables, finds the wine list. A thousand rows. Not too big, but we can do some fun stuff with it.

7:20What I want to do first is enrich this with AI-generated descriptions. I'll use MotherDuck's prompt() function to write a product description for each wine using country, region, producer, name, vintage, and score as context.

8:30It's already doing some data quality analysis — flagging the non-vintage edge case, vintage year 1000, using coalesce. That's a nice catch. Let's use GPT 5.0 as the model. It's testing the query syntax before running the full table, which is smart.

10:40We serve these models via Azure using the secure Azure model serving layer with OpenAI. So you can use OpenAI models inside Claude, which is pretty cool. Now it's running with the query_rw tool — you'll notice there are two query tools when you use the MCP. One is called query, one is called query_rw.

13:50Now let's create another new table that adds embeddings for each description — 512-dimension vectors so we can do cosine similarity search later. Claude knows to check the MotherDuck docs for the embeddings syntax. Done. It worked.

15:00Elegant Burgundy Pinot Noirs with aging potential — using cosine similarity. Here are the recommendations. A 97-score wine that nobody knows about. That is extremely funny. So we've basically built a recommendation engine on the fly in SQL inside Claude on MotherDuck.

19:30Let me pop into the MotherDuck UI to show what we built. We've got unit size, bottle size, scores, quantities, prices, descriptions, and embeddings all in one table. The varchars are now integers. Pretty cool.

22:50So what just happened? We took a dataset, enriched it, cleaned it up, and found some bottles of wine. Now let me talk about what architecturally makes this possible.

23:50Four things make MotherDuck well-suited for this type of agentic workflow. First: zero-copy cloning. If you're working on a warehouse owned by someone else, they can share it to you without duplicating data. You make local modifications. Production is untouched.

24:50Second: time travel. We have snapshotting now. If you drop a table with your agent, you can undrop it. So even for sensitive datasets that are expensive to rebuild, we have those safety features.

25:40Third: hyper-tenancy. Every user gets their own database and doesn't share by default. If your agent writes a bad query, it only affects your instance, not your neighbors'.

26:30Fourth: we split query and query_rw into two separate tools. If you want to enable the MCP but not writes, you can turn that off. Claude and Anthropic have a built-in feature to disable specific tools inside specific MCPs.

28:05Q&A. On how the workflow has changed: a lot of Excel work has just been replaced. AI and SQL have basically replaced spreadsheets for me. I'm someone who used Excel my whole career and was pretty good at it.

29:52On runaway costs: MotherDuck isn't like Snowflake or BigQuery — you can't run queries for 24 hours or use 40,000 slots. That constraint naturally limits cost blowout.

36:03On the local DuckDB MCP vs remote MotherDuck MCP: the local MCP runs on your machine and is free. The remote MCP runs on MotherDuck's servers and handles authentication. The tool sets are similar but not identical. Those are two separate pathways.

35:15For people new to MotherDuck today: start with a real problem you have. DuckDB is free, open source, MIT licensed, runs anywhere. MotherDuck fits in when you need to persist and share data. We have a free trial and a free plan for personal use.

38:14All right. With that, we'll end it here. We'll share the recording link and put it on our website. Thank you, everyone.

FAQS

The query_rw tool in MotherDuck's MCP server gives AI agents write access to your database. Before this, the MCP only supported read queries. With query_rw, an agent can create tables, insert rows, update data, and save views. The two tools, query and query_rw, are separate so you can default to read-only and only enable writes when you actually need them. Claude and other MCP-compatible tools also let you disable specific tools at the admin level, so you can cut off write access entirely without disconnecting the server.

MotherDuck has four features that make it less risky to give an AI agent write access. Zero-copy cloning lets you work on a shared dataset without touching the production copy — modifications stay in your own database. Time travel lets you restore a table if an agent drops it. Hyper-tenancy isolates your compute from other users, so a runaway query only affects your instance. And because query and query_rw are separate MCP tools, you can disable write access at the admin level without losing read access. The MCP workflows docs cover how to set this up.

The remote MotherDuck MCP runs on MotherDuck's servers and handles authentication for you. The local DuckDB MCP runs on your machine and is free. It can also connect to MotherDuck, since DuckDB supports those connections natively. The two offer similar but not identical tool sets. If you want to experiment without any cost, the local MCP is a good starting point since it only uses your own compute. If you need hosted authentication or a production setup, use the remote MCP.

Yes. MotherDuck has a built-in prompt() function that calls external AI models directly from SQL. In the demo, it calls GPT-4 in parallel across every row of a table. MotherDuck routes these requests through Azure's OpenAI layer, so you can use GPT-4 and other OpenAI models without managing API keys yourself. A thousand-row table finishes quickly given the parallelism. You can also pass model parameters like temperature and model variant.