MCP server · 41 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 scoped key per agent, 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.
This server is the other shape: the credentials live in the deployment, the agent gets a key, and the key is the thing you scope, 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.
Keys are shown once, stored Argon2id-hashed, pinned to one workspace, and carry hierarchical scopes — read, execute, author (admin is for people, never issued to a key). A key's scopes can never exceed its creator's at issue time.
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 user-supplied — GPL-2.0 with FOSS exception
ORACLE · com.oracle.database.jdbc:ojdbc11
Driver user-supplied — 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 surface
Discovery, authoring, execution and result reading — the full lifecycle. 25 of them read; 16 can write, and those are the ones the audit log flags with mcp.tool.write.
7 tools — every name, its scope and whether it writes is listed on the tools page.
7 tools — every name, its scope and whether it writes is listed on the tools page.
8 tools — every name, its scope and whether it writes is listed on the tools page.
3 tools — every name, its scope and whether it writes is listed on the tools page.
1 tools — every name, its scope and whether it writes is listed on the tools page.
4 tools — every name, its scope and whether it writes is listed on the tools page.
4 tools — every name, its scope and whether it writes is listed on the tools page.
2 tools — every name, its scope and whether it writes is listed on the tools page.
2 tools — every name, its scope and whether it writes is listed on the tools page.
3 tools — every name, its scope 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 — 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, 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, writing a node's output 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 — one checkbox, 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.