MCP Server for SQLite: The Real Options

There is no official first-party MCP server for SQLite anymore — the reference implementation was archived — so the real choice is between a handful of community servers that speak SQLite well. For most people the answer is DBHub: one binary, read-only guardrails, and only two tools so it barely dents your context budget. This post covers when to pick it, when to reach for something else, and the minimal config to get a SQLite file talking to Claude, Cursor, or VS Code.

All four servers here run locally over stdio, which matches the wider pattern that roughly 90% of MCP servers ship as local stdio processes rather than remote HTTP endpoints. That's a good thing for SQLite: your database is a file on disk, so there's no reason to route it through a network hop.

The short answer: use DBHub for SQLite

Run DBHub unless you have a specific reason not to. It's a zero-dependency TypeScript server that connects to SQLite (plus Postgres, MySQL, MariaDB, and SQL Server) through one interface, and it deliberately exposes just two core MCP tools instead of a dozen. That matters more than it sounds — every tool a server registers eats into a client tool budget that's effectively capped around 40 tools before models start mis-selecting. A two-tool server leaves room for everything else.

DBHub also ships the guardrails you actually want against a database: read-only mode, row limiting, and query timeouts. Point it at a .db file and it can explore the schema and run SELECTs without you worrying that a hallucinated DELETE wipes a table.

Here is the full stdio config — swap in your file path:

{
  "command": "npx",
  "args": [
    "@bytebase/dbhub@latest",
    "--transport", "stdio",
    "--dsn", "sqlite:///absolute/path/to/app.db",
    "--readonly"
  ]
}

Use an absolute path in the DSN. Relative paths resolve against wherever your MCP client spawns the process, which is rarely where you think it is.

The full field: how the four SQLite servers differ

All four connect SQLite over stdio and none require auth for local use. Where they diverge is scope, runtime, and how many tools they dump into your context.

Server	Runtime	Install	Tools exposed	Best for
DBHub	Node / npx	npx @bytebase/dbhub	2	Default choice; multi-DB, read-only guardrails
Anyquery	Go binary	brew install anyquery	3 (listTables, describeTable, executeQuery)	Querying files + 40+ apps alongside SQLite
MCP Alchemy	Python / uvx	uvx mcp-alchemy	schema + query tools	SQLAlchemy shops, exotic dialects
CentralMind Gateway	Go / Docker	docker run …/gateway	generated per-endpoint	Governed, PII-redacted access for a team

A few opinions on that table. Anyquery is a SQLite-based query engine at its core, so if your goal is to run SQL over CSVs, JSON, Parquet, and apps like Notion or Chrome history as well as your .db file, it's the most interesting pick — it exposes exactly three tools and treats everything as a table. MCP Alchemy is the escape hatch: because it rides SQLAlchemy, it reaches Oracle, MS SQL, CrateDB, Vertica, and anything else with a dialect, so reach for it only when DBHub doesn't support your other databases.

What to skip

Skip CentralMind Gateway for a personal SQLite file. It's a strong server, but it's built for a different job: it runs a one-time LLM discovery pass over your schema to generate a gateway.yaml, then exposes each endpoint as an MCP method, with PII detection, row-level security, and OpenTelemetry auditing on top. That governance is worth it for a shared production database; it's pure overhead for a 40 MB analytics file on your laptop.

Also skip the generic "filesystem" servers for this. Reading a .db file as bytes gives the model nothing — SQLite is a binary format. You want a server that actually opens the database and speaks SQL.

And don't confuse a SQLite MCP server with something like codebase-memory-mcp, which uses a local database to persist a code knowledge graph. That's a great tool for coding agents, but it manages its own store — it won't let you query an arbitrary SQLite file you point it at.

Wiring it up and staying safe

Add the config block to your client's MCP settings and restart the client — the mechanics are the same for Claude Desktop, Cursor, and VS Code, and the walkthrough in how to add an MCP server covers each one. Confirm the server registered by asking the model to list tables; if it can name your tables, the connection is live.

Two safety rules for database servers specifically. First, run read-only whenever you can — DBHub's --readonly and its row-limit and timeout flags exist precisely so an agent can't run away with your data. Second, keep the transport on stdio. DBHub's HTTP transport binds to 0.0.0.0 by default and does not authenticate clients, so an accidental HTTP launch can expose your database to the whole network. For a local SQLite file there is no upside to HTTP — stay on stdio.

If you want to compare these against other database options or generate a config for a client you're not sure about, the best MCP servers list and the config generator are the fastest next steps; the capabilities page breaks down which servers expose read versus write tools.

Bottom line

For a SQLite file, install DBHub in read-only mode over stdio — two tools, sane guardrails, done. Move to Anyquery if you're also querying files and apps, MCP Alchemy if you need a dialect DBHub doesn't cover, and CentralMind Gateway only when a team needs governed, audited access. Everything else is a distraction.