Which integrations are available for this server?

Provides secure read-only access to an SQLite e-commerce database, enabling AI agents to list tables, inspect schemas, and run read-only SQL queries with pagination.

How do I use Read-Only SQLite Shop Database MCP Server?

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., "@Read-Only SQLite Shop Database MCP Server show me the top 5 best-selling products" 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.

de en es ja ko ru zh

Read-Only SQLite Shop Database MCP Server

by alimbux

Overview Schema Source Related Servers Discussions Admin

Python

Local

Read-Only SQLite Shop Database MCP Server

An official Model Context Protocol (MCP) server providing secure, read-only database access to an SQLite e-commerce store (shop.db) for AI agents.

🌟 Key Features

Standard stdio Transport: Works seamlessly with any MCP client (Claude Desktop, Cursor, Gemini CLI, Antigravity, etc.).
Multi-layered Read-Only Security:
- SQLite URI read-only mode (?mode=ro).
- Strict runtime PRAGMA query_only = ON;.
- Pre-flight SQL parser rejecting all DDL/DML mutation statements (INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, etc.).
- Blocks SQL injection chains and multi-statement execution.
LLM-Optimized Tools: Clear descriptions, robust error handling without raw stack traces, and automatic pagination (limit/offset).
Flexible Path Resolution: Works out of the box with relative paths, DB_PATH environment variable, or --db-path CLI flag.

Related MCP server: shop-db

🗄️ Database Schema

The SQLite database (shop.db) contains the following entities:

customers
    │
    └──< orders
             │
             └──< order_items >── products

customers: id, first_name, last_name, email, phone, created_at
products: id, name, category, price, stock_quantity, created_at
orders: id, customer_id, order_date, status (new, processing, shipped, completed, cancelled), total_amount
order_items: id, order_id, product_id, quantity, unit_price

🛠️ MCP Tools

Tool	Parameters	Description
`list_tables`	None	Lists all user tables with column count and row count summary.
`describe_table`	`table_name` (string, required)	Returns column definitions, data types, primary keys, foreign keys, row count, and sample rows.
`get_database_schema`	None	Returns the complete schema and relationship graph of all tables in one call.
`read_query`	`query` (string, required), `limit` (int, default: 100), `offset` (int, default: 0)	Executes read-only queries (`SELECT`, `WITH`, `EXPLAIN`) with pagination.

🚀 Getting Started

1. Installation

Create a virtual environment and install the required dependencies:

# Create virtual environment
python3 -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install -r requirements.txt

2. Running Locally

Run the MCP server over standard input/output:

python server.py

Or specify a custom database path:

# Using CLI argument
python server.py --db-path /path/to/shop.db

# Or using Environment Variable
DB_PATH=/path/to/shop.db python server.py

3. Running Tests

Run the test suite to verify tool functionality and safety constraints:

python -m unittest discover -s tests -v

🔌 Connecting to AI Agents

Claude Desktop

Add this server to your claude_desktop_config.json (~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "shop-database": {
      "command": "/absolute/path/to/.venv/bin/python",
      "args": ["/absolute/path/to/server.py"],
      "env": {
        "DB_PATH": "/absolute/path/to/shop.db"
      }
    }
  }
}

Cursor IDE

In Cursor Settings → Features → MCP:

Type: command
Command: /absolute/path/to/.venv/bin/python /absolute/path/to/server.py

Antigravity / Gemini CLI

Add to your MCP configuration file:

{
  "mcpServers": {
    "shop-database": {
      "command": "python",
      "args": ["server.py"]
    }
  }
}

🔒 Safety & Validation Examples

If an AI agent or prompt attempts a destructive operation, the server immediately rejects the query gracefully:

Prompt: "Delete all cancelled orders."

Server Response:

{
  "error": "Operation rejected: Statement type 'DELETE' is not allowed. Only read-only queries (SELECT, WITH ... SELECT, EXPLAIN) are permitted."
}

📊 Verification Queries

The server enables AI agents to resolve analytical queries such as:

Table Discovery: list_tables() and describe_table(table_name="customers")

Customer Demographics:

SELECT count(*) FROM customers WHERE phone LIKE '+7%';

Customer Who Spent the Most Money:

SELECT c.first_name, c.last_name, c.email, SUM(o.total_amount) AS total_spent
FROM customers c
JOIN orders o ON c.id = o.customer_id
WHERE o.status != 'cancelled'
GROUP BY c.id
ORDER BY total_spent DESC
LIMIT 1;

Top 5 Best-Selling Products:

SELECT p.name, SUM(oi.quantity) AS units_sold, SUM(oi.quantity * oi.unit_price) AS revenue
FROM products p
JOIN order_items oi ON p.id = oi.product_id
JOIN orders o ON oi.order_id = o.id
WHERE o.status != 'cancelled'
GROUP BY p.id
ORDER BY units_sold DESC
LIMIT 5;

Top 3 Product Categories by Revenue:

SELECT p.category, SUM(oi.quantity * oi.unit_price) AS revenue
FROM products p
JOIN order_items oi ON p.id = oi.product_id
JOIN orders o ON oi.order_id = o.id
WHERE o.status != 'cancelled'
GROUP BY p.category
ORDER BY revenue DESC
LIMIT 3;

Customer With Most Orders:

SELECT c.first_name, c.last_name, COUNT(o.id) AS order_count
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id
ORDER BY order_count DESC
LIMIT 1;

Available Tools

4 tools

describe_tableA

Get detailed schema information for a specific database table, including column names, data types, primary keys, foreign key relations, total row count, and sample data.

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description must convey safety and behavior. The unambiguous read verb 'Get' and the listed read-only outputs make it clear this is a non-destructive metadata retrieval. It does not disclose potential latency of row-count computation or permission requirements, but such contexts are less critical for a schema-inspection tool.

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?

The description is a single, focused sentence and front-loads the core purpose. The enumeration of returned fields adds useful detail without unnecessary filler, though 'detailed schema information' is slightly redundant with the listed specifics.

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?

With one required, clearly named parameter and the existence of an output schema, the description supplies enough detail for correct invocation: what to pass and what the tool returns. It does not mention pagination or performance caveats, but these are not essential for a single-table schema lookup.

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?

There is one parameter, table_name, and the input schema has no detailed description. The description only says 'specific database table', which lightly reinforces the parameter's meaning but adds no format, naming, or scoping specifics. For a self-evident single parameter, this is adequate but not compensating beyond schema titles.

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 starts with 'Get detailed schema information for a specific database table', clearly identifying the verb, resource, and specificity. It enumerates the returned content (columns, data types, primary keys, foreign keys, row count, sample data), which also separates it from list_tables and read_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?

The description implies use when you need schema details for one table ('specific database table'), but it does not explicitly contrast with alternatives like get_database_schema or list_tables. No when-to-use or when-not-to-use conditions are stated, so this rests on inference rather than explicit guidance.

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

get_database_schemaA

Get the complete schema for all tables and foreign key relationships across the entire database in a single call. Use this to quickly understand the entire database structure.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It transparently says what the call returns (complete schema, all tables, foreign key relationships) and that it does so in a single call. It does not mention possible size/performance tradeoffs, but this is a simple read-only introspection tool.

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 concise sentences: one states what the tool does, the other states why to use it. There is no fluff or redundant detail.

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 zero-parameter tool with an output schema, the description is complete. It explains the action, the scope, the foreign-key relationships, and the intended use case, so an agent has sufficient context to invoke it.

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 tool has zero parameters, so there is no parameter semantics burden. The description reinforces the scope of what will be returned, which is enough given the empty input schema and full schema coverage.

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 names a specific verb and resource: 'Get the complete schema for all tables and foreign key relationships across the entire database'. It clearly differentiates itself from siblings like list_tables and describe_table by targeting the entire database rather than a single table or list.

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?

It gives a clear use case: 'Use this to quickly understand the entire database structure.' It does not explicitly state when not to use it or name alternatives, but the whole-database scope makes the intended usage context clear.

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 user tables available in the SQLite database, along with column count and row count summary.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description must communicate behavioral safety itself. It states a non-destructive 'list' operation and further constrains scope to user tables, providing a clear and accurate behavior. It doesn't mention edge cases like performance, ordering, or whether views are included, but the core behavioral context is present.

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, focused sentence that fronts the main action and resource without any filler. Every word earns its place, and the summary metrics are included efficiently.

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 simplicity of a no-parameter list tool, the description answers what, why, and what result to expect. The output schema exists to specify the structure of the return. It doesn't explicitly describe sibling relationships, but that isn't required for basic call completeness.

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 tool has zero parameters, and the schema is empty, so baseline per instructions is 4. The description actually adds value by defining what will be returned (column count and row count summary), which is relevant and meaningful beyond the empty 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 uses a clear action verb ('List') and specifies the exact resource ('all user tables available in the SQLite database'). It also states the return content (column count and row count summary), making it easy to distinguish from sibling tools like describe_table or get_database_schema.

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 purpose is clear enough to imply when to use this tool—when you need an overview of available tables—but there is no explicit guidance about when not to use it or when to prefer a sibling like get_database_schema or describe_table. Usage is logical but not elaborated.

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

read_queryA

Execute a read-only SQL query (SELECT, WITH ... SELECT, or EXPLAIN) on the database. Mutating queries (INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, etc.) are strictly prohibited and will be rejected. Results support pagination via limit and offset.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`offset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly tells the agent that mutating statements are prohibited and will be rejected, and that results are paginated via limit and offset. This covers the most important runtime behaviors, though it does not mention minor details like timeouts or maximum result sizes.

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 three concise sentences with no filler. Each sentence contributes essential information: what it does, the safety boundary, and pagination. The most important action is front-loaded and a reader can immediately grasp the tool's purpose.

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 tool with three simple parameters and an output schema, the description covers the core distinctions the agent needs to know: allowed query types, forbidden mutations, and pagination. It does not mention response format, but the output schema exists for that purpose. The main omission is that it does not explicitly compare itself to sibling tools in the description.

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 description coverage is 0%, so the description is the only source of parameter meaning. It explains the query parameter by restricting it to read-only SQL forms (SELECT/WITH/EXPLAIN), and it gives meaning to limit and offset through pagination. Default values are already in the schema, so not repeating them is acceptable.

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 begins with a strong verb+resource ('Execute'), specifies the exact SQL forms allowed (SELECT, WITH... SELECT, EXPLAIN), and explicitly states it runs on the database. It clearly differentiates from sibling metadata tools like list_tables/describe_table by presenting itself as the raw read-only query tool.

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 establishes when to use this tool: any time the agent needs to issue a read-only SQL query against the database. It also provides a strong when-not: mutating SQL is strictly prohibited and rejected. It does not explicitly name sibling tools as alternatives, but the context is clear enough.

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.

4 tool updatesv1.0.0Aug 23, 2026
- First observeddescribe_table
- First observedget_database_schema
- First observedlist_tables
- First observedread_query

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-08-23 20:20 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing tables, describing a single table, viewing the full schema, and executing read-only queries. Potential overlap between get_database_schema and describe_table is resolved by one being all-encompassing while the other focuses on one table with sample data.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: list_tables, describe_table, get_database_schema, read_query. The naming style is uniform and predictable, making it easy for an agent to infer tool behavior from names.

Tool Count5/5

Four tools is well-scoped for a read-only SQLite server. Each tool serves a necessary part of database exploration without being redundant or overwhelming, fitting comfortably in the ideal tool count range.

Completeness5/5

The toolset fully covers the read-only exploration lifecycle: reveal the database structure and allow arbitrary SELECT queries. There are no missing operations for a read-only server, as all needed capabilities are present.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
mcpmyadminOAuth
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2
db-plannerOAuth
io.dbplanner
Read and edit DB Planner database schemas, diagrams and board layouts as an AI agent.
Databases Data Visualization
1

Related MCP Servers

Shop Analytics MCP Server
Databases E-commerce & Retail
bogdaamn
F
license
A
quality
C
maintenance
Enables AI agents to answer analytical questions about an online store's SQLite database through specialized read-only tools, without any risk of modifying the underlying data.
Updated 21 days ago (2026-08-23 18:33 UTC)
8
-
shop-db
Databases E-commerce & Retail
aleksei-antipin
F
license
A
quality
C
maintenance
Enables AI agents to read-only query an online store's SQLite database, listing tables, inspecting schemas, and running SELECT queries over customers, products, orders, and order items.
Updated 20 days ago (2026-08-23 19:58 UTC)
3
-
shop-db MCP Server
Databases E-commerce & Retail
bulychauPI
F
license
A
quality
B
maintenance
Gives AI agents read-only analytical access to an e-commerce SQLite database (customers, orders, order_items, products) via SQL queries, table listing, and schema inspection.
Updated 20 days ago (2026-08-24 07:04 UTC)
3
-
Shop MCP Server
Databases E-commerce & Retail
k0ry
F
license
A
quality
C
maintenance
Enables AI agents to analyze an SQLite e-commerce database via secure read-only SQL queries, providing tools for table inspection and analytical requests.
Updated 19 days ago (2026-08-24 23:50 UTC)
2
-