A
licenseNot graded
qualityC
maintenanceEnables exploring and querying SQLite databases through natural language, with tools to list tables, describe table structures, and run SELECT queries.
MIT
node-sqlite-mcp
by djgadd
node-sqlite-mcp enables an AI agent to perform read-only exploration and querying of local SQLite database files via three tools:
list_tables– Lists all tables and views in a given.db/.sqlitefile (requires an absolute path).describe_table– Returns column details (name, type, NOT NULL constraint, default value, primary key flag) for a specified table or view.query– Executes a single read-only SQL statement and returns results as TSV (tab-separated values). Write operations (INSERT,UPDATE,DELETE, schema changes) are blocked at the engine level.
Key characteristics:
All operations are strictly read-only — no data can be modified.
Results are not truncated, so use
LIMITand select only needed columns to manage payload size.The server can open any SQLite file readable by the OS user — there is no allowlist or directory restriction.
Uses Node's built-in
node:sqlitemodule, so no native compilation or system-wide SQLite installation is needed.NULLvalues, BLOBs, and booleans have specific handling in TSV output, with special characters escaped.
Provides tools for querying SQLite database files: list_tables, describe_table, and query, all read-only with TSV output.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@node-sqlite-mcpList tables in /home/user/chinook.db"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
node-sqlite-mcp
An MCP server that lets an AI agent query SQLite database files on the local machine.
It uses Node's built-in node:sqlite
module, so there is no native module to compile and no system SQLite to
install — the only thing you need on the host is a recent Node.
Requirements
Node.js 22.16 or newer (which ships
node:sqliteunflagged). Node 24+ is recommended.
Check with node --version.
Related MCP server: mcp-to-db
Install
The server is published to npm and is installed into your agent with
add-mcp:
npx add-mcp node-sqlite-mcpadd-mcp detects your installed agents (Claude Code, Claude Desktop, Cursor,
VS Code, …) and registers the server as a local stdio command. Nothing is
cloned or installed globally — the command is fetched and run on demand.
You can also run it directly to sanity-check it:
npx -y node-sqlite-mcpIt speaks MCP over stdio and waits for a client; there is nothing interactive to see.
Tools
Every tool takes the database as an argument — path should be an absolute
path to a .db / .sqlite file. The database is always opened read-only.
Tool | Arguments | Returns |
|
| The tables and views in the database. |
|
| Columns, types, a boolean not-null flag, defaults and a boolean primary-key flag for one table or view. |
|
| The rows returned by a single read-only SQL statement. |
Output format
Results come back as TSV: a tab-separated header row of column names, one line per row, then a blank line and a row count. This is used instead of JSON because it does not repeat column names on every row, keeping the payload small.
NULLis rendered as an empty field.Tabs, carriage returns, newlines and backslashes inside values are escaped (
\t,\r,\n,\\). Other control characters are escaped as\xNN(e.g. NUL as\x00).BLOBs are rendered as a SQLite hex literal, e.g.
x'deadbeef'.The
describe_tablenot_nullandprimary_keycolumns are booleans (true/false).
Read-only
The SQLite connection is opened read-only, so INSERT / UPDATE / DELETE
and schema changes fail at the engine level — not merely by convention. The
query tool runs a single statement per call and does not truncate
results, so a broad SELECT * on a large table can return a very large payload;
the tool description tells the agent to add a LIMIT and select only needed
columns.
Security note
This is a local, trust-the-user tool. It will open any SQLite file the operating-system user running the server can already read — there is no allowlist or directory confinement.
Development
npm install # installs deps and builds via the "prepare" script
npm run build # compile TypeScript to dist/Source is TypeScript in src/; the published package ships compiled JavaScript
in dist/ (the bin entry point). Consumers never run a build step.
Releases & publishing
Releases are automated with Release Please, driven by Conventional Commits:
Every push to
mainopens or updates a standing release PR that bumps the version inpackage.json/package-lock.jsonand updatesCHANGELOG.md, derived from the commits since the last release (fix:→ patch,feat:→ minor, a!orBREAKING CHANGE:→ major).Merging that release PR tags the version, creates a GitHub Release, and triggers
npm publish(on-push-main.yml→workflow-call.release.yml).
So the normal flow is: land Conventional-Commit PRs on main, then merge the
release PR when you want to cut a version — no manual tag or npm publish.
Publishing uses npm trusted publishing (OIDC) — no tokens. Configure the
trusted publisher on npmjs.com against this repository, the entry workflow
on-push-main.yml, and the production environment. The publish job
runs with id-token: write on npm ≥ 11.5.1, and provenance is generated
automatically.
To publish by hand instead (e.g. the first release, to bootstrap the package before a trusted publisher can be configured), from a logged-in machine:
npm publishCommit messages
This repo uses Conventional Commits.
Because PRs are merged (not squashed), every commit lands on main verbatim and
is what Release Please parses — so each commit in a PR is linted against the
convention (on-pr.yml → workflow-call.lint-pr.yml, config in
.commitlintrc.json). Common types: feat:, fix:, docs:, chore:,
refactor:, test:, ci:. A feat!: prefix or a BREAKING CHANGE: footer
marks a breaking change.
License
MIT
Available Tools
3 toolsdescribe_tableDescribe tableA
Describe the schema of a single table or view: its columns, declared types, a boolean not-null flag (true when the column is NOT NULL), default values and a boolean primary-key flag (true when the column is part of the primary key). path must be an absolute path; table is the table or view name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the SQLite database file. | |
| table | Yes | Name of the table or view to describe. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully discloses the output structure (columns, types, not-null, primary-key flags). It is honest about reading schema without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains output, second clarifies parameter requirements. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly explains return fields. For a simple schema-reading tool with 2 params, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described. The description adds minimal extra detail (path must be absolute), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'describe' and clearly identifies the resource as 'schema of a single table or view'. It distinguishes from siblings: list_tables lists tables, query executes queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what the tool does and implies when to use it. While it does not explicitly exclude alternatives, context signals provide sibling tools for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesList tablesA
List the names of all tables and views in a SQLite database file. path must be an absolute filesystem path to the .db/.sqlite file.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the SQLite database file. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It notes the path constraint but does not disclose error handling (e.g., if file not found), whether it is read-only, or the output format (just names). More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The purpose is stated first, followed by a necessary constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description is largely complete. It could mention potential errors or what happens with invalid paths, but the basic functionality is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, and the description adds the critical context that the path must be absolute. This adds meaning beyond the schema's 'Absolute path to the SQLite database file.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists names of tables and views in a SQLite database. It uses a specific verb ('List') and resource ('tables and views'), and the sibling tools ('describe_table', 'query') indicate distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by specifying the 'path' must be an absolute filesystem path. It doesn't explicitly state when to use vs siblings, but the tool's purpose of listing tables is distinct from describing a table or querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
queryRun a read-only SQL queryA
Run a single read-only SQL statement against a SQLite database file and return the rows as TSV (a tab-separated header row of column names, then one line per row). The database is opened read-only, so INSERT/UPDATE/DELETE and schema changes will fail. Exercise caution: results are NOT truncated, so a broad query like SELECT * FROM big_table can return an enormous result set — add a LIMIT and select only the columns you need. path must be an absolute filesystem path; sql must be a single statement.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | A single read-only SQL statement to execute. | |
| path | Yes | Absolute path to the SQLite database file. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: read-only, TSV output, no truncation, single statement requirement, and cautions about large results. This covers key behavioral traits effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences) and well-structured: first sentence states purpose and output, then constraints, then caution and parameter details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description is complete: it explains output format, constraints, cautions, and parameter requirements. It lacks only explicit error handling info, but that is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that 'path' must be absolute and 'sql' must be a single statement, and provides an example of what to avoid (SELECT *). This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a read-only SQL query against a SQLite database and returns results as TSV. It distinguishes from sibling tools (describe_table, list_tables) which are for schema inspection, not arbitrary queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions read-only nature, that INSERT/UPDATE/DELETE fail, advises caution with broad queries, and specifies the need for absolute paths and single statements. Does not explicitly mention alternatives but strongly implies this tool is for ad-hoc queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.5/5.0
Disambiguation5/5
Each tool serves a distinct purpose: listing tables, describing schema, and executing read-only queries. There is no functional overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (describe_table, list_tables, query). 'query' as a single verb is standard for SQL operations.
Tool Count5/5
Three tools are appropriate for a read-only SQLite explorer, covering the essential operations of listing, describing, and querying without unnecessary bloat.
Completeness5/5
The tool set fully covers the domain of exploring a SQLite database: listing tables/views, inspecting their schema, and running arbitrary read-only queries. No obvious gaps.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceExposes any SQLite database as read-only MCP tools for AI assistants, enabling listing tables, describing schemas, and running SELECT queries with filtering, ordering, and pagination.
- FlicenseNot gradedqualityCmaintenanceProvides AI agents read-only analytical access to a SQLite database over stdio, with tools for listing tables, describing schemas, and running paginated SQL queries.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/djgadd/sqlite-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server