SQLite is a Databases MCP server that lets Claude Code, Cursor, Windsurf and any MCP-compatible AI agent local SQLite database access and management. Install in 1 minute with mcpizy install sqlite.
Databases
Local SQLite database access and management
Official homepagemcpizy install sqlitenpx -y @modelcontextprotocol/server-sqliteread_queryExecute a SELECT query and return rows
Inputs
querystringrequiredwrite_queryExecute an INSERT/UPDATE/DELETE statement
Inputs
querystringrequiredcreate_tableCreate a new table
Inputs
querystringrequiredlist_tablesList all tables in the database
describe_tableShow the schema of a table
Inputs
table_namestringrequiredWorks identically across clients. Only the config file path differs.
~/.claude.json{
"mcpServers": {
"sqlite": {
"command": "uvx",
"args": [
"mcp-server-sqlite",
"--db-path",
"/path/to/database.db"
]
}
}
}.cursor/mcp.json{
"mcpServers": {
"sqlite": {
"command": "uvx",
"args": [
"mcp-server-sqlite",
"--db-path",
"/path/to/database.db"
]
}
}
}~/.codeium/windsurf/mcp_config.json{
"mcpServers": {
"sqlite": {
"command": "uvx",
"args": [
"mcp-server-sqlite",
"--db-path",
"/path/to/database.db"
]
}
}
}Point the server at a local .db file — no credentials needed
Paste any of these prompts into Claude Code, Cursor or another MCP-compatible client.
“Show me the schema of the `users` table”
Uses: describe_table
“Count rows in every table in my database”
Uses: list_tables, read_query
“Insert a new user named 'Alice' with email [email protected]”
Uses: write_query
“Create a `sessions` table with columns id, user_id, expires_at”
Uses: create_table
SQLite MCP is the easiest database MCP to set up — point it at a `.db` file path and you're done. No connection strings, no credentials, no network. That makes it the natural choice for three workflows: prototyping a feature against a local schema, analysing a CSV/Parquet you've loaded into a local SQLite, and exposing a portable read-only dataset to an AI agent (think analytics datasets shipped as `.db` files).
What you actually do with it: `read_query` for SELECTs, `write_query` for INSERTs/UPDATEs, `create_table` and `list_tables` for schema work. Five tools, perfectly scoped. The MCP runs in the same process as your client (stdio transport), so latency is sub-millisecond — agent loops feel instant compared to a network DB.
The honest trade-offs: SQLite is single-writer (one writer at a time, readers concurrent), so this is not a server-grade DB. If your agent is doing parallel `write_query` from multiple subagents, you'll see lock contention. The other gotcha is that SQLite's type system is weak (declared types are advisory) — if the agent expects strict typing, you need `STRICT` table mode or explicit casts.
Where it beats Postgres MCP: portability (single file you can ship anywhere), simplicity (no auth, no network), and zero cold-start. Where Postgres wins: any production workload, any concurrent-write workflow, any need for advanced indexing or row-level security.
The MCP server expects an absolute path to the `.db` file — relative paths fail silently or open a brand-new empty database in the working directory of the client. If your queries return zero rows on a populated DB, check the resolved path with `ls -lh` before debugging the SQL.
Concurrent writes from multiple agent subagents will hit `database is locked` errors. SQLite serialises writers; for parallel work, either use a single agent or switch to Postgres MCP.
`write_query` does not auto-commit transactions in some SQLite MCP forks — verify by querying back after writing. If you see "table updated, count = 0", the transaction may have rolled back silently.
The schema introspection tools (`list_tables`, `describe_table`) read SQLite's `sqlite_schema` directly. Views appear in the table list but write operations against views fail unless you've set up `INSTEAD OF` triggers — the agent won't know that without explicit instructions.
Honest pros/cons against the closest databases MCP servers.
| Server | Strengths | Trade-offs |
|---|---|---|
| Postgres MCP | Production-grade, concurrent writers, rich indexing | Needs running server + connection string, no portability |
| DuckDB MCP | Columnar, blazing-fast analytics on Parquet/CSV, drop-in for SQLite | Newer, fewer client integrations, OLAP not OLTP |
| Supabase MCP | Full backend platform on top of Postgres | Massive overkill for single-file local analytics |
If SQLite doesn't fit your stack, these Databases MCP servers solve similar problems.
The SQLite MCP server is an Databases Model Context Protocol server that lets Claude Code, Cursor, Windsurf, VS Code with Copilot, and other MCP-compatible AI agents local SQLite database access and management. It exposes SQLite's capabilities as tools the AI can call directly from your editor or CLI.
The fastest way is the MCPizy CLI: run `mcpizy install sqlite` and MCPizy will add the server to your `.claude.json` automatically. You can also install it manually by adding an entry under `mcpServers` in `.claude.json` with the command `npx -y @modelcontextprotocol/server-sqlite` and restarting Claude Code.
Yes. The SQLite MCP server is free and open source (see the GitHub repository linked on this page). You may still need a SQLite account or API key to connect the server to the underlying service, but the MCP layer itself has no MCPizy subscription cost.
Yes. Any MCP-compatible client works — including Claude Code, Claude Desktop, Cursor (via `.cursor/mcp.json`), Windsurf, VS Code with Copilot Chat, and custom agents built on the MCP SDK. The same install command targets all of them; only the config file path differs.
Once installed, your AI agent can local SQLite database access and management directly inside your conversation. Typical use cases include asking Claude Code or Cursor to run SQLite operations, inspect results, chain SQLite with other MCP servers (see our Workflow Recipes), and automate repetitive databases tasks without leaving your editor.