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.

2. Find the real database file:

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

Look for the non-empty one.

3. 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.

The @modelcontextprotocol/server-sqlite creates the SQLite file at --db-path if it does not exist (standard SQLite open behavior), which means a typo in the path produces a working server against an empty database instead of an error. The symptom reported by users is queries failing with no such table on a database they believe is populated. The fix is verifying the path points at the real file and removing the accidentally created empty file. This behavior is inherent to how the server opens its database.