Model Context Protocol server for SQLite Cloud database
The server defines 10 tools with reasonable naming conventions (verb_noun style like 'read-query', 'write-query', 'list-tables'). However, critical gaps in schema completeness, parameter descriptions, and output documentation significantly limit production readiness. All tools have descriptions (positive), but many descriptions are generic and lack context about prerequisites, return types, or when to use alternatives. Input schemas use Zod with type definitions, but most parameters lack sufficient descriptive text to guide LLM decision-making. Error handling exists (e.g., validation in read-query to reject non-SELECT) but lacks recovery guidance. No output schemas are documented, forcing LLMs to infer structure. Several tools have descriptions under 20 characters or are incomplete (e.g., 'write-query' description says 'SELECT SQL query' when it should describe INSERT/UPDATE/DELETE). The server is functional but falls short of production-grade tool design patterns.
Gathers information about the indexes used in the query plan of a query execution.
Resets the statistics about a specific query, group of queries, or database.
Create a new table in the SQLite database on SQLite Cloud
Get the schema information for a specific table on SQLite Cloud database
Execute only SQLite Cloud commands listed in the `list-commands` tool. You can use the `list-commands` tool to see the available commands.
Returns a rowset with the slowest queries performed on the connected this.mcpServer. Supports filtering with GROUPID, DATABASE, GROUPED, and NODE options.
Parameter description for 'write-query' is incorrect, says 'SELECT SQL query to execute' when tool expects INSERT/UPDATE/DELETE. This is a copy-paste error from read-query that will confuse LLMs.
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, forcing them to infer structure and plan downstream tool calls blindly.
execute-command accepts 'command' as a bare string with no enum constraints. LLMs must call list-commands to discover valid options, adding latency and context overhead. Should provide an enum or strict validation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
List all available commands and their descriptions from the SQLite database and an external documentation page.
List all tables in the SQLite database on SQLite Cloud
Execute a SELECT query on the SQLite database on SQLite Cloud
Execute a INSERT, UPDATE, or DELETE query on the SQLite database on SQLite Cloud
Destructive operations (write-query, create-table, execute-command, analyzer-reset) lack confirmation steps, dry-run modes, or explicit warnings in descriptions. Agents could accidentally run harmful commands.
Error messages are present in code but lack recovery guidance. E.g., 'Only SELECT queries are allowed for read-query' tells LLMs what failed but not what to do next (try write-query? check syntax?). Error responses should guide the agent's next step.
Several parameter descriptions are vague or incomplete. E.g., 'node' parameter in list-analyzer and analyzer-plan-id is described as 'SQLite Cloud Node ID to execute the command on a specific cluster node' but lacks format/example. LLMs do not know if this is a number, UUID, or string name.
Analyzer tools (list-analyzer, analyzer-plan-id, analyzer-reset) lack clear descriptions of prerequisites, output format, and typical usage flow. LLMs cannot confidently decide when to call them or how to interpret results.
list-commands fetches external documentation from GitHub but returns raw content without structure. LLMs receive unstructured markdown that wastes tokens and is harder to parse than a structured list of command objects.
No pagination or result limiting documented for tools that return multiple rows (list-tables, list-analyzer, read-query). Large result sets could blow context windows. Descriptions should specify result limits and offer pagination.