SQLite MCP Server Setup Guide (2026)

How do you connect an AI assistant to a SQLite database over MCP? Run an MCP server that wraps SQLite and point it at a .db file with a --db-path argument, then add that server to your client's mcp.json (or equivalent) as a local command/args entry. The two real options in 2026 are the original reference server (uvx mcp-server-sqlite --db-path /path/to.db), now archived by its maintainers, and the actively maintained @executeautomation/database-server package, which also covers PostgreSQL, MySQL, and SQL Server if you outgrow SQLite.

The archived-server situation, stated plainly

The original SQLite server lived in modelcontextprotocol/servers, then moved to modelcontextprotocol/servers-archived — GitHub marks that repository as archived by its owner, read-only. That doesn't mean the server stopped working; the published package, mcp-server-sqlite on PyPI, still installs and runs. It means the MCP org isn't actively developing or patching it going forward. For a quick local dev database or a one-off analysis task, that's a fine trade-off. For anything you're depending on long-term, know that you're picking up a frozen tool, not a maintained one — check the alternative further down if that matters for your use case.

Quick reference

Option A: The archived official reference server

Prerequisites

Install and verify

uvx runs the package in an ephemeral virtual environment without a permanent install:

uvx mcp-server-sqlite --help

That should print help output describing the --db-path argument. If it errors, confirm uv itself is on your PATH (uv --version).

Add to Claude Desktop

Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "/absolute/path/to/database.db"]
    }
  }
}

Use an absolute path. Restart Claude Desktop.

Add to Cursor

~/.cursor/mcp.json or .cursor/mcp.json, same shape under Cursor's mcpServers key:

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "/absolute/path/to/database.db"]
    }
  }
}

Add to Cline

cline_mcp_settings.json, opened from the Cline panel's MCP Servers icon:

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "/absolute/path/to/database.db"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

See Cline MCP Server Setup for the full config schema.

Running it in Docker instead

If you'd rather not install uv, the server also ships as a Docker image:

docker run --rm -i -v mcp-test:/mcp mcp/sqlite --db-path /mcp/test.db

Note the path inside the container (/mcp/test.db) is different from the host path — the volume mount (-v mcp-test:/mcp) is what makes the database file persist between container runs instead of vanishing when the container exits.

What the archived server actually exposes

Six tools: read_query (run a SELECT), write_query (run INSERT/UPDATE/DELETE), create_table, list_tables, describe_table, and append_insight (adds a note to a running business-insights memo). It also ships one prompt, mcp-demo, that walks an assistant through a guided database-analysis session given a business-domain topic argument, and one resource, memo://insights, a running memo the server updates as it discovers things during a session.

This tool set is intentionally narrow — there's no schema migration tool beyond create_table, and no bulk import/export tool. It's built for "let the assistant explore and query a database," not for managing schema changes as part of a deploy pipeline.

Keeping it updated

Since the repo is archived, there won't be new releases addressing bugs or adding features. If you're pinned to uvx (which always resolves the latest published version unless you specify otherwise), you'll keep getting whatever the last published PyPI release is:

uv tool upgrade mcp-server-sqlite

Option B: The maintained multi-database alternative

@executeautomation/database-server is a separately maintained, actively developed package that speaks SQLite, PostgreSQL, SQL Server, and MySQL through the same MCP interface — worth the switch if you expect to add a second database type later, or if you specifically want a project that's still receiving updates.

Install

npm install -g @executeautomation/database-server

Or run it without a global install via npx.

Add to Claude Desktop (SQLite mode)

{
  "mcpServers": {
    "sqlite": {
      "command": "npx",
      "args": ["-y", "@executeautomation/database-server", "/absolute/path/to/database.db"]
    }
  }
}

The database path is a positional argument here, not a --db-path flag — that's the biggest config difference from Option A if you're switching between the two.

Local development build

If you're building from source rather than using the published package, point command at node and args at the built entry file plus your database path:

{
  "mcpServers": {
    "sqlite": {
      "command": "node",
      "args": ["/path/to/mcp-database-server/dist/index.js", "/absolute/path/to/database.db"]
    }
  }
}

Practical workflows once connected

Schema-aware querying:

List the tables in this database, then show me the schema for the orders table.

Ad hoc analysis:

How many rows are in the users table, and what's the date range of the created_at column?

Guided exploration (archived server's mcp-demo prompt):

Use the mcp-demo prompt with topic "customer churn" and walk me through what the data shows.

Schema changes (write-capable, use with caution):

Add a nullable last_login_at TIMESTAMP column to the users table.

When NOT to point an MCP server at your production SQLite file

Both servers above will happily run write_query/INSERT/UPDATE/DELETE if the underlying file is writable and you approve the call. Neither server enforces read-only mode by default — that's a client-side or filesystem-permissions decision you have to make yourself. For a database backing a live application, point the server at a copy, or chmod the file read-only at the OS level, rather than trusting prompt-level restraint. For genuinely production-facing workloads, a proper client/server database (Postgres, MySQL) with connection-level read replicas is a better fit than SQLite's single-file model regardless of which MCP server you're using — see PostgreSQL MCP Server Setup if that's the direction you're headed.

Troubleshooting

"command not found: uvx." Install uv first — uvx ships as part of it, it isn't a separate package. Confirm with uv --version in the same terminal your MCP client will actually use to spawn the process (a shell alias in your interactive profile doesn't always carry over to a GUI app's subprocess environment).

Server connects but every query returns "no such table." Almost always a relative path resolving from the wrong working directory. Use an absolute path in --db-path (Option A) or the positional path argument (Option B) — don't rely on a path being relative to wherever you happen to have a terminal open.

Writes silently do nothing, or the file doesn't update. Check file permissions on the .db file and its containing directory (SQLite needs to write a journal or WAL file alongside the main database file, not just the file itself). If the directory is read-only, writes can fail in ways that don't always surface a clear error back through the MCP layer.

Docker container's database resets every run. You're not using a named volume, or you're pointing at a different volume path than last time. Confirm the same -v mcp-test:/mcp volume name is used on every invocation.

Which package should I pick if I'm starting fresh? If you only ever need SQLite and want the minimal, protocol-reference implementation, the archived server still works fine and its tool set (read_query, write_query, list_tables, describe_table) covers most exploratory use cases. If you want ongoing maintenance or might add Postgres/MySQL later, start with @executeautomation/database-server instead — switching later means re-pointing one config block, not a rewrite.

Frequently Asked Questions

Is the official SQLite MCP server still safe to use if it's archived? It still runs and does what it says — archived means no further updates or bug fixes from the MCP organization, not that it's broken. For low-stakes local use it's fine; for something you want actively maintained, use @executeautomation/database-server instead.

Does the SQLite MCP server support read-only mode? Neither the archived reference server nor the community alternative documents a built-in read-only flag. Enforce read-only access by pointing the server at a copy of the database, or by removing write permission on the file at the OS level.

Can I use this with an in-memory SQLite database instead of a file? The documented configs use a file path via --db-path or a positional argument; an in-memory database wouldn't persist between server restarts and isn't the documented use case for either package.

What's the actual difference between mcp-server-sqlite and @executeautomation/database-server? The archived server is SQLite-only, Python-based, and no longer actively maintained, with a small fixed tool set plus a demo prompt and an insights resource. The community alternative is Node-based, actively maintained, and also supports PostgreSQL, SQL Server, and MySQL through the same server if you need more than SQLite.

Related guides

Official docs cited