Agents are getting good, really good, at asking questions and building visualizations. Hook up an LLM to an analytics database, point it at your business data, and it can find patterns, generate reports, and surface insights that would take a human analyst hours to uncover.
The interesting work, though, starts when an agent can act on what it finds — creating derived tables, storing intermediate results, building enriched datasets, or writing back transformed data for the next agent in the chain.
We just released write access for the MotherDuck remote MCP server via the new query_rw tool. Your agents can now INSERT, UPDATE, DELETE, create tables, and modify schemas through the MCP — not just SELECT.
While you could always use the DuckDB CLI plus a coding agent to write to your databases, the MCP server provides another interface for faster, lighter-weight writes. Here's why that matters, and how to do it safely.
Agents Need More Than Read Access
If you're building with agents, you've hit this wall: the agent generates a great analysis, computes a useful intermediate result… and then has nowhere to put it. It can't create a staging table. It can't store a derived metric for next time. It can't clean up after itself.
Consider a churn prediction agent. It needs to:
- Pull customer data from your business systems — CRM, product usage logs, support systems
- Join and transform that data into a unified view
- Compute derived features (engagement scores, usage trends, spending velocity)
- Store those features so downstream agents or dashboards can use them
- Update the analysis as new data arrives
Steps 1 and 2 are read operations. Steps 3 through 5 require write access. Without it, the agent is stuck presenting results ephemerally — you see them once in a chat window, and they're gone.
Sure, you could have the agent write dbt pipelines. But not everything needs a pipeline! Sometimes you just want it done.
New Tools in the MotherDuck MCP Server
The MotherDuck MCP server now exposes two SQL execution tools:
query— Read-only. SELECT, EXPLAIN, ATTACH. Standard for exploratory analytics.query_rw— Full read-write. INSERT, UPDATE, DELETE, CREATE TABLE, ALTER, DROP. For agents that need to build things.
The interface is straightforward — your agent sends a SQL statement and an optional database context:
Copy code
{
"database": "my_database",
"sql": "CREATE TABLE main.churn_features AS SELECT customer_id, avg(daily_usage) as avg_usage, count(support_tickets) as ticket_count FROM usage_data GROUP BY customer_id"
}
Results come back in the same format as read queries — columns, types, rows, and row count on success; error type and message on failure.
From MCP clients like Claude Desktop and Claude Code, you can configure tool permissions to constrain agent behavior at the tool level: always allow, needs approval, or blocked. So you're not handing over the keys entirely.
Here's what that looks like in practice — a Claude Code agent using query_rw to create a table directly in MotherDuck:
Running Write Access Safely on MotherDuck
Giving an agent write access to a shared data warehouse sounds terrifying — and in most architectures, it should be. At worst, one runaway agent corrupts a shared table and takes down analytics for the whole organization. At best, agents executing long-running queries rack up an excruciating bill.
MotherDuck has three features that make write access safe by design.
Zero-Copy Clones: Give Every Agent Its Own Playground
Rather than pointing an agent at your production database, give it a clone. A single CREATE DATABASE statement clones an entire MotherDuck database almost instantly — no data is physically duplicated, so it's effectively free. This operation is nearly instantaneous and only updates metadata, so storage costs are not duplicated and changes in the clone are isolated from the source after creation.
Copy code
-- Give the agent its own playground
CREATE DATABASE agent_workspace FROM production_db;
The agent gets full write access to its clone: add columns, enrich data, create derived tables, run experimental transformations. When it's done, you move results back with cross-database queries. If something goes wrong, drop the clone. Nothing is lost, production was never touched. Learn more about zero-copy cloning in MotherDuck.
Time Travel with Snapshots: Built-In Undo for Agent Changes
Even when an agent writes directly to a database, MotherDuck's snapshot system has your back. Every insert, update, delete, and schema change automatically captures a point-in-time snapshot. You can restore from any snapshot within your retention window — or create named snapshots as explicit checkpoints — to recover the exact state before the agent made its changes. No restore workflows, no downtime.
Copy code
-- Roll back to yesterday's state
CREATE DATABASE recovery FROM production_db (SNAPSHOT_TIME '2025-06-14T00:00:00');
Write access becomes a reversible operation. Let the agent build, and if something goes wrong, rewind.
Hypertenancy: Isolated Compute for Every Agent
MotherDuck doesn't share a single compute pool across all users in an organization. Every user — and every agent — gets their own isolated compute instance, called a duckling. They share access to the underlying data, but each duckling runs on its own resources. This architecture is called hypertenancy.
What this means for agents with write access:
- No resource contention. An agent running an expensive transformation doesn't slow down your BI dashboards or other users — human or agent. Each duckling has its own compute allocation.
- Cost predictability. You choose the instance size per agent. A lightweight reporting agent gets a small duckling. A heavy churn predictor gets a jumbo. You're paying for what each agent actually uses, not peak capacity across all of them.
- Sandboxed experimentation. An agent can create tables, write intermediate results, and iterate in its own space. If something goes wrong, the blast radius is contained.
Controlling Write Access
Write access is powerful, and you'll want to control who has it. Within an organization, you can maintain write access as a data engineer or admin, while providing database shares to downstream, read-only users. Shares are read-only by nature, so you don't need to configure tool access at the client level.
On the agent client side, the remote MCP server makes configuration straightforward — most MCP clients let you toggle individual tools on or off. Disable query_rw for any agent or user that shouldn't be writing, keep query available for read-only analytics.
Getting Started
Armed with write access, agents can ingest, transform, and materialize results in one pass, and persist expensive computations for reuse instead of recomputing from scratch. It also unlocks multi-agent workflows where each agent reads from the previous one's output tables and writes its own, with the database as the coordination layer.
If you're already using the MotherDuck remote MCP server, query_rw is available now. Both tools are exposed out of the box — no configuration changes needed. For a full walkthrough of agent workflows with MotherDuck MCP, see the MCP workflows docs.
Start with something simple: have your agent create a summary table from an existing dataset. Then try a multi-step workflow where the agent ingests, transforms, and writes back. Once you see an agent building things in your warehouse, it's hard to go back.
Your agent has been asking great questions. Now let it build the answers.
TABLE OF CONTENTS
Start using MotherDuck now!
