Skip to main content
Glama
skycandykey1

SQLite Read-Only MCP Server

by skycandykey1
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

MCP Server for SQLite (read-only) — safe SQL for your AI agent

tests python MCP license

A small, production-minded MCP server (Model Context Protocol) that gives an AI agent — Claude Desktop, Claude Code, or any MCP client — safe, read-only SQL access to a SQLite database. Point it at a .db file and the agent can explore schemas and run SELECT queries — but never write, drop, or escape the database.

Built on the official MCP Python SDK (FastMCP). The read-only safety core has zero MCP dependency and is unit-tested on its own — the server is a thin, auditable wrapper.

Why read-only matters

Handing an LLM a raw database connection is how you get a DROP TABLE in production. This server enforces read-only at two independent layers:

  1. OS-level — the connection is opened with SQLite ?mode=ro + PRAGMA query_only, so any write fails at the engine.

  2. Statement-level — query rejects anything that isn't a single SELECT/WITH (no multi-statements, no INSERT/UPDATE/DELETE/DROP/PRAGMA writes), and caps row counts.

Defense in depth: even if one layer is bypassed, the other still holds. (There's a test that proves it.)

Related MCP server: sqlite-analyst

What the agent gets (all 3 MCP primitives)

Primitive

Name

Does

🔧 tool

list_tables

List the tables in the database

🔧 tool

describe_table

Column schema (name, type, nullability, PK)

🔧 tool

query

Run a single read-only SELECT/WITH, capped at max_rows

📄 resource

schema://tables

The whole DB schema as text

💬 prompt

explore_database

A ready-made "explore this DB" prompt

Quick start (≈ 1 minute)

git clone https://github.com/skycandykey1/mcp-sqlite-server
cd mcp-sqlite-server
pip install -r requirements.txt

# make a sample DB to play with
python examples/make_sample_db.py

# inspect it live in the MCP dev inspector
SQLITE_DB_PATH=examples/sample.db mcp dev mcp_sqlite/server.py
# ...or run the server directly
SQLITE_DB_PATH=examples/sample.db python -m mcp_sqlite.server

Use it from Claude Desktop

Add this to your Claude Desktop config (Settings → Developer → Edit Config), using absolute paths — see examples/claude_desktop_config.example.json:

{
  "mcpServers": {
    "sqlite-readonly": {
      "command": "python",
      "args": ["-m", "mcp_sqlite.server"],
      "cwd": "/absolute/path/to/mcp-sqlite-server",
      "env": { "SQLITE_DB_PATH": "/absolute/path/to/your.db" }
    }
  }
}

Restart Claude Desktop, then ask: "What tables are in my database? Show me the top 5 orders by amount."

How it fits together

  MCP client (Claude Desktop / Claude Code)
            │  MCP over stdio
            ▼
  mcp_sqlite/server.py   ← thin FastMCP wrapper (tools / resource / prompt)
            │
            ▼
  mcp_sqlite/db.py       ← read-only core (no MCP dep, fully unit-tested)
            │  ?mode=ro + query_only + SELECT-only guard
            ▼
        your .db  (read-only)

Run the tests

pip install -r requirements-dev.txt
python -m pytest -q       # offline — no MCP client, no API key needed

License

MIT — see LICENSE.

💼 Built by skycandykey1 — available for AI agent & automation contract work. I build agents, MCP servers, and LLM automation. → skycandykey456@gmail.com · https://github.com/skycandykey1

Available Tools

3 tools
describe_tableA

Get the column schema (name, type, nullability, primary key) for one table.

Args: table: Table name, as returned by list_tables.

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior2/5

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

No annotations provided; description only lists output fields. Does not disclose error handling, permissions, or idempotency. Minimal 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, front-loaded purpose, zero waste. Every sentence adds value.

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?

Output schema exists, so description correctly focuses on input and return fields. Single-parameter tool, fully and concisely described.

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?

With 0% schema coverage, description adds value by specifying table name should come from list_tables, guiding agent on valid input.

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?

Explicit verb 'Get' and resource 'column schema' (name, type, nullability, primary key). Clearly distinct from siblings list_tables and query.

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?

Implied that table name comes from list_tables, but no explicit when-to-use or when-not-to-use. Lacks alternatives comparison.

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

list_tablesA

List all tables in the database.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations exist, so the description carries the full burden. It only states the basic function without disclosing behavioral traits such as performance implications, permission requirements, or whether it returns cached data.

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 a single sentence, front-loaded with the key action and resource. No unnecessary 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?

Given the tool has no parameters and an output schema, the description is adequate for a simple list-all operation. However, it lacks any context about the database scope or filtering.

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?

With zero parameters, the schema has complete coverage. The description adds no extra parameter information, but the baseline for 0 parameters is 4, and the description is sufficient.

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 action (list), the resource (tables), and the scope (all in database). It distinguishes from sibling tools like describe_table (describes a specific table) and query (runs a query).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about when not to use it.

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

queryA

Run a READ-ONLY SQL query (a single SELECT or WITH statement) and return the rows.

Writes (INSERT/UPDATE/DELETE/DROP/...) are rejected. Results are capped at max_rows.

Args: sql: A single SELECT or WITH statement. max_rows: Maximum number of rows to return (1-1000, default 100).

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYes
max_rowsNo

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses that the tool is read-only, rejects writes, and caps results at max_rows (1-1000). These behavioral traits go beyond the input schema, which has no annotations. No contradictions.

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 extremely concise (4 lines) with a clear structure: purpose first, then constraints, then parameter explanations. No unnecessary words or repetition.

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?

For a tool with only 2 parameters and no output schema, the description covers all essential aspects: what query types are allowed, row limit, parameter defaults, and rejection of writes. It is fully adequate for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description provides meaningful explanations for both parameters: 'sql' is 'A single SELECT or WITH statement' and 'max_rows' is 'Maximum number of rows to return (1-1000, default 100).' This fully compensates for the schema's lack of descriptions.

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 'Run a READ-ONLY SQL query (a single SELECT or WITH statement) and return the rows.' It specifies the verb (run), resource (SQL query), and distinguishes from siblings (describe_table, list_tables) by focusing on querying data. No ambiguity.

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 explicitly states 'Writes are rejected,' guiding the agent not to use for write operations. While it does not mention sibling tools by name, the context provides them, and the read-only nature implies alternative uses. Could be improved by stating 'For describing tables, use describe_table.'

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observeddescribe_table
    • First observedlist_tables
    • First observedquery
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clear, non-overlapping purpose: listing tables, describing a table's schema, and running read-only queries. No ambiguity.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern ('describe_table', 'list_tables', 'query') with clear, predictable naming.

Tool Count5/5

Three tools is ideal for a read-only SQL interface—covers essential operations without unnecessary complexity.

Completeness5/5

The set covers all necessary operations for a read-only database: enumeration, schema inspection, and arbitrary queries. No gaps.

Maintenance

ActivityStale
ResponsivenessNo issues

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

Related MCP Servers

  • analytics-mcp-server

    kshitiz305
    A
    license
    A
    quality
    C
    maintenance
    Enables safe exploration and analysis of SQLite databases through guarded read-only queries, schema inspection, aggregations, and CSV imports.
    5
    MIT

  • sqlite-analyst

    yogaibhh
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to explore and query SQLite databases through read-only tools, with defense-in-depth sandboxing preventing any data modifications.
    MIT

  • sqlite-guard-mcp

    Brandon-35
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to safely work with SQLite databases by enforcing read/write separation, dry-run writes with confirmation, automatic backups, and an audit trail.
    MIT

  • shop-mcp

    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.
    3
    -

Latest Blog Posts

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/skycandykey1/mcp-sqlite-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server