MCP server · 61 tools · eight engines · AGPL-3.0
MCP server for SQL databases
Postgres, Oracle, SQL Server, MySQL, H2, DuckDB, SQLite and dp-lake behind one MCP endpoint: read-only by default, one key per person that carries their role, every call written to an audit log. Self-hosted, AGPL-3.0.
The fast way to give a coding agent database access is to paste a connection string into a config file. It works on the first afternoon and creates four problems you keep. An MCP database server, one endpoint the agent talks to instead of the database, is the shape that avoids all four, and the rest of this page is what that server has to do to be safe.
This server is the other shape: the credentials live in the deployment, the agent gets a key with its own role, chosen when a person creates it and never more than theirs, and the key is the thing you revoke and audit.
What "governed" means here
A datasource flagged read-only refuses the three write-shaped uses in the pipeline contract: a DML node's source, a DDL node's source, and any node writing its output back to a datasource. The check runs at save time and again at execution time against the live row, so flipping the flag takes effect on the next run, not on the next cache expiry.
The flag is contract, not containment: the documented pattern is a SELECT-only database user for any datasource whose data must not change. The flag gives the agent a fast, machine-readable refusal; the credential gives the guarantee. The demo's own datasources have both.
An MCP key is created on the Keys page by a member whose role may create one, and it carries the role that creator chose for it: author, promoter or workspace admin. It is stored as an Argon2id hash, pinned to that workspace, and it acts as an identity of its own. Instance administration stays with signed-in people and is never granted to a key. Later changes to the member's role do not change the key's role; narrowing or rotating one means revoking it on the Keys page and creating another.
Revoke one agent's key and that agent stops working within about a minute, the validation cache's TTL. No shared password to rotate, and nobody else is interrupted.
The dispatcher writes mcp.tool.called for every call and mcp.tool.write for every mutating one, into the same audit log that carries logins, key issuance and datasource decryptions.
/mcpThe endpoint accepts DP-API-Key or Authorization: Bearer dpk_… and rejects browser session cookies outright. A browser-embedded MCP client authenticates like any other agent. There is no cookie path to borrow.
Datasource passwords are AES-256-GCM encrypted in the metadata database with the datasource name bound as additional authenticated data, and the app refuses to start without a valid key.
A pipeline that reads across engines stages each result set into an in-memory database created for that one execution, joins there, and destroys it when the execution ends. How the staging join works.
Pick your engine
One server speaks all eight. Each page carries that engine's dialect constant, its JDBC driver and license, whether the driver ships in the published image, and the client config to paste.
POSTGRES · org.postgresql:postgresql
Driver ships in the published image
MSSQL · com.microsoft.sqlserver:mssql-jdbc
Driver ships in the published image
MYSQL · com.mysql:mysql-connector-j
Driver you supply; its license is GPL-2.0 with FOSS exception
ORACLE · com.oracle.database.jdbc:ojdbc11
Driver you supply; its license is OTN
SQLITE · org.xerial:sqlite-jdbc
Driver ships in the published image
DUCKDB · org.duckdb:duckdb_jdbc
Driver ships in the published image
H2 · com.h2database:h2
Driver ships in the published image
LAKE · org.duckdb:duckdb_jdbc
Driver ships in the published image
The tools
Discovery, authoring, execution and result reading: the full lifecycle. 34 of them read; 27 can write, and those are the ones the audit log flags with mcp.tool.write.
7 tools. Every name, its permission and whether it writes is listed on the tools page.
8 tools. Every name, its permission and whether it writes is listed on the tools page.
8 tools. Every name, its permission and whether it writes is listed on the tools page.
3 tools. Every name, its permission and whether it writes is listed on the tools page.
1 tools. Every name, its permission and whether it writes is listed on the tools page.
4 tools. Every name, its permission and whether it writes is listed on the tools page.
4 tools. Every name, its permission and whether it writes is listed on the tools page.
2 tools. Every name, its permission and whether it writes is listed on the tools page.
6 tools. Every name, its permission and whether it writes is listed on the tools page.
2 tools. Every name, its permission and whether it writes is listed on the tools page.
6 tools. Every name, its permission and whether it writes is listed on the tools page.
3 tools. Every name, its permission and whether it writes is listed on the tools page.
7 tools. Every name, its permission and whether it writes is listed on the tools page.
All of them over one endpoint: POST {host}/mcp, Streamable HTTP, stateless by default.
Asked before
Postgres, Oracle, SQL Server, MySQL, H2, DuckDB, SQLite and dp-lake, behind one MCP endpoint over all eight, each with its own dialect adapter, and any of them marked read-only where writes must never happen. The dialect catalog with drivers and licenses is docs/datasources.md §4.
No. Datasource credentials are encrypted at rest in the metadata database and never returned, not through a tool, not through the UI and not in a pipeline's JSON. The agent holds a key to the server; the server holds the credentials. Credential storage is docs/datasources.md §7.
The datasource's read-only flag refuses the write-shaped uses, a DML node's source, a DDL node's source and a node's output written back, at save time and again at execution against the live row, and the documented pattern pairs it with a SELECT-only database user. The flag's semantics are docs/datasources.md §5.7.
Revoke its key on the Keys page, and the agent stops working within about a minute, the validation cache's TTL. No shared password to rotate, and nobody else's key is touched. Revocation and the validation cache are docs/auth.md §11.4.
Yes: the dispatcher writes mcp.tool.called for every call and mcp.tool.write for every mutating one, into the same audit log that carries logins and key issuance, with the key and the tool, never the SQL text or the row data. The audit log is docs/auth.md §10.
One command brings up the server, the demo sources and the pipelines that join them. The afternoon you spend on the demo is the cheapest way to find out what governed agent access feels like.