SQLite MCP Server

The SQLite MCP server is an official reference implementation from Anthropic that gives AI agents full read and write access to a local SQLite database file. It exposes six tools covering SELECT queries, INSERT/UPDATE/DELETE statements, table creation, schema inspection, and a built-in insights memo. Because SQLite is file-based, there is nothing to install or provision beyond pointing the server at a .db file. It is the fastest path to letting an agent interact with a real database.

Getting an AI agent to work with a database should not require provisioning a server, managing a connection pool, or writing infrastructure code. For a large class of tasks, it does not have to. The SQLite MCP server points at a .db file and hands the agent a full set of database tools in about two minutes of config.

This is the simplest database integration in the MCP ecosystem. It is also the one with the widest write permissions in the reference implementations, which means it is important to understand when that is acceptable and when you should reach for something more constrained.

What the SQLite MCP server does

The server exposes six tools and one resource:

read_query runs SELECT statements and returns the result set. This is the safe half of the server: the agent can explore your data without modifying anything.

write_query runs INSERT, UPDATE, and DELETE statements. This is the tool that makes SQLite MCP meaningfully different from the Postgres MCP server, which enforces read-only access at the transaction level. SQLite MCP trusts you to scope access appropriately.

create_table lets the agent define new tables. Useful when you want the agent to design and populate a schema from scratch, which is a common pattern for prototyping.

list_tables returns the names of every table in the database. An agent typically calls this first to understand what it is working with.

describe_table returns the column names and types for a specific table. Paired with list_tables, these two tools give the agent an accurate picture of your schema before it writes a single query.

append_insight adds an observation to a persistent memo. After a session where the agent has been analyzing data, you can read the memo://insights resource to see a collected summary of what it found. This is a small but useful feature: it turns a conversational session into something with a durable output.

The zero-infrastructure advantage

SQLite is a file. There is no daemon to start, no port to open, no credentials to rotate. When you configure the SQLite MCP server, the only thing you specify is the path to the .db file. The server handles everything else.

This makes it genuinely useful for a set of tasks that would be disproportionately painful with a networked database:

• Exploring a dataset you downloaded (many open datasets ship as SQLite files)
• Prototyping a schema before committing to a database engine
• Building a personal project where shared access is not a concern
• Testing an agent workflow locally before wiring it to a real database
• Letting an agent read and write structured data without any API surface

For these scenarios, the SQLite MCP server is the right tool and alternatives would add complexity without adding value.

Setup

The reference implementation runs via uv, Python's fast package manager. If you do not have uv, install it first:

curl -LsSf https://astral.sh/uv/install.sh | sh

Then add the server block to your Claude Desktop config at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS:

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": [
        "mcp-server-sqlite",
        "--db-path",
        "/Users/you/projects/myapp.db"
      ]
    }
  }
}

Use an absolute path for --db-path. Relative paths can behave unexpectedly depending on where the MCP client launches the subprocess.

If the database file does not exist at the specified path, the server creates an empty one. That is useful for greenfield projects but worth knowing so you do not accidentally create a parallel database next to the one you intended to use.

Docker alternative:

docker run -i --rm \
  -v /Users/you/projects:/mcp \
  mcp/sqlite \
  --db-path /mcp/myapp.db

The volume mount maps your local directory into the container at /mcp. Use that prefix in the --db-path argument.

For Claude Code, the config file is at ~/.claude/mcp.json and follows the same structure as the Claude Desktop format above.

Common use cases

Prototyping data models. Ask the agent to design a schema, create the tables, and populate them with sample data. You can iterate on the structure in conversation rather than writing migrations by hand. When the shape looks right, export it or adapt it for your target database.

Exploring datasets. Many public datasets ship as SQLite files: government data, research exports, app backups. Drop the file into the config, ask the agent to summarize what is in each table, and start querying in plain language. The agent can write the SQL, run it, and interpret the results in one loop.

Agent memory layers. A SQLite database is a reasonable backing store for agent memory that needs to survive across sessions. Write_query lets the agent persist structured state, read_query lets it retrieve it, and the schema tools let it manage its own storage format.

Local analytics. If your app already uses SQLite (mobile apps, desktop apps, and many small web backends do), you can point the MCP server at the app database and let the agent answer questions about it. This is faster than exporting to CSV and more accurate than describing the data in prose.

Schema documentation. The agent can walk every table with describe_table, sample a few rows with read_query, and generate accurate documentation for a database that has never been formally documented. The append_insight tool means findings accumulate in a readable memo rather than disappearing into the conversation.

Write access: what to watch

The SQLite server's write tools are the right call for local and prototyping use cases. They become a risk if you forget you are working with a file that has no built-in recovery mechanism.

A few habits that prevent problems:

Keep a backup before any session where you expect the agent to write. SQLite databases are single files. A cp myapp.db myapp.db.bak before starting costs nothing and avoids a bad afternoon.

Use a dedicated database for agent work. If your application already uses a SQLite database, do not hand that file to the MCP server for exploration. Create a copy or use a separate test database. The agent can produce unexpected writes, especially when you are iterating on instructions.

Be specific in your prompts. Write_query does not have a confirmation step. If you tell the agent to clean up duplicate records and your intent is ambiguous, it will make its best interpretation and run the DELETE. Precise prompts reduce the chance of an unintended modification.

These are the same precautions you would apply to any tool with write access to data you care about. They are not SQLite MCP-specific; they are just worth naming explicitly because the frictionless setup can make it easy to forget you are working with real data.

SQLite MCP vs Postgres MCP: when to use which

The Postgres MCP server enforces read-only access at the transaction level. The SQLite MCP server does not. Beyond that fundamental difference, the choice between them follows the choice between SQLite and Postgres in general.

Use SQLite MCP when:

• You are working locally, solo
• The database does not need to be shared between processes or machines
• You are prototyping and want to move fast
• The dataset fits comfortably in a single file (SQLite handles hundreds of gigabytes but degrades with many concurrent writers)

Use Postgres MCP when:

• The database is shared or networked
• You need the read-only safety guarantee
• You are working against a staging or production data source
• You want row-level security or other PostgreSQL-specific access controls

There is no overlap ambiguity once you have answered those questions. Most projects that start with SQLite MCP for prototyping graduate to the Postgres setup when they move to shared infrastructure. The tool surface is similar enough that the transition is straightforward.

The bigger picture

The SQLite MCP server is one of a small set of official MCP servers that Anthropic built to demonstrate what the protocol can do. It is simple on purpose. The six tools cover the full CRUD surface for a SQL database with no opinions about schema design, no middleware, and no configuration beyond a file path.

For anyone evaluating how much an agent can do with database access, this is the right starting point. It installs in two minutes, the tool surface is small enough to understand in one read, and the feedback loop for testing agent-written SQL is immediate. Pair it with Claude Code and you have a setup where you can prototype a schema, query it, and iterate on the data model entirely in conversation. The best AI agent for coding roundup covers which agents handle MCP database tools most reliably if you want a comparison before committing to a workflow.

Bottom line

The SQLite MCP server is the fastest path to letting an agent use a real database. No server to run, no credentials to manage, no infrastructure to think about. Point it at a .db file and start working.

The write access it provides is a feature, not a gap. For local development, personal projects, and prototyping, an agent that can create tables and insert data is significantly more useful than one that can only read. Just keep a backup before you start, use a copy of any database you care about, and the risk profile is entirely manageable.

When the project grows past what a local file can handle, move to the Postgres MCP server. Until then, SQLite MCP is enough, and being enough is its whole point.

Features

• Execute SELECT queries with read_query
• Run INSERT, UPDATE, and DELETE with write_query
• Create new tables with create_table
• List all tables with list_tables
• Inspect column definitions with describe_table
• Persistent insights memo via append_insight and memo://insights resource
• Zero infrastructure required, just a local .db file
• Works with uv, Docker, or VS Code Quick Install
• MIT licensed reference implementation

How to set up the SQLite MCP Server MCP server

1. Install uv if not already present (curl -LsSf https://astral.sh/uv/install.sh | sh)
2. Create or locate the SQLite file you want to expose (e.g. ~/projects/myapp.db)
3. Add the server block to your Claude Desktop or Claude Code MCP config file
4. Set the --db-path argument to the absolute path of your .db file
5. Restart your MCP client and verify the six tools appear in the tool list