From One Tool to a Context Engineering Platform

▶ Watch (0:03)

MotherDuck built a cloud data warehouse on DuckDB. Every user gets their own compute instance. That isolation makes agentic SQL access safe. Till Döhmen started the MCP server with a single tool. It worked with careful prompting. But DuckDB SQL syntax deviates from PostgreSQL, especially for schema exploration. Clients sent queries written for Postgres. Döhmen added more tools to help agents explore schemas. He also added a sub-agent tool that answers questions from MotherDuck documentation. The server grew from one tool to a context engineering system.

Dives: Live Data Visualizations in the Chat

▶ Watch (3:37)

Users generated static React artifacts from the MCP server. Data was hardcoded inside them. Döhmen saw the limitation. MotherDuck has a TypeScript SDK for live queries. He built a tool called the dive guide. It teaches the agent how to wire up live queries through the SDK. The agent saves the result as a dive in MotherDuck. Dives are React apps with live querying. Users built earthquake maps and a computer game where blocks are real data. The creators could not write TypeScript or SQL. Döhmen called this a huge unlock.

Why MCP and Where It Breaks

▶ Watch (8:11)

MCP provides smooth authentication and a native distribution mechanism. Users add MotherDuck from the app directory. MCP apps bring UI elements into the chat. Döhmen wants to expose more of MotherDuck’s web UI through MCP. But the context engineering model breaks with scale. A client connected to 25 MCP servers with 200 tools cannot load all tool descriptions up front. Tool search and other discovery mechanisms replace the initial load. Döhmen said it becomes difficult to reason about when the client sees a tool description. Multi-step workflows like the dive guide depend on that ordering.

The Wish List: Client Feedback and Tool Chaining

▶ Watch (13:07)

MCP servers push tools to clients. There is no back channel. Döhmen wants to know which client is calling the server. Claude Code gets a different dive guide than Claude Web because Code has a local file system. He wants a way to chain tool calls without forcing users into MCP gateways. The spec defines initial instructions, but Claude Web ignores them. Döhmen also wants client-specific UX testing. Automated evaluations on a generic agent harness do not catch errors in Claude or ChatGPT. Observability alone does not solve the problem.

Q&A

What is the most important thing dives unlock for customers? Dives fill the gap between static BI dashboards and ad-hoc questions not significant enough to justify a new dashboard. ▶ Watch (17:45)

How do you evaluate MCP server quality? MotherDuck runs automated evaluations against agentic analytics benchmarks, but results depend heavily on the specific agent harness used. ▶ Watch (20:29)

Notable Quotes

I think what what what really matters for us in the end is uh we want to get to where the users typically are which is clawd or chatgpt Till Döhmen · ▶ Watch (8:31)

it’s very difficult now to reason about when when the client is going to see your tool description and that makes it also difficult to build these kind of multi-step workflows Till Döhmen · ▶ Watch (11:41)

it’s those things were built by people that can neither write TypeScript code nor can write SQL really. Uh and this is a huge huge unlock. Till Döhmen · ▶ Watch (6:15)

Key Takeaways

  • MotherDuck’s MCP server evolved from one tool to a suite for context engineering.
  • Dives let non-developers build live data visualizations without writing code.
  • The MCP protocol lacks a client-to-server feedback channel for tool chaining.

About the Speaker(s)

Till Döhmen is AI Lead at MotherDuck, where he focuses on building agentic experiences for data analytics. He designed and built the MotherDuck MCP Server, enabling AI agents to query and analyze data through Claude, Cursor, and other MCP clients. Till is also a final-year PhD candidate.