dba-mcp has 10 tools with complete input schemas and basic descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have descriptions (10-100+ chars), but most lack per-parameter descriptions, critical for LLM parameter selection. No output schemas documented. Error handling is minimal. Naming is verb-forward (list_, save_, remove_, inspect_, sql_, generate_, migrate_, replicate_) but some names are vague (inspect_schema, generate_migration_ddl). The server exposes database credentials via connection strings in parameters, violating secret-injection patterns. Destructive operations (migrate_data, replicate_database) lack confirmation/dry-run patterns.
Compare schemas and generate DDL to migrate from Source to Target
Retrieve stored knowledge/context about a database.
Get schema information. Lists tables if tableName not provided, or describes table.
List configured database connections and their status
Migrate data between databases. Warning: Experimental.
Remove a stored database connection.
AUTO-MAGIC: Clone ALL tables and data from Source DB to Target DB. Target should be empty.
Credentials exposed as parameters: save_connection accepts connectionString directly, violating secret-injection pattern. Connection strings contain passwords and should be injected server-side via environment variables or vault.
No parameter descriptions: Most tools lack per-parameter descriptions. E.g., sql_query has 'query' param with no description of expected SQL dialect, result format, or constraints. LLMs cannot infer parameter semantics from names alone.
No output schemas documented: Tool descriptions do not specify what fields are returned or their types. E.g., list_connections returns unknown structure; sql_query result format is undocumented. LLMs cannot plan downstream calls without knowing response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Save a new database connection persistently.
Save AI-generated knowledge/context about a database (e.g. governance, business rules, schema explanation).
Execute a SQL query
Destructive operations lack confirmation: migrate_data and replicate_database can destroy data but have no dry-run, confirmation, or undo mechanism. Agents may accidentally truncate production databases.
Vague tool names reduce clarity: 'inspect_schema' is ambiguous (inspect what? list tables or describe one?). 'generate_migration_ddl' is jargon-heavy. Better names: 'list_tables', 'describe_table', 'generate_schema_migration_sql'.