Database devtools — connect, query, inspect, import/export
Database operations server with 18 tools covering PostgreSQL, MySQL, SQLite, MongoDB, and Redis. Naming is consistently verb-noun (db_*, pg_*, mongo_*, redis_*), which is good. All tools have descriptions and input schemas are visible in the source. However, descriptions are often terse (20-80 chars) and lack actionable context for LLM selection. Parameter descriptions exist but some are overly generic ('Connection ID' without guidance on how to obtain one). Output schemas are not documented, the code shows responses are text-based, but the agent cannot see the return structure beforehand. Error handling is basic (errors exist but lack recovery guidance). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the metadata. Security is reasonable for a database tool (secrets not in params, operations gated by connection ownership), but input validation details are not visible in sampled code.
Opens a new database connection with the given driver and DSN. Supported drivers: postgres, sqlite, mysql, redis, mongodb
Creates an index on a table
Returns the schema (column definitions) of a table
Closes and removes the connection with the given ID
Drops an index from a table
Exports a table to CSV or JSON format
Imports data from CSV or JSON file into a table
Lists all active database connections
Output schemas not documented. Tools return text-based responses but LLMs cannot see the response structure beforehand. For example, db_query returns 'X rows' as text, but there's no schema indicating fields, data types, or how rows are formatted. Forces LLMs to infer structure from examples.
Descriptions are terse (most 50-80 chars) and lack context for LLM tool selection. Example: 'Closes and removes the connection with the given ID' (db_disconnect) doesn't explain when an agent should call this vs keeping connections open, or what happens to in-flight queries. Descriptions should answer WHAT, WHEN, and any dependencies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Lists indexes on a table
Lists all tables in the database
Executes a SELECT query on the given connection and returns rows as a list of maps
Manages MongoDB indexes with operations to list, create, and drop indexes
Performs MongoDB server administration operations
Creates a GIN (Generalized Inverted Index) on a PostgreSQL table for full-text search or JSON data
Creates a vector index on a PostgreSQL table using HNSW or IVFFlat methods for vector similarity search
Shows index bloat statistics for PostgreSQL indexes
Runs REINDEX on a PostgreSQL object (table, index, or database)
Performs Redis server administration commands
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit Risk classifications in metadata. db_import, db_create_index, db_drop_index, mongo_indexes, pg_create_gin_index, pg_create_vector_index, pg_reindex are WRITE operations; the LLM cannot see this in the tool definition and might retry them indiscriminately. Tool annotations are part of current spec (2026-07-28).
Error handling lacks recovery guidance. Test code shows errors (e.g., 'expected error for unsupported driver'), but tool responses do not suggest next steps. Per pattern:recovery-guide, error messages should say 'User not found. Try search_users()...', not just a status code.
'connection_id' parameter description is generic ('Connection ID') across all tools. LLMs don't know how to obtain a connection_id without reading db_connect docs. Add: 'Obtain via db_connect() or list all active IDs with db_list_connections().' This reduces discovery overhead.
DSN parameter in db_connect lacks format guidance. Description is 'Data source name (connection string)' but doesn't explain format per driver. Add: 'For postgres: postgresql://user:pass@host:5432/db. For sqlite: /path/to/file or :memory:. For mysql: mysql://user:pass@host:3306/db.' Prevents invalid DSN attempts.