A unified database connection manager and MCP server that manages connections to multiple database types (MySQL, PostgreSQL, SQLite, SQL Server, MongoDB, Redis, etcd) with team-based access control, bridges for local databases, and a web UI.
UniDB MCP server has 7 tools with clear naming patterns (verb_noun style: connect, disconnect, query, execute, list_*, schema). Tool descriptions are present and moderately detailed (50-100 chars each). Input schemas are visible in the code with proper JSON schema structure (type, properties, required). However, parameter descriptions are generic and lack actionable constraints. Output schemas are completely undocumented, no return type specifications provided. Error handling is absent from visible code. Security considerations for SQL execution (query, execute) are not addressed. The server supports multiple database backends (SQLite, PostgreSQL, MySQL, MongoDB, etc.) but tool descriptions do not clarify database-specific behaviors or limitations.
Establish connection to a database using stored DSN
Close and remove an active database connection
Execute a write operation (INSERT/UPDATE/DELETE)
List all active database connections
List all configured DSN connections available to connect to
Execute a SELECT query on the specified database
Get schema information for tables in the database
Output schemas completely undocumented. Tools return data structures but provide no schema documentation for LLM to understand what fields to expect. This violates the pattern:tool requirement that output be documented so agents can chain calls.
SQL injection risk exposed via 'query' and 'execute' tools. Parameters accept raw SQL strings with no validation or parameterized query guidance. Descriptions do not warn about SQL injection or recommend prepared statements.
Parameter descriptions lack actionable constraints. 'sql' parameter description is just 'SQL SELECT query' with no guidance on format, length limits, or prohibited operations. 'connection_id' described generically as 'ID of the active connection' without explaining how to discover valid IDs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | 2025-03-26+ | v1 |
No error handling guidance. If a query fails, times out, or returns no rows, the tool provides no recovery instructions. Error responses should guide the LLM on what to try next (e.g., 'Try with a simpler query' or 'Check connection_id with list_connections').
No pagination or result limiting documented. 'query' and 'schema' tools may return large result sets with no mention of limits, pagination, or cursor handling. Large unbounded results waste context tokens and risk hallucination.
'query' and 'execute' tools lack destructive operation semantics. The pattern:command-tool requires that tools modifying state be explicitly marked so agents know which calls are safe to retry. 'execute' supports INSERT/UPDATE/DELETE but provides no confirmation step or dry-run mode.
No tool annotations visible in schema. The current MCP spec (2026-07-28) expects tools to declare readOnlyHint, destructiveHint, and idempotentHint. Query tools should be marked readOnly=true; execute should be marked destructive=true.
'table' parameter in 'schema' tool marked optional but no guidance on what happens when omitted. Does it return all tables, the current database schema, or an error?