Which integrations are available for this server?

Provides read-only exploration and querying of SQLite databases, including listing tables and views, describing schemas, running bounded SELECT queries, inspecting query plans, and generating token-dense database summaries.

How do I use mcp-sqlite-explorer?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-sqlite-explorer describe the users table in ./app.sqlite" 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.

mcp-sqlite-explorer

by KaryawanSurga

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

mcp-sqlite-explorer

License: MIT Node

Zero-dependency, read-only SQLite explorer and query sandbox for AI agents and developers.

Inspect databases, extract relational schemas, run bounded read-only queries, and generate token-dense database summaries for Claude, Cursor, and MCP-compatible coding agents — without risking accidental data modification or context window flooding.

✨ Features

🛡️ Multi-Layer Read-Only Safety:
- AST-level query validator blocks all mutating statements (INSERT, UPDATE, DELETE, DROP, ALTER, ATTACH, mutating PRAGMAs).
- Multi-query injection detection (disallows statement chaining via ;).
- Native SQLite engine-level read-only mode (PRAGMA query_only = ON; and readOnly: true).
⚡ Zero Native Dependencies:
- Built entirely on Node 22+ native node:sqlite.
- No node-gyp, no Python runtime requirement, no C++ compilation errors on Windows, macOS, or Linux.
🧠 Token-Optimized AI Context Summaries:
- sqlite_summarize_database produces high-density schema maps (tables, row counts, PKs, foreign keys, indexes) formatted specifically to conserve LLM context budgets.
📊 Bounded Query Sandbox:
- Enforces pagination (limit & offset) with default cap (50 rows, max 500) and truncation indicators.
- Formats results into GitHub-flavored markdown tables, compact TSV, or JSONL.
🔍 Query Plan Explainer:
- Inspect SQLite index utilization and execution plans with EXPLAIN QUERY PLAN.
💻 Standalone CLI:
- Dual-mode: works as both an MCP stdio server and a standalone terminal utility.

Related MCP server: shop-mcp

🚀 Quick Start

1. Claude Desktop Configuration

Add mcp-sqlite-explorer to your claude_desktop_config.json:

{
  "mcpServers": {
    "sqlite-explorer": {
      "command": "npx",
      "args": ["-y", "mcp-sqlite-explorer", "serve", "--db", "/path/to/database.sqlite"]
    }
  }
}

2. Standalone CLI Usage

# List all tables and views with row counts
npx mcp-sqlite-explorer tables ./mydb.sqlite

# Describe table columns, primary keys, and foreign keys
npx mcp-sqlite-explorer describe ./mydb.sqlite users

# Run a safe read-only query
npx mcp-sqlite-explorer query ./mydb.sqlite "SELECT id, name FROM users LIMIT 10"

# Generate agent-ready database summary
npx mcp-sqlite-explorer summary ./mydb.sqlite

# Inspect query plan
npx mcp-sqlite-explorer explain ./mydb.sqlite "SELECT * FROM posts WHERE user_id = 1"

🛠️ MCP Tools Reference

Tool	Description	Key Parameters
`sqlite_list_tables`	List user tables and views with row and column counts	`db_path`, `include_views`
`sqlite_describe_table`	Full schema detail: columns, types, PKs, FKs, indexes, DDL	`db_path`, `table`
`sqlite_read_query`	Execute read-only query (`SELECT`, `WITH`) with pagination	`db_path`, `query`, `limit`, `offset`, `format`
`sqlite_explain_query`	Inspect SQLite execution plan	`db_path`, `query`
`sqlite_summarize_database`	Token-dense database overview for LLM context	`db_path`

🔒 Security Model

Strict SQL Whitelist: Only SELECT, WITH ... SELECT, EXPLAIN, and safe read-only PRAGMAs (table_info, database_list, index_list, foreign_key_list) are permitted.
Comment Stripping: SQL comments (-- and /* */) are parsed and removed prior to analysis to prevent comment-cloaked attacks.
No Database Writes: Any attempt to write or mutate triggers an immediate UnsafeQueryError before reaching SQLite.

🧪 Testing

npm test          # Run Vitest test suite (35+ unit & e2e tests)
npm run typecheck # Validate TypeScript types
npm run build     # Compile TypeScript to dist/

📄 License

MIT © KaryawanSurga

Available Tools

5 tools

sqlite_describe_tableDescribe SQLite Table SchemaA

Read-only

Inspect columns, types, primary keys, foreign keys, indexes, and CREATE TABLE DDL for a specific table or view in SQLite.

Name	Required	Description	Default
`table`	Yes	Table or view name to inspect
`db_path`	No	Path to SQLite database file

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value by telling the agent what information comes back (keys, indexes, DDL), which substitutes for a missing output schema, but it says nothing about behavior for a nonexistent table/view or default db_path resolution.

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?

A single front-loaded sentence that enumerates the returned artifacts with no filler or redundancy.

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?

For a simple two-parameter read tool with no output schema, the description adequately conveys the shape of the result (columns, types, PK/FK, indexes, DDL). The only real gap is error behavior on a missing table, which is minor given the read-only annotations.

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 description coverage is 100%, so both parameters are already documented. The phrase 'specific table or view' usefully confirms views are accepted (matching the schema wording), but nothing is added about db_path defaults or path validation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (inspect) and resource (a table or view's schema) and enumerates exactly what it surfaces: columns, types, keys, indexes, DDL. It is clearly distinct from sqlite_list_tables and sqlite_read_query in practice, though it never names those siblings to reinforce the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied — an agent can infer this is the schema-inspection step before writing or explaining a query, but the description never says when to prefer it over sqlite_list_tables or sqlite_summarize_database, nor any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sqlite_explain_queryExplain SQLite Query Execution PlanA

Read-only

Run EXPLAIN QUERY PLAN on a query to inspect SQLite index usage, table scans, and optimization steps.

Name	Required	Description	Default
`query`	Yes	SQL query to explain
`db_path`	No	Path to SQLite database file

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context about what the plan reveals, but does not state that the query is not actually executed or what the response shape looks like — relevant since there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words. It is efficiently sized, though it errs slightly toward terse for a tool with no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only tool this is close to sufficient, but the absence of an output schema means the description could say more about what the plan output contains or its format. It also doesn't clarify whether the query is executed or merely planned.

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% and both parameters (query, db_path) are documented in the schema. The description adds no meaning beyond that, so the baseline of 3 applies.

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?

States a specific verb and resource ('Run EXPLAIN QUERY PLAN on a query') and names the diagnostic output (index usage, table scans, optimization steps). This clearly separates it from data-fetching siblings such as sqlite_read_query or sqlite_list_tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is for query-plan inspection, but the description never says when to prefer it over sqlite_read_query or when-not to use it (e.g., it does not return rows). No alternatives or prerequisites are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sqlite_list_tablesList SQLite TablesA

Read-only

List all user tables and views in a SQLite database with row counts and column counts. Use this to discover database schema without loading data.

Name	Required	Description	Default
`db_path`	No	Path to SQLite database file (.db, .sqlite, .sqlite3)
`include_views`	No	Include views in the list (default true)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The phrase "without loading data" adds a genuine efficiency trait beyond the annotations, but nothing is said about what "user tables" excludes or how large/slow the call might be on big schemas.

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, zero filler: the capability comes first, the usage cue second. Nothing is repeated from the title or schema.

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?

For a simple read-only discovery tool with full schema coverage and annotations, the description covers purpose, output shape, and the key non-obvious trait (no data loading). It only lacks the sibling-differentiation that would make selection unambiguous.

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% – both db_path (with accepted extensions) and include_views (default true) are documented in the schema. The description adds no format, default, or behavioral nuance beyond that, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (list user tables and views in a SQLite database) and adds the return payload (row counts and column counts), so the agent knows exactly what it gets. It does not, however, distinguish itself from siblings like sqlite_describe_table or sqlite_summarize_database, leaving overlap for the agent to resolve.

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?

"Use this to discover database schema without loading data" gives a clear triggering context. There are no explicit exclusions (e.g., 'use sqlite_describe_table for a single table's columns'), so the alternative-routing piece is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sqlite_read_queryExecute Safe Read-Only QueryA

Read-only

Execute a read-only SQL query (SELECT, WITH, PRAGMA info) safely on SQLite. All write/mutation queries are blocked.

Name	Required	Description
`limit`	No	Maximum rows to return (default 50, max 500)
`query`	Yes	Read-only SQL query to execute
`format`	No	Output format (default markdown)
`offset`	No	Number of rows to skip (default 0)
`db_path`	No	Path to SQLite database file

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the bar is lower; the description still adds real value by stating that write/mutation queries are actively blocked and naming the permitted statement classes. It stops short of disclosing return shape, row-limit enforcement, or what happens when a blocked query is attempted.

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 short sentences, zero padding, with the operation stated first and the safety constraint immediately after. Every sentence earns its place and nothing is buried.

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?

For a five-parameter query tool with full schema coverage and no output schema, the description says enough to call it correctly, and the sibling set covers schema discovery. Minor gaps: no mention of pagination behavior or what a blocked query returns, though the schema mitigates the first.

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 description coverage is 100%, with limit, offset, format, and db_path all documented inline, so the schema carries parameter semantics. The description contributes no additional parameter detail beyond the general 'read-only SQL query' framing, making baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Execute a read-only SQL query... on SQLite') and enumerates the accepted statement types (SELECT, WITH, PRAGMA info), so the agent knows exactly what the tool performs. It does not explicitly position itself against siblings like sqlite_explain_query or sqlite_summarize_database, leaving that differentiation to the names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage context (ad-hoc read queries against a SQLite database) and makes clear that mutations are blocked, but offers no explicit when-to-use or when-not-to-use guidance relative to the sibling tools. An agent must infer that this is the fallback for queries the specialized tools don't cover.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sqlite_summarize_databaseSummarize SQLite Database for AI AgentA

Read-only

Generate a token-dense markdown summary of the entire database (tables, row counts, columns, PKs, FK relationships, indexes) optimized for AI agent context windows.

Name	Required	Description	Default
`db_path`	No	Path to SQLite database file

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds the output medium and shape (markdown, token-dense, agent-context-optimized), but says nothing about cost or limits on large schemas, truncation behavior, or whether db_path defaults when omitted.

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?

One sentence, front-loaded with the action and the scope, and the parenthetical inventory of summary contents carries real information rather than filler. Nothing to trim.

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?

With no output schema, the description does the right thing by enumerating what the returned markdown contains, so an agent knows what it gets back. Only minor gaps remain (no handling guidance for missing/huge databases), which is light for a single-parameter read-only tool.

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 description coverage is 100% and the single db_path parameter is documented in the schema, so baseline 3 applies. The description adds no extra meaning about the path parameter, notably no guidance on the optionality (0 required params) or what happens if db_path is omitted.

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?

States a specific verb+resource with scope: 'generate a token-dense markdown summary of the entire database' and enumerates exactly what the summary contains (tables, row counts, columns, PKs, FKs, indexes). The word 'entire' distinguishes it from siblings sqlite_list_tables and sqlite_describe_table, which operate on one table at a time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'optimized for AI agent context windows' implies the tool is the orientation/overview step before drilling into individual tables, but no sibling is named and no when-not-to-use condition (e.g., very large databases, or when you already know the schema) is given. Usage must be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Oct 27, 2026
- First observedsqlite_describe_table
- First observedsqlite_explain_query
- First observedsqlite_list_tables
- First observedsqlite_read_query
- First observedsqlite_summarize_database

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4/5.0

Scored 2026-10-27 07:35 across 5 tools

Disambiguation4/5

Most tools have clearly distinct purposes: listing, describing, querying, explaining, and summarizing. However, sqlite_summarize_database overlaps substantially with sqlite_list_tables and sqlite_describe_table because it aggregates similar schema/count information, and sqlite_read_query can also surface PRAGMA-style schema details.

Naming Consistency5/5

All tools use a consistent sqlite_verb_noun naming pattern: sqlite_list_tables, sqlite_describe_table, sqlite_read_query, sqlite_explain_query, sqlite_summarize_database. The convention is predictable and easy for an agent to follow.

Tool Count5/5

Five tools is well-scoped for a read-only SQLite exploration server. Each tool earns its place: schema discovery, table inspection, querying, query-plan inspection, and context-friendly summarization.

Completeness5/5

The server explicitly targets safe read-only exploration, and its surface covers the full workflow: discover tables, inspect schema, run read-only queries, analyze query plans, and summarize a database for agent context. No obvious read-only lifecycle gap remains.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
https://mcp.querybear.com/mcp
wgong-sqlite-mcp-server
ai.smithery
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Databases Developer Tools
21
https://server.smithery.ai/@wgong/sqlite-mcp-server/mcp
mcpmyadminOAuth
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2
https://mcpmyadmin.ai/mcp
Veto — SQL Safety & Cost Oracle A
com.vetosql
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Databases Security Autonomous Agents
32
https://vetosql.com/mcp

Related MCP Servers

SQLite Read-Only MCP Server
Databases Developer Tools
skycandykey1
A
license
A
quality
D
maintenance
Enables safe, read-only SQL access to SQLite databases for AI agents, allowing schema exploration and SELECT queries with defense-in-depth protections.
Updated 4 months ago (2026-06-14 15:46 UTC)
3
MIT
shop-mcp
Databases
stalexsm
F
license
A
quality
C
maintenance
Enables AI agents to safely explore and query a SQLite database in read-only mode, allowing them to inspect schema and run analytical SQL queries without risking data modification.
Updated 12 days ago (2026-10-16 11:47 UTC)
3
-
sql-guard-mcp
Databases Security
egoring
A
license
Not graded
quality
B
maintenance
Enables AI agents to safely query and explore SQLite databases through read-only, guard-protected tools that block writes, sensitive table access, and runaway queries.
Updated a month ago (2026-09-17 06:46 UTC)
1
MIT
db-query-mcp
Databases Security Developer Tools
asd369932
A
license
B
quality
B
maintenance
Enables AI assistants to safely run read-only SQL against SQLite databases through whitelist-validated queries, capped result sets, and confined file paths. It also exposes schema inspection so models can discover tables and columns before querying.
Updated a month ago (2026-10-02 09:37 UTC)
2
MIT