Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_SQLITE_DBYesPath to the SQLite database file. Required (--db PATH).
MCP_SQLITE_RGNoPath to ripgrep executable; default is rg on PATH (--rg PATH).rg
MCP_SQLITE_VERBOSENoEnable verbose output (-v, --verbose).off
MCP_SQLITE_MAX_ROWSNoMaximum rows returned (--max-rows N).1000
MCP_SQLITE_SNAPSHOTSNoNumber of snapshots to keep; 0 disables (--snapshots N).5
MCP_SQLITE_DEFAULT_LIMITNoDefault result limit (--default-limit N).100
MCP_SQLITE_QUERY_TIMEOUTNoQuery timeout in seconds (--query-timeout SECONDS).10
MCP_SQLITE_MAX_CELL_CHARSNoMaximum characters per cell (--max-cell-chars N).2000
MCP_SQLITE_MAX_UPDATE_ROWSNoMaximum rows an UPDATE may affect in write_query (--max-update-rows N).500
MCP_SQLITE_MAX_RESULT_BYTESNoMaximum total result bytes (--max-result-bytes N).32768
MCP_SQLITE_SEARCH_CANDIDATESNoSearch candidate row limit for search_text (--search-candidates N).5000

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

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

Tools

Functions exposed to the LLM to take actions

NameDescription
read_queryA

Run one read-only SQL statement and get CSV back: a header row, data rows, then a '# N rows' trailer that says whether the result was truncated. Time-limited and capped in rows and bytes. Select only the columns you need and keep limit small: results cost context.

write_queryA

Run one data or additive-schema statement and return the affected row count. Refuses DELETE, DROP, ALTER and triggers: those need destructive_query. An UPDATE that touches more rows than the configured cap is rolled back, so a forgotten WHERE clause cannot rewrite a whole table by accident. RETURNING clauses come back as CSV.

destructive_queryA

Run one destructive statement. A snapshot of the database file is written first (the newest few are kept next to the database), then the statement runs. Requires a short reason, which lands in the audit log. Never use this when write_query would do.

list_tablesB

List tables and views as CSV: name, type, system (1 for the server's own memory and audit tables) and row count (tables only).

describe_tableA

Columns (cid, name, type, notnull, default, pk), foreign keys and indexes of a table or view, as CSV sections.

get_schemaA

The CREATE statements of every table, index, view and trigger, exactly as stored. View descriptions appear as '-- description:' comments. The server's own tables are hidden unless include_system is true.

create_viewA

Save a SELECT as a named view: a reusable query skill. Give it a description so future sessions know what it is for; it is stored inside the view and shown by get_schema. With replace=true an existing view is redefined and its previous definition is kept in query_log.

append_eventA

Append one entry to the memory log. The log is append-only and hash-chained by the server, so history cannot be rewritten through SQL. Use it for decisions, results, errors and observations worth remembering across sessions.

verify_chainA

Recompute the memory_events hash chain and report whether it is intact, with the first event id where it breaks if it is not.

checkpointA

Write a summary of the current state to memory_checkpoints, anchored to the latest event. Do this at milestones and before context runs out; get_resume_context returns the latest one.

get_resume_contextA

Call this first in a new session or after context compaction. Returns the latest checkpoint, the events appended since it (oldest first, most recent max_events), and the result of verifying the hash chain.

search_textA

Regex search inside column values in one call: the WHERE filter narrows rows in SQL, then ripgrep matches the pattern over the selected columns. Returns CSV rows of key, column, snippet, one per matching value, plus a trailer with the totals.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 12 tools

Disambiguation5/5

Each tool has a clearly distinct role: the three query tools are separated by intent (read/write/destructive), and the introspection trio (list_tables, describe_table, get_schema) differs by granularity. Memory tools (checkpoint, append_event, get_resume_context, verify_chain) are distinguishable by write-vs-read purpose.

Naming Consistency4/5

Most names follow a verb_noun pattern (read_query, write_query, list_tables, describe_table, get_schema, create_view, append_event, verify_chain, search_text). Exceptions are 'checkpoint' (bare noun) and 'destructive_query' (adjective_noun), but both remain readable and predictable.

Tool Count5/5

12 tools is well-scoped for a SQLite memory store that also exposes generic DB operations. Every tool earns its place with no redundancy.

Completeness5/5

Full lifecycle coverage: read/write/destructive queries, schema introspection, view creation, plus a hash-chained memory log with append, checkpoint, resume, and verification. search_text adds value beyond SQL, and destructive_query covers drops/alters, leaving no obvious gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues