-
Notifications
You must be signed in to change notification settings - Fork 19
Description
What
Add dbcode-disconnect and dbcode-connect MCP tools that allow agents to programmatically disconnect and reconnect named database connections.
Why (problem/use case)
DuckDB uses exclusive file locking — only one process can hold a write connection at a time. When an AI agent uses dbcode-execute-query to inspect data (e.g., validating a dbt model output), DBCode holds the connection open. Any subsequent build tool (dbt, DuckDB CLI) that needs write access fails with:
IO Error: Cannot open file "...duckdb": The process cannot access the file because it is being used by another process.
Today the only workaround is asking the user to manually click disconnect in the DBCode panel — breaking the agent's autonomous workflow. With dbcode-disconnect / dbcode-connect, an agent could:
- Connect → query to validate results → disconnect
- Run dbt build / DuckDB CLI commands
- Reconnect → query to verify
This is a common pattern in data engineering workflows where agents alternate between querying results and running build pipelines against the same database file.
Additional Context
- This only affects file-based databases with exclusive locking (DuckDB, SQLite). Server-based databases like Fabric/Postgres are unaffected — multiple concurrent connections work fine.
- The existing
dbcode-get-connectionstool already returns connection IDs, sodbcode-disconnect/dbcode-connectcould accept those same IDs. - Suggested signatures:
dbcode-disconnect(connectionId)— close the connection, release file lockdbcode-connect(connectionId)— reopen a previously configured connection
- Ideally
dbcode-execute-querycould also accept anautoDisconnect: trueparameter that closes the connection after returning results, for fire-and-forget validation queries.