Query MotherDuck Prerequisites An established MotherDuck connection (or an active MotherDuck MCP server) Target database and tables identified Default Posture When MotherDuck MCP is available and the SQL answers a business question, call get query guide first, then read only the relevant Guide topics and validate their claims against the live schema. Write DuckDB SQL, not PostgreSQL SQL, even when using the PG endpoint. Prefer fully qualified "database"."schema"."table" names; they are required once more than one database or share is attached. Preserve result grain and check join cardinality before optimizing or materializing a query. Filter early, aggregate early, and prefer serving tables or summaries for repeated reads. Keep SQL obvious, multi line, and explicit about grain, filters, and output shape. Treat DDL, DML, ATTACH , DETACH , recovery commands such as CREATE SNAPSHOT , ALTER DATABASE ... SET SNAPSHOT , UNDROP DATABASE , and lifecycle commands such as SHUTDOWN as writes. Use the MotherDuck MCP query rw tool when the user's change request authorizes the write. Ask for confirmation only when the action is destructive, externally visible, or outside the stated scope. Tag long lived integrations with custom user agent when the connection path supports it; the tag appears per query in the Duckling Overview and in query history. For classification, scoring, routing, or yes/no judgments over text or images, use prompt jev() : it returns typed probabilities and labels, bills input tokens only, and batches rows. Use prompt() for generated text or open extraction with struct or json schema . Both are per row billable calls: test on a small LIMIT , store results in a table, and rerun only NULL rows. Workflow 1. Confirm the actual tables, columns, and grain before writing SQL. 2. Load relevant Guide context when MCP is available, without treating it as a substitute for schema inspection. 3. Write the query in SQL first, then wrap it in Python or TypeScript only if needed. 4. Use DuckDB native patterns when they simplify the query; a simple lookup does not need a CTE or a materialization. 5. Verify result shape and key aggregates. When performance is part of the request or execution shows a problem, check EXPLAIN ANALYZE and md information schema.query history ( wait time , bytes spilled to disk , instance type ) before changing the query or the Duckling size. 6. Materialize expensive repeated queries into serving tables or light views when warranted. References Read only the reference sections needed for the current task. Read references/QUERY PLAYBOOK.md for DuckDB query patterns, exploration SQL, performance rules, common analytical shapes, and common mistakes Read references/AI FUNCTIONS.md when a query calls prompt jev() , prompt() , or embedding() Read references/PERFORMANCE.md when a query is slow, spills, runs out of memory, or a Duckling looks undersized Related Skills Load related skills only for missing capabilities; reuse established context. motherduck connect for session setup motherduck duckdb sql for syntax and function reference motherduck explore for understanding the source schema before writing queries motherduck manage guides when semantic definitions or reusable query rules need to be read or maintained

motherduck-query