sqlite-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQLITE_DB_PATH | No | Path to the SQLite database file. Can also be provided via CLI argument --db-path or per tool invocation db_path. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tablesB | List all user tables and views in the SQLite database with their row count. Args: db_path: Optional path to SQLite file. If omitted, uses default database path. |
| describe_tableA | Get detailed schema information for a specific table or view, including columns, primary keys, foreign keys, and indexes. Args: table_name: The name of the table or view to inspect. db_path: Optional path to SQLite file. If omitted, uses default database path. |
| get_database_schemaA | Get the full CREATE DDL statements and schema definitions for all tables, views, and indexes. Args: db_path: Optional path to SQLite file. If omitted, uses default database path. |
| read_queryA | Execute a safe, read-only SELECT query against the SQLite database. Args: query: The SQL SELECT query to execute. Mutation queries (INSERT, UPDATE, DELETE, DROP, etc.) are strictly rejected. params: Optional list of query parameters for prepared statements (? placeholders). max_rows: Maximum number of rows to return (default: 1000). Protects against context overflow. db_path: Optional path to SQLite file. If omitted, uses default database path. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| schema_analysis | Prompt for analyzing database structure, table relationships, and optimization opportunities. |
| safe_query_assistant | Prompt to assist in drafting safe, optimized SELECT queries for a specific goal. Args: user_goal: Description of what data the user wants to retrieve. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| database_schema_resource | Resource providing the full SQLite database DDL schema. |
| table_list_resource | Resource listing all tables and views with row counts. |
TDQS
Scored across 4 tools
list_tables, describe_table, and get_database_schema have some overlap in scope (schema/table inspection), but each operates at a clearly different granularity: table list with counts, single-table detail, and full DDL. read_query is cleanly distinct as the data-retrieval tool. An agent can reasonably pick the right one.
Names are snake_case verb_noun throughout (list_tables, describe_table, get_database_schema, read_query), which is readable and predictable. Minor deviation in that three verbs (list/describe/get) are used for closely related inspection tasks rather than one consistent verb.
Four tools is well-scoped for a read-only SQLite inspection server, with each tool earning its place and no redundancy. Nothing feels padded or thin for the stated purpose.
The read-only inspection surface (list tables, describe table, full DDL, run SELECT) covers the core discovery and query workflow with no dead ends. Gaps exist around write/mutation operations and query-plan/explain introspection, but those are plausibly out of scope for a deliberately read-only server.