Read-only by default · one scoped key per agent · every call audited
DUCKDB dialect
Give Claude Code, Cursor or any MCP client a a DuckDB connection it cannot abuse: read-only by default, one scoped key per agent, every call audited, and the database password never leaves your deployment.
Driver and dialect
| Dialect constant | DUCKDB |
|---|---|
| JDBC driver | org.duckdb:duckdb_jdbc |
| Driver license | MIT |
| In the published image? | Yes — bundled |
| JDBC URL shape | jdbc:duckdb:/data/warehouse.duckdb |
Copy, paste, done
The endpoint is POST {host}/mcp over Streamable HTTP, and the credential is an API key in
DP-API-Key or Authorization: Bearer dpk_…. Session cookies are rejected there,
so the config is the same whichever engine you registered — the engine is a datasource, not a server.
claude mcp add --transport http datapipelines https://your-host/mcp \
--header "DP-API-Key: dpk_<id>.<secret>"~/.cursor/mcp.json{
"mcpServers": {
"datapipelines": {
"url": "https://your-host/mcp",
"headers": { "DP-API-Key": "dpk_<id>.<secret>" }
}
}
}.vscode/mcp.json{
"servers": {
"datapipelines": {
"type": "http",
"url": "https://your-host/mcp",
"headers": { "DP-API-Key": "dpk_<id>.<secret>" }
}
}
}The endpoint and the header are ours and specified above; the surrounding file shape belongs to each client and is what its own documentation prescribes. The full walkthrough covers minting the key and checking that the tool list came back.
Registering the database
Flag the datasource read-only and the three write-shaped uses — a DML node's source, a DDL node's source, and writing a node's output back to it — are refused at save time and again at execution time, against the live row.
The flag is contract; the database credential is containment. For anything that must not change, create a SELECT-only user — the documented pattern, and what the demo's own datasources run under.
AES-256-GCM in the metadata database, with the datasource name bound as additional authenticated data. The application refuses to start without a valid encryption key.
datasources_get_schemas, datasources_get_tables, datasources_get_columns and datasources_preview_rows exist so the agent grounds its SQL in your real schema instead of guessing at it. What it cannot do is create a datasource: no credential travels through an agent, so a person registers the connection and the agent uses it by name.
Asked before
That is the page's driver-matrix table above: some engines' drivers are bundled, and the ones whose licenses we do not redistribute are user-supplied — registering a datasource whose driver is absent fails at save time with datasource.driver_not_loaded. The matrix is docs/deployment.md §3.5.
It does not reach the engine at all: the agent talks to the MCP endpoint with an API key in DP-API-Key or Authorization: Bearer dpk_, and the server connects to the database with the credentials it holds. Session cookies are rejected on /mcp. The authentication is docs/mcp-server.md §4.1.
No — the credential is AES-256-GCM encrypted at rest with the datasource name bound as additional authenticated data, and it is never returned through a tool or the API. The agent references the datasource by name. The encryption is docs/datasources.md §7.1.
No — no credential travels through an agent, so a person registers the connection and the agent uses it by name. What the agent gets instead is the read side: schemas, tables, columns and preview rows over the introspection tools. The tool list is docs/mcp-server.md §6.1.
Register the datasource, mint a scoped key, paste one config block — the setup page walks all of it, and the demo stack gives you a safe place to try the whole loop first.