Mcp Server Motherduck Cloud

MotherDuck gives MCP servers a managed DuckDB experience with cloud persistence, so an agent can query Parquet on S3, local files, and shared databases with the same SQL. The setup is unusually simple: a service token, a database attach, and a few read-only grants get you a production-grade agent backend.

MotherDuck is DuckDB in the cloud with sharing, persistence, and hybrid execution. That combination makes it an excellent target for MCP: DuckDB's SQL dialect is friendly for agents, the cost is low, and cloud persistence means the agent can work with shared data across sessions. This guide covers the production setup.

Why MotherDuck Fits MCP

Most data stacks overprovision for MCP workloads. Snowflake, BigQuery, and Databricks are built for BI at scale; an agent's per-query cost on those warehouses is often pennies spread across minutes of warehouse uptime. MotherDuck sidesteps that by running DuckDB in the cloud at a fraction of the cost, with instant cold starts.

MotherDuck also solves a real DuckDB weakness: persistence. Traditional DuckDB is file-local, which makes it hard for an MCP server to share state across restarts or users. MotherDuck keeps the database in the cloud, handles concurrent reads, and supports sharing across team members — everything you need to run an MCP server that survives deployments.

Authentication with Service Tokens

MotherDuck authentication uses service tokens (PATs). Create a token scoped to a single database with read-only permissions and load it into the MCP server via environment variable. Rotate the token quarterly and keep it in a secrets manager, not committed in a config file.

• •Service token — single database scope
• •Read-only grants — via ATTACH
• •MD_TOKEN env var — loaded from secrets manager
• •Hybrid mode — local scan + cloud compute
• •Share links — controlled distribution of views

Attach and Grants

The MCP server connects by attaching a MotherDuck database via the DuckDB client: ATTACH 'md:analytics' AS md. The service token governs what the agent can see. Use MotherDuck's grant system to expose specific schemas and views, and keep raw tables private. The grant model is similar to Postgres and should feel familiar.

Cost and Usage Limits

MotherDuck pricing is usage-based: compute units consumed plus storage. For a typical MCP workload the monthly cost is tens of dollars, not thousands. Set a billing alert at a threshold (usually $50) so you notice if an agent starts burning more than expected. A runaway agent on MotherDuck is much cheaper than a runaway agent on Snowflake.

Hybrid Execution

MotherDuck's killer feature for MCP is hybrid execution — the agent can scan Parquet files on the local machine and join them against cloud tables without moving data. That is useful when the agent operates on local exports or logs but needs to enrich them with shared reference data. Most other MCP backends cannot do this at all.

Observability

MotherDuck exposes a query history UI and a CLI command (md query history) that show every query the token issued. That plus the agent's own audit log gives you a complete picture of activity. The dataset is small compared to a full warehouse query log, so exporting it to an analytics target is cheap.

Data Workers on MotherDuck

Data Workers' MotherDuck connector handles token auth, attaches the shared database, and picks up grant metadata automatically. The catalog agent discovers tables, the cost agent tracks usage, and the pipeline agent can run transforms in DuckDB SQL. See AI for data infrastructure or compare with MCP server DuckDB local for the embedded variant.

To see MotherDuck MCP wired into an agent workflow with real data, book a demo. We will walk through token setup, ATTACH patterns, and hybrid scans.

MotherDuck's hybrid execution deserves a closer look because it is genuinely unusual. When the MCP server runs a query that touches both local data (say, a Parquet file on disk) and cloud data (say, a shared team database), MotherDuck decides on the fly where each part of the plan should execute. Scans that hit cloud data run in MotherDuck; scans that hit local data run in-process. The result is lower data transfer costs and faster queries than shipping everything to one side.

For teams evaluating MotherDuck versus a full warehouse, the decisive factors are usually cost, concurrency, and governance. Cost favors MotherDuck by an order of magnitude for small agent workloads. Concurrency is fine up to a few dozen simultaneous agents but not thousands. Governance is where full warehouses still win — MotherDuck's RBAC is simpler than Snowflake's, so highly regulated environments may still prefer a traditional warehouse even if the cost is higher.

One compelling pattern is using MotherDuck as the agent's scratch warehouse. The agent reads from the primary Snowflake or BigQuery via a separate MCP server, materializes the intermediate results as Parquet files on S3, then queries them with MotherDuck for fast iteration. This keeps the expensive warehouse doing only the heavy lifts while the agent runs interactive exploration on cheap storage.

MotherDuck is the cheapest, fastest way to put a production MCP server on a DuckDB backend. Service tokens, read-only grants, and hybrid execution give agents everything they need without the cost and cold-start penalties of a full warehouse.