An MCP server that exposes SQLite database operations through tools, allowing LLM agents to query, insert, and delete data from local SQLite databases.
Server has 5 tools with basic schemas and descriptions, but significant quality gaps. Tool names follow verb_noun convention (list_, get_, query_, insert_, delete_) which is good. However, descriptions are minimal (10-50 chars), parameter descriptions lack detail, and output schemas are not documented. The dummy_param in list_db_tables is a code smell. SQL injection risks in query_db_table and get_table_schema (f-string interpolation on table_name). No error recovery guidance. Missing idempotency hints for write operations. Average tool score: 42/100.
Deletes rows from a table based on a given SQL WHERE clause condition.
Gets the schema (column names and types) of a specific table.
Inserts a new row of data into the specified table.
Lists all tables in the SQLite database.
Queries a table with an optional condition.
SQL injection vulnerability in get_table_schema and query_db_table. Table names are interpolated directly into SQL via f-strings (e.g., f"PRAGMA table_info('{table_name}');"). Malicious input like 'users'; DROP TABLE users; --' will execute. Use parameterized queries or strict allowlist validation.
Dummy parameter in list_db_tables serves no purpose and confuses the interface. The parameter description says 'not used by the function', this violates the principle that every parameter should have a clear, necessary role. Remove it or document why it exists.
Output schemas are not documented. Tools return dicts/lists but LLMs cannot see the structure. For example, list_db_tables returns {success, message, tables} but this is not declared in the tool schema. Document all return fields with types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | <=2025-11-25 | v2 |
Descriptions are too brief (10-50 chars). Pattern baseline is 194 chars average. Descriptions lack context on WHEN to use each tool, WHAT it returns, and dependencies. For example, 'Gets the schema (column names and types) of a specific table.' does not explain that you should call list_db_tables first to discover table names.
No error recovery guidance. Error responses return {success: false, message: '...'} but do not tell the LLM what to do next. For example, if a table is not found, suggest calling list_db_tables() to discover valid tables. Pattern: recovery-guide.