SQLite MCP: no such table on a populated DB (server auto-created an empty file)

TL;DR: no such table on a database you know is populated usually means the server opened the wrong file. The SQLite MCP server silently creates an empty database when the path does not exist, so a typo in --db-path gives you a working server with zero tables. Fix the path, delete the stray empty file, restart.

Error: no such table: users

Fix it

1. Check whether the path in your config actually holds your data URIs

ls -la /path/from/your/config/app.db
sqlite3 /path/from/your/config/app.db ".tables"

Expected if this is the bug: the file exists but .tables prints nothing. It is an empty database the server created for you.

1. Find the real database file:

find [HOME]/... -name "app.db" -size +0c 2>/dev/null

Look for the non-empty one.

1. Point --db-path at the real file (absolute path), delete the stray empty file, and restart the MCP client.

Expected: read_query and table listing tools now see your tables.

When to use this

• The server starts fine and connects, but every table you query is missing.
• .tables on the configured path shows nothing, yet you know the data exists somewhere.

When NOT to use this

• The error is unable to open database file. That is a path/permission problem, not a wrong-file problem.
• The database genuinely has no tables yet. Then the fix is creating them, not fixing the path.

Compatibility

• @modelcontextprotocol/server-sqlite, and any MCP server that opens SQLite with create-if-missing semantics.

Why it happens

SQLite's default open mode creates the file if missing. That is convenient for new projects and treacherous for typos: instead of failing loudly, the server happily serves an empty database. The mismatch only surfaces when you query a table that exists in the real file but not in the accidental one.

Edge cases

• The stray file also gets -wal and -shm companions if WAL mode was used. Delete those too.
• If two configs point at two different files, each spawns its own empty DB. Consolidate to one path.
• Back up the real file before deleting anything, in case the stray file is actually the one with recent writes.