Schema Generator - SQLite database schema management and CRUD operations
SchemaGen has 12 tools with basic schemas and descriptions, but significant quality gaps prevent production use. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization) and input schemas are present but minimal. Critical issues: (1) SQL injection vulnerability, table_name, column_name, and old_name parameters are interpolated directly into SQL without sanitization, violating pattern:tool-gateway. (2) No error handling guidance, tools return raw SQL or status strings without recovery hints. (3) Parameter descriptions lack constraints, 'columns' in create_table is 'Dictionary mapping column names to their SQLite types' but doesn't specify valid SQLite types or format. (4) Output schemas undocumented, get_records returns 'List[Dict]' but LLMs don't know field names or types. (5) No idempotency guarantees, insert_record and create_table use 'IF NOT EXISTS' but don't document retry behavior. (6) Destructive operations (drop_table, delete_record, drop_column) lack confirmation or dry-run patterns. Average tool description length is ~35 chars (baseline 194 chars); descriptions are too terse for LLM selection.
Add a new column to an existing table
Create a new table with specified columns
Delete a record from the specified table
Drop (delete) a column from a table
Drop (delete) a table from the database
Retrieve records from the specified table
Get the current database schema as DDL (Data Definition Language)
SQL injection vulnerability: table_name, column_name, old_name, and new_name parameters are interpolated directly into SQL strings without sanitization (e.g., f'CREATE TABLE {table_name}', f'ALTER TABLE {old_name}'). LLMs can be tricked via prompt injection to pass malicious payloads like 'users; DROP TABLE users;--'. All DDL tools affected.
Destructive operations lack confirmation or dry-run patterns. drop_table, delete_record, and drop_column execute immediately without user confirmation, violating pattern:confirmation-request. Agents make mistakes, irreversible operations should support a dry-run or explicit confirmation step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Insert a new record into the specified table
Ping the SchemaGen server
Rename a column in a table
Rename an existing table
Update an existing record in the specified table
Parameter descriptions lack format constraints and valid value ranges. 'columns' in create_table is described as 'Dictionary mapping column names to their SQLite types' but doesn't specify which SQLite types are valid (TEXT, INTEGER, REAL, BLOB, NULL). 'filters' in get_records doesn't explain filter syntax or operators. LLMs cannot infer constraints from names alone.
Output schemas are undocumented. get_records returns 'List[Dict[str, Any]]' but LLMs don't know what fields are in each dict or their types. create_table returns a dict with 'status', 'table', 'columns', 'sql' but this is not documented in the tool definition. LLMs need explicit output schema to plan downstream calls.
No error handling guidance. Tools return raw SQL strings or generic 'status: success' responses without recovery hints. If a table already exists, create_table silently succeeds (IF NOT EXISTS). If a table doesn't exist, drop_table silently succeeds. LLMs cannot distinguish success from silent failure or know what to do next.