Feature Requests

Just like with the list_tables and list_columns tools, a list_functions tool would let the agent discover any functions defined as part of the current schema. It should include comments on those functions, just as the aforementioned tools do. It could be called list_macros instead, since these terms are used interchangeably in DuckDB.

Something like Snowflake's auto-evolution would make having a bronze data lake easier. Having it be a toggle on/off, for when you want to build more structured and governed data, would be a requirement.

Query MotherDuck through an http REST request that passes in a SQL string and receives the results. Please comment with the specifics of what you would like to see with this API!

Summary Let a published, public Dive be embedded in a third-party website via a simple iframe or <script> snippet, with no backend and no Business plan required. Keep MotherDuck branding and attribution in the embed. Today, embedding a Dive at all requires the Business plan plus a server to mint session strings, which rules out static personal sites. Problem I built two public Dives and want to showcase them on my personal site (a static Hugo site on GitHub Pages). I expected to drop in an iframe. Two things block it: 1. The hosted Dive URL ( app.motherduck.com/dives/ ...) sends X-Frame-Options: SAMEORIGIN and Content-Security-Policy: frame-ancestors 'self', so it cannot be framed on any other origin. 2. The official embed path ( embed-motherduck.com/sandbox/#session= ...) needs (a) the Business plan and (b) a backend endpoint to generate session strings from an access token. A static site has no backend, and a personal showcase does not justify a Business plan. So the only option left is to screenshot the Dive and link out, which loses the interactivity that makes a Dive worth sharing. Current workaround Static screenshot plus a link to the hosted Dive. Functional, but the visitor leaves my site and the embedded experience is just an image. Proposed solution For a Dive whose owner has explicitly marked it public/embeddable, provide a no-backend embed. Any of these would solve it: - An "Embed" button in the Dive UI that produces a ready-to-paste iframe snippet pointing at an embeddable, framing-allowed URL (relaxed frame-ancestors for public Dives). - A signed, read-only, public embed token baked into the snippet at publish time, so no runtime session-minting server is needed. - An oEmbed endpoint so platforms can auto-expand a Dive link into the live embed. Constraints I would happily accept: - Persistent MotherDuck branding and a "Made with MotherDuck" link in the embed. I want the attribution, not to hide it. - Read-only, public-data-only, with per-Dive rate limiting and the ability to revoke or unpublish. - Available on free/Pro tiers since it is public data and public promotion. Why this benefits MotherDuck Every embedded public Dive is a branded, interactive ad for MotherDuck running on someone else's site, with attribution. The current friction means those Dives get screenshotted and linked instead of embedded, so the brand impression and the live-query demo never leave MotherDuck's domain. Lowering the barrier to embed turns every public Dive author into a distribution channel. Acceptance criteria - I can take a public Dive and, with no server and no paid plan, paste a snippet into a static HTML page and see the live, interactive Dive render. - The embed shows MotherDuck branding. - I can revoke/unpublish to kill the embed. Written by Claude Opus 4.8, verified and edited by Will Hea

Two related asks: 1. Expand the published-Dive import allowlist to cover network-graph / 3D libraries — e.g. react-force-graph-2d/3d, three, or a sanctioned graph lib like reactflow / @visx/network. Today the runtime resolves only react, @motherduck/react-sql-query, recharts, d3, and lucide-react. 2. Enforce the allowlist in the local preview harness (or surface it via a build/lint check), so an unsupported import fails at build time instead of at publish. Why it matters: I built an NFL coaching-tree Dive as a force-directed graph using react-force-graph. It built and looked finished in the local .dive-preview/ Vite harness — because that harness is a normal Vite app that can npm install anything. Only at publish did I hit the fixed runtime allowlist: the graph library was unresolved and the Dive crashed. The guide says "what you preview is what gets saved," but preview doesn't actually enforce the runtime allowlist, so the failure surfaces only after the work is done. I ended up rewriting the whole renderer by with Claude by hand-rolling the force layout and projection onto a plain <canvas> using only React and the allowed d3 math. Even without expanding the allowed libraries, enforcing the allowlist in preview would have let me know I was going down the wrong path. Published Dive for reference: https://motherduck.com/dive-gallery/dives/nfl-coaching-tree *Written by Claude Sonnett 4.8, verified by Will Hea

Deleting a cell currently requires going into the cell menu and selecting the Delete entry, or opening the command palette and selecting "Delete current cell". Preferably there'd be a dedicated keyboard shortcut to delete a cell, or the option to auto-delete emptied cells on blur.

As of now attempting to use FiveTran Transformations with dbt Core with MotherDuck as the Destination shows "This destination does not support dbt Core"

Role-based access control

Would be super useful for in-notebook documentation to be able to create markdown cells.