DSH plugins for Database

Database plugins let the agent talk to real stores instead of pasting CSV exports into a prompt: SQL clients with schema introspection, local embedded databases used as memory backends, cache layers, and artifact stores. In this directory the practical split is local embedded stores (SQLite graphs, sandboxed project databases) versus anything that holds a live connection string to a remote engine.

Read-only credentials are the sane starting point. Prefer plugins that show the query they are about to run, limit row counts by default, and keep connection strings out of the model context. A plugin that writes to production because the agent “thought it should” is a category failure, not a power feature.

How to evaluate

Ask where data lives, who can mutate it, and what leaves the machine. Local SQLite backends keep the blast radius inside a profile directory; remote SQL clients inherit your network and your credentials. Check whether the plugin logs executed statements, whether schema introspection is bounded, and whether exports or dumps can be triggered without an approval step.

For memory-shaped plugins that use a database underneath, separate two questions: is retrieval bounded, and are writes reviewable? A graph that grows without an audit surface will eventually be wrong and unreadable.

What good looks like

A strong database plugin defaults to read-only, shows the statement before it runs, and caps result sizes so a wide table cannot flood the context window. Schema facts are explicit. Writes, when they exist, are either behind an approval gate or confined to a local artifact file you can inspect. Connection secrets stay in config the model does not echo back.

Treat “the agent can query Postgres” as a capability claim, not a workflow. The useful plugins are the ones that make the query path as reviewable as a file edit.

Common failure modes

The usual failure is write access granted by default because a tutorial needed an INSERT. The second is pasting a URL with password into the prompt or into tool arguments the transcript stores forever. The third is unbounded SELECT * against wide tables, which burns context and produces confident summaries of the wrong slice.

Local stores versus remote engines

Local embedded databases keep secrets and blast radius inside a profile directory. Remote engines inherit your network, your credentials, and every mistake a write tool can make. Start local. Promote to remote only when the query path is as reviewable as a file edit: statement shown, rows capped, secrets never echoed.

Memory-shaped plugins that sit on a database need both bounds: retrieval must be bounded, and writes must be reviewable. Either missing half is how a graph store becomes wrong and unreadable at the same time.