scriptease.dev
Connecting 50 Databases to an AI
The best idea in my database tool is stolen. I found it in a tool that edits Word documents.
The trick worth stealing
The tool is called OfficeCLI — a free project on GitHub, the public square where programmers share their code, that lets an AI create and edit Office documents. It has one pattern that wouldn't leave my head.
A Word file looks like one document, but under the hood it's a packed archive full of bookkeeping — open it, change one word, close it, and you've unpacked and repacked the whole box for a single spoon. Most tools do exactly that, for every single edit. OfficeCLI doesn't. The AI opens a document once, and from then on a small helper program keeps it sitting in memory, ready. Every edit after that is scoped to the open document and lands instantly — no unpacking, no repacking. When the AI is done, it closes the document and the helper packs the box once.
I read that and thought: this is the ideal pattern to build my own tool on.
Because databases have exactly the same problem.
Don't repeat yourself
At work, my AI assistants look things up in databases all day — find this order, check that stock level, trace what happened to a payment. A database doesn't just answer whoever walks up to it. First you connect: prove who you are, agree on a dialect, get a session. It's a phone call — and dialing takes real time before anyone says a word.
A command-line tool — a CLI, one of those short typed commands an AI can fire off — normally lives and dies in a blink. Every question redials the phone. Connect, ask one thing, hang up. Connect, ask the next thing, hang up. My first setup paid that toll on every single query, and an AI asks a lot of single questions in a row.
I went looking for an existing tool that keeps the line open between short commands, and came back empty-handed: no off-the-shelf tool does this. The ones that keep a connection alive want you to stay inside their own interactive window; the ones an AI can call in a blink redial every time.
So I built the OfficeCLI pattern for databases: a small helper that stays running in the background and keeps named connections open, plus short commands that borrow those connections. The AI says open once — "connect to this database, call it shop" — and from then on every query --alias shop rides the warm line. close hangs up.
I called it jdbc-cli, after JDBC — Java's standard adapter for talking to databases, the plumbing it used inside — and it spoke to the three databases I actually deal with: MySQL, PostgreSQL, and SQLite. I used it a bunch — mostly MySQL for work, SQLite for connecting to our iOS apps.
First run needed a setup
Then I shared it with a colleague, and the tool met its first stranger.
The colleague had a brand-new computer. My tool was written in Java, and Java programs don't run on their own — they need the Java runtime installed first, like a game that ships without the console. On my machine, with years of accumulated setup, everything just worked. On a fresh machine there was no Java, none of the invisible scaffolding I'd stopped seeing. What was "install and go" for me was a clunky afternoon for him.
The times of "write once, run anywhere" — Java's famous promise — are apparently over. But there's a new tool in town…
Connecting to databases on the Go
I rewrote the whole thing in Go — a programming language whose party trick is producing a single self-contained file. Nothing to install first, nothing to hunt down. You copy one file to a new machine and it runs. The same helper-in-the-background design, the same commands, just nothing to set up around it.
With Java gone, the old name told a lie, so jdbc-cli became database-cli, on GitHub for anyone: github.com/scriptease/database-cli.
I didn't get rid of the old Java-era address format. Not because I was lazy but because AIs are trained on decades of these addresses and write them correctly on the first try.
The password stays hidden
There was one rule I built in from the start: the AI never gets to see a password.
An AI conversation is a transcript. Anything written into it is stored locally and uploaded to the AI's servers with every exchange. So database-cli refuses the easy route. Passwords never appear. The tooling makes sure of it — the tool fetches the secret itself, from the Mac's Keychain or from 1Password, the password manager; the AI only ever names which entry to use.
You can harden it even more: open the connection yourself, outside the AI's session, and let the AI merely use it — then it never even comes near the credentials.
And for pure look-don't-touch work, a connection can be opened read-only — the database itself will refuse any command that changes data, no matter what the AI meant to do.
Fifty databases and counting
Here's where the pattern really pays off.
At work we don't only have one database. I always said "fifty" as a figure of speech, so this morning I actually counted. Across our different server types the configs name 33 distinct databases, another 34 machines run their own MySQL, and my laptop holds 20 more locally. That's 87 — and many exist again in variations like test, dev and alpha, so the full number of connections is well past a hundred. The fifty in the title are just the ones I might actually open, and even that is conservative.
And that count only covers databases with an address. SQLite databases are just files — so when I'm debugging an iOS app, the AI can open the app's own little database straight out of the simulator — the pretend iPhone on my Mac — on a whim. Nobody's counting those.
On a given morning I can ask for one in prose: "open the test database for customer X."
The standard way to give an AI access to things is called MCP — think of it as a wall socket you install for each thing the AI should be able to reach. It's a fine standard, and it has no good answer for fifty of anything. One socket wired to fifty databases is a monster to set up and keep current. Fifty separate sockets is absurd. Either way you're maintaining a directory of connections that mostly sit unused.
database-cli sidesteps the whole question. There's nothing to configure per database. The AI works out the address from the project it's already looking at, asks the password manager for the right entry by name, opens the connection on demand, uses it, closes it. Fifty databases need zero standing setup — just the one little helper, dialing whichever number today's question needs.
Databases that need another hop — fenced off inside a cluster or behind a locked gateway — get the same treatment: the surrounding tooling opens a tunnel, and database-cli dials through it like the database was sitting next door.
Sometimes I want to look myself
Not every database moment is a question for the AI. Sometimes I want to browse with my own eyes — click through tables, scroll, poke around.
So at work, database-cli is wrapped in a skill — a playbook the AI reads that covers both kinds of request. Ask a question, and it runs database-cli and answers. Say "open the shop database," and it launches a database app instead — Beekeeper Studio, Sequel Ace, SQLPro — with the connection already open, ready to browse. The AI decides which of the two I want from how I ask. Both paths start from the same JDBC address, and the app launch is wired through a script too, so even there the passwords stay hidden.
Daily use
That was three months ago. The session logs say my assistants have reached for it in 86 working sessions since — almost one a day. It's how they look things up now, one warm connection at a time.
If you want the same thing, the tool is on GitHub: github.com/scriptease/database-cli. One self-contained file, a background helper, open / query / close, passwords never in the chat. And if you build tools for AI assistants, steal the idea the way I did: make everything a CLI the AI can use.
This setup beats any curated list of saved connections inside one app. The AI works out the rest.