Skip to main content
Glama
sqlscope-mcp

sqlscope-mcp

by 0xmortuex

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Explore and understand an SQLite database file. Everything is read-only by construction (the file is opened read-only and every statement passes an authorizer), so it is safe to point at any .db / .sqlite file. Every tool takes the file's path. Start with db_overview (size, tables, row counts), then describe_table for one table, schema_graph for how tables relate, and data_quality to find problems. Use query for SELECT statements (results are capped; aggregate instead of pulling rows), explain_query to see whether a query uses an index, find_in_db to locate a value anywhere in the database, and schema_docs to produce markdown documentation.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
db_overviewA

Start here. Summarise an SQLite database file: size, page size, text encoding, journal mode (WAL or not), user_version, counts of tables / views / indexes / triggers, and a row count for every table (from ANALYZE statistics when present, otherwise an exact count that stops at 100,000). Virtual tables (FTS5, rtree) are listed with their module and their internal shadow tables are folded away. Opening is read-only and never modifies the file or creates -wal / -shm files.

path: the .db / .sqlite file (relative paths are resolved inside the --dir folder, if one was set).

describe_tableA

Describe one table or view in depth: columns with declared type, NOT NULL, default, primary key and generated-column flags; per-column NULL percentage, distinct count, min, max and the storage types actually seen (computed over a sample of up to stats_sample rows); foreign keys in both directions; indexes; CHECK constraints; triggers; the CREATE statement; and sample rows. BLOBs are shown as size plus a hex prefix, long text is truncated with its length.

table: table or view name (case-insensitive; a close-match hint is given if it does not exist). sample_rows: how many example rows to show (0-50). stats_sample: rows to sample for the statistics (100-200000).

schema_graphA

Show how tables relate through foreign keys: every child -> parent edge, tables with no relationships, a parents-first load order and circular references. Also reports foreign-key columns that have no index (with a CREATE INDEX suggestion as text) and checks for orphan rows (child rows whose parent does not exist) over a sample, even when PRAGMA foreign_keys is off.

format: "text" (default) or "mermaid" (an erDiagram you can paste into a renderer). orphan_sample: child rows to sample per foreign key (100-100000).

queryA

Run one read-only SELECT / WITH / VALUES statement. Anything that would write (INSERT, UPDATE, DELETE, CREATE, DROP, ATTACH, VACUUM, PRAGMA assignments, load_extension) is refused. Results stop at max_rows rows and about 200 KB, and the query is interrupted after timeout_seconds. BLOB cells show size plus a hex prefix, and text longer than 200 characters is truncated with its length. Prefer aggregates (COUNT, GROUP BY) over pulling raw rows.

format: markdown (default), csv or json. max_rows: 1-5000. timeout_seconds: 0.1-60.

explain_queryA

Show the execution plan of a SELECT / WITH query without running it (EXPLAIN QUERY PLAN), as an indented tree, followed by plain-language findings: full table scans (with row counts), temporary B-tree sorts for ORDER BY / GROUP BY / DISTINCT, and automatic indexes SQLite has to build on every run. Missing-index suggestions are returned as CREATE INDEX text only; nothing is ever created.

find_in_dbA

Find where a string or number appears anywhere in the database: a substring search over every non-BLOB column of every ordinary table (virtual and shadow tables are skipped). Returns, per table, the matching rows (rowid or primary key), the column and a snippet around the match. Each table has a time budget and a match cap, so a huge database cannot hang the call; tables that ran out of budget are listed.

case_sensitive: default false (SQLite folds ASCII letters only, so Turkish or other non-ASCII letters match case-sensitively). max_matches_per_table: 1-50. seconds_per_table: 0.1-30.

data_qualityA

Look for data problems, using SQL over a sample of each table: columns that are mostly or always NULL (and NULL versus empty-string mixes); columns holding mixed storage types (SQLite does not enforce column types; the typeof() distribution is reported, with examples); key-like columns (id, email, uuid, ...) that contain duplicates, case/space-only duplicates, and rows identical in every non-key column; dangling foreign keys even though SQLite does not enforce them by default; and date-looking text columns whose formats are inconsistent.

table: check just this table (default: all ordinary tables). sample: rows to examine per table (100-200000).

schema_docsA

Generate markdown documentation of the whole schema as text: an entity-relationship diagram (mermaid) when foreign keys exist, then every table with its columns, types, defaults, key and reference notes, indexes, CHECK constraints and triggers, followed by views and trigger definitions. Nothing is written to disk; paste the result where you want it.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

Each tool has a reasonably distinct role: overview, single-table deep dive, whole-schema docs, FK graph, ad-hoc query, plan analysis, cross-DB text search and data-quality checks. The main overlap is between schema_docs and schema_graph, since both can emit a mermaid ER diagram, and data_quality partially overlaps with what an agent could do via query. Descriptions give strong cues (db_overview is explicitly 'start here'), so misselection is unlikely but not impossible.

Naming Consistency4/5

All eight names use consistent snake_case with no camelCase or casing drift. The only inconsistency is grammatical style: some are verb_noun (describe_table, explain_query, find_in_db) while others are noun_noun (schema_docs, schema_graph, db_overview, data_quality) or a bare verb (query). Readable and predictable overall, just not a single uniform pattern.

Tool Count5/5

Eight tools is a well-scoped set for a read-only SQLite inspection server, and each tool maps to a distinct inspection task. Nothing feels padded or redundant enough to merge, and nothing essential appears to be missing from the count.

Completeness4/5

Coverage of the read-only introspection domain is strong: schema docs, overview, per-table detail, FK graph, query execution, plan explanation, value search and data-quality auditing. Minor gaps exist, such as no explicit lightweight 'list tables/views/trigger names' operation (db_overview reports counts and describe_table requires a known name) and no schema-diff or index-only listing tool. The deliberately read-only scope means no write/migration operations, which is appropriate rather than a gap.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues