A professional MCP (Model Context Protocol) server implementation with plugin system supporting multiple database backends (MongoDB, MySQL, PostgreSQL, SQL Server, Redis) and OpenAPI/Swagger parsing
This is a multi-database MCP server with 13 tools across MongoDB, MySQL, PostgreSQL, and Redis. Tool definitions ARE visible in the code (packages/*/src/index.ts), with proper JSON Schema input parameters and descriptions. The server is functionally organized but lacks the polish and documentation required for confident production recommendation.
Tools (13)
mongodb_countread onlysource verified63/100
Count documents in a MongoDB collection
mongodb_findread onlysource verified62/100
Find documents in a MongoDB collection
mongodb_insert_manywritesource verified65/100
Insert multiple documents into a MongoDB collection (requires FULL mode)
mongodb_insert_onewritesource verified65/100
Insert a single document into a MongoDB collection (requires FULL mode)
Output schemas completely undocumented. No tool declares what fields it returns (e.g., mongodb_find does not specify whether it returns raw documents or wrapped in a 'results' object, or what metadata is included). LLMs cannot plan downstream operations without knowing response structure.
Parameter descriptions lack actionable constraints. For example, 'filter' is described as 'Query filter object (MongoDB query syntax)' but does not specify: allowed operators ($eq, $in, $gt, etc.), nested object structure, required vs optional fields, or what happens if filter is invalid. LLMs cannot safely construct queries without this.
mongodb_findmongodb_countmysql_querymysql_execute
Recommendations
Document output schema for every tool. For mongodb_find, specify: 'Returns {"documents": [...], "count": number}' where each document is a MongoDB document (with _id, user fields). For mysql_query, specify: 'Returns {"rows": [...], "rowCount": number}' where each row is an object with column names as keys. Add return type to tool definition or description.
Upgrade parameter descriptions with constraints and examples (without literal example values in descriptions). For filter, write: 'Query filter using MongoDB operators ($eq for equality, $in for array membership, $gt/$lt for comparisons, etc.). Example structure: {"status": "active", "age": {"$gt": 25}}. Invalid operators are rejected.' For params (SQL), write: 'Positional or named parameters for safe parameterized queries. Count must match placeholders (?) in query. All values are escaped; do not concatenate strings into query.'
Add error guidance to tool descriptions. For insert_one, add: 'Errors: duplicate key (document with same _id already exists, use find first to check), invalid document (field validation failed, check schema), database/collection does not exist. Retryable: no. Contact support if database is missing.'
Implement dry-run parameter for all write tools (mongodb_insert_*, mysql_execute, postgres_execute, redis_set). Add optional 'dry_run': boolean parameter. When true, return what WOULD happen (e.g., 'Would insert 5 documents') without committing. LLMs can preview before executing.
Add pagination to discovery and list tools. For mysql_list_tables and postgres_list_tables, add optional 'limit': number (default 100) and 'offset': number (default 0) parameters. Return {"tables": [...], "total": number, "limit": 100, "offset": 0} so agents know if more results exist.
Score history
Overall score trend
↑ 49 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
2026-07-28+
v2
2026-03-09
F
0
-
v1
read onlysource verified62/100
Execute a SELECT query on MySQL database
postgres_executewritesource verified63/100
Execute an INSERT, UPDATE, DELETE, or DDL query (requires FULL mode)
STDIO-only transport. The server is not remotely accessible and cannot be used by hosted MCP clients or integrated into cloud-based agent platforms. No HTTP or SSE transport option visible.
No error handling documentation. Tool descriptions do not indicate what errors can occur, whether they are retryable, or what the LLM should do next. For example, mongodb_insert_one does not say: 'Returns error if database does not exist' or 'Duplicate key error if _id already exists, check if document exists first.'
No dry-run or confirmation for destructive operations. mongodb_insert_many, mysql_execute (DELETE/UPDATE), postgres_execute (DELETE/UPDATE), and redis_set all modify state but lack a safe preview or confirmation mechanism. An agent mistake could silently corrupt data.
Generic parameter descriptions in query tools. 'params' in mysql_query and postgres_query is described as 'Query parameters for parameterized queries' but does not explain: expected order (positional?), type safety (are values auto-escaped?), or what happens if params length does not match placeholders. Forces LLM to guess.
No pagination guidance in discovery tools. mysql_list_tables and postgres_list_tables do not specify: are results limited? Are they sorted? Can they be filtered? What if there are 1000+ tables, does the tool truncate or fail? Agents cannot safely iterate large result sets.
mongodb_find combines multiple orthogonal concerns (filtering, projection, sorting, pagination) in one tool. More granular tools (mongodb_find_by_filter, mongodb_get_field_projection, mongodb_sort_results) would reduce parameter explosion and improve composability. Current design makes simple queries verbose.
Inconsistent naming across databases. MongoDB uses 'mongodb_' prefix, MySQL uses 'mysql_', PostgreSQL uses 'postgres_', Redis uses 'redis_'. Within MongoDB, all are verbs (find, count, insert_one). Within SQL, discovery tools use list_ and describe_. This is marginally acceptable but could be more consistent across similar operations (e.g., all discovery tools should be list_<resource>).
Split mongodb_find into more granular tools or document the parameters more precisely. Either create separate tools (mongodb_find_with_filter, mongodb_project_fields, etc.) or add to the description: 'All parameters (filter, projection, sort, limit, skip) are optional. If none provided, returns all documents (limited to 100 by server). Projection: {"fieldName": 1} includes, {"fieldName": 0} excludes. Sort: positive number for ascending, negative for descending.'
Standardize discovery tool naming. Use list_* for all discovery operations across databases (list_mongodb_collections, list_mysql_tables, list_postgres_schemas). This reduces cognitive load for LLMs and improves pattern recognition.
Add validation error responses with actionable guidance. When an LLM passes invalid filter syntax to mongodb_find, return: 'Invalid filter syntax. Expected MongoDB query object like {"field": value} or {"field": {"$operator": value}}. Your filter was: ...'. This lets LLMs self-correct in the same turn.
Document connection handling and defaults. The descriptions mention '(uses default if not specified)' for database/schema but do not explain what the default is. Add to tool descriptions: 'If database is omitted, uses DATABASE env var or configured default. If not set, returns error: "No database specified."'
Add rate limiting or result limits. Specify in descriptions: 'mongodb_find returns maximum 1000 documents per call. If filter would match more, use skip/limit for pagination.' This prevents LLM from accidentally requesting millions of documents.