MotherDuck’s minimal data agent is read-only—but its real perimeter is deployment protection

MotherDuck’s newly published Data Chat Mini is useful because it does not present text-to-SQL as a model-selection problem. The reference app wraps SQL generation in a small control plane: read-only database access, a limited MCP tool surface, a bounded agent loop, structured rendering and telemetry. But its repository also documents a boundary practitioners can easily miss: read-only SQL does not make an unauthenticated data-chat endpoint safe.

The database boundary is deliberately narrow

The workshop describes a plain agent loop capped at 40 iterations, intended to prevent a difficult question from spinning indefinitely. The system prompt tells the model to inspect the schema rather than guess, while a strict chart schema replaces arbitrary HTML output. MotherDuck says the app exposes a tool allow-list rather than the complete MCP surface and records model and tool activity for later review. The workshop recording and written summary present those controls as the system around the model, not as optional production polish.

The Data Chat Mini repository makes the allow-list concrete: query, catalog inspection, catalog search and documentation lookup are available; the read-write query tool is not advertised or dispatched. The code classifies mutating and destructive tools, then rejects tools outside the approved set before execution. The repository recommends a dedicated non-admin, user-scoped token because database grants remain the underlying tenancy boundary.

Read-only is not the same as private

The sharper deployment lesson sits outside SQL. Data Chat Mini has no application-level authentication and uses one server-side personal access token for every visitor. MotherDuck therefore warns that publishing the Vercel URL without deployment protection exposes the token owner’s catalog and personal guides, while also letting visitors consume the shared model budget. Its deployment instructions call for password protection across all deployments—not only previews.

That distinction matters. A read-only endpoint can still disclose schemas and permitted rows, reveal saved context, consume paid inference, or become an unlimited query surface. Database permissions constrain what a successful request may do; application authentication constrains who may make the request at all. They are separate gates.

Telemetry and timeouts finish the minimum stack

The app writes model prompts, completions and tool calls as JSONL, with tooling for run-level cost, latency and token summaries. It also documents two execution ceilings: the streaming route requests up to 300 seconds, while the free Vercel tier can cut long turns at roughly 60 seconds; an individual MotherDuck MCP query is separately capped at about 55 seconds. Those limits make a practical point: bounding loop count alone does not bound wall-clock time or infrastructure cost.

For teams adapting the pattern, the minimum production checklist is therefore four layers: least-privilege database credentials, an explicit MCP allow-list, authenticated application access, and observable resource ceilings. MotherDuck’s demo is intentionally small, but its most valuable lesson is that “read-only agent” describes only one of those layers.