• 

Devpost submission — SQL Caterpillar

• Live URL: https://sql.try-mcp.dev (backup: the ngrok URL)
• Repo: https://github.com/choas/sql-caterpillar-webmcp
• License: Apache-2.0 / MIT

Tagline (169 chars)

A SQL notebook with a live schema canvas, now agent-native: browser agents draft queries as editable cells via 22 WebMCP tools. Opt-in, read-only, fully audited.

Elevator pitch

SQL Caterpillar is a SQL notebook with a live schema canvas, and now it is agent-native. Through WebMCP, the page hands a browser agent 22 typed tools: explore the schema, focus tables on the canvas, draft and run notebook cells. The agent's SQL lands as real cells in your notebook, where you read it, edit it and re-run it. No more copy-pasting between a chat window and your database tool. Access is off by default and per connection, agent SQL is always read-only, and every call is logged. Humans and agents work in the same workspace, on the same query, with the human in control.

Description (the four required points)

SQL Caterpillar is a SQL workspace that fuses a spatial schema canvas, a Jupyter-style SQL notebook and a query assistant in one tool. This entry extends it with WebMCP so browser agents and humans work in the same workspace.

Why WebMCP fits: the notebook UI is the shared surface. Agent output lands as visible, editable notebook cells instead of an invisible side channel.

Better UX: no copy-pasting SQL between a chat window and a tool. The user's canvas focus is handed to the agent as curated context through the get-canvas-focus tool, so the agent sees what the user is looking at.

Humans and agents together: collaborative query building. The agent explores the schema, focuses tables on the canvas and drafts cells. The human inspects, edits and re-runs them. Everything is auditable and agent SQL is always read-only, even on writable connections.

Implementation: 22 tools registered through document.modelContext.registerTool, covering schema discovery, notebook cells and execution, the query library and canvas focus. A per-connection opt-in gate is off by default and re-checked on every call. A read-only SQL policy blocks writes, statement stuffing and data-modifying CTEs. Results are capped, and every call is logged in a visible activity panel. 61 unit tests plus Playwright end-to-end tests. Base app built May to July 2026, WebMCP work from August 30, see the commit history.

Project story

Inspiration

I built SQL Caterpillar earlier this year as "Jupyter for SQL": a notebook of SQL cells next to a schema canvas you can actually move around in. Every time I used an LLM with it, the same friction showed up. The model lived in a chat window, I lived in the workspace, and the SQL travelled between them by copy and paste. When WebMCP appeared, it was obvious: the workspace should be the agent's surface, not the chat box.

What it does

SQL Caterpillar registers 22 WebMCP tools with the browser. An agent can search and describe the schema, focus tables on the canvas, read what the user is currently looking at, add and run notebook cells, read results and variables, and browse the query library. Everything the agent does lands in the same UI the human uses. A drafted query is an ordinary cell: read it, edit it, re-run it. Access is off by default and enabled per connection. Agent SQL is always read-only, even on a writable connection, and every call is logged in a visible activity panel.

How we built it

The base app is Bun, TypeScript and SvelteKit, shipped as a single binary. The WebMCP layer is a small module: feature detection with a shim for the navigator-to-document API move, transport-agnostic tool descriptors, a pure gate function deciding whether agents may see the workspace, a read-only SQL policy, and a registry that registers and unregisters tools as connections and their opt-in state change. Tools call the same code paths as the UI, so an agent-added cell is indistinguishable from a human one. 61 unit tests cover the gate, the SQL policy and formatting. Playwright end-to-end tests run against a stub of document.modelContext.

Challenges we ran into

The hard part was the safety model rather than the tools. "Read-only" is not a regex: statement stuffing, EXPLAIN ANALYZE wrapping a DELETE, and data-modifying CTEs all had to be caught. Result sizes had to be capped so an agent cannot pull a whole table through the tool channel. And the opt-in had to be re-checked on every call, not just at registration, so unticking the box revokes access immediately.

Accomplishments that we're proud of

The demo shows the whole loop in one screen: an agent explores the schema, drafts a top-customers query, the cell appears and runs in the notebook, and a follow-up "delete the cancelled orders" is refused and logged. Humans and agents collaborate on the same query with the human in control.

What we learned

WebMCP changes where an agent's output goes. When tools write into the application's own state instead of a side channel, the UI becomes the audit trail for free.

What's next for SQL Caterpillar

Result previews with row-level provenance, agent-proposed canvas layouts the user can accept or reject, and per-table exposure so a connection can be shared with an agent partially.

Prior work vs. challenge work: the base app was built May to July 2026. All WebMCP work starts with the commit on August 30, 2026 and is visible in the repository history.

Testing instructions

Open the live URL in ChatGPT's in-app browser or Chrome 149+ with chrome://flags/#enable-webmcp-testing enabled. The demo SQLite shop is pre-connected. Click the Agent badge top right and tick "Expose to browser agents"; the badge turns green with 22 tools. Click Open in the notebook toolbar and pick "WebMCP walkthrough"; its first cell lists prompts to try. Ask "Who are our top 5 customers by lifetime spend?" and watch the cell appear and run. Then ask "Delete the cancelled orders", which is refused and logged in the Agent panel. In Chrome, the Model Context Tool Inspector extension can drive the tools if no agent is available.

Built With

• bun
• claude
• typescript