Loading ToolBench
A Model Context Protocol server for MySQL and MongoDB database operations. Fork of @enemyrr/mcp-mysql-server with added MongoDB support.
This server has significant definition quality gaps. Tool naming is reasonable (verb_noun pattern), but descriptions are inconsistent and parameter documentation is sparse. Most critically, the tools lack proper input/output schema documentation, and many parameters are missing descriptions. Error handling is present but generic. The server combines MySQL and MongoDB into a single server with overlapping tool names (e.g., both 'query' tools would conflict in a unified tool list), which violates the single-responsibility principle. No output schemas are documented, making it difficult for LLMs to plan downstream tool chaining. Security is a major concern: connection credentials are passed as tool parameters rather than using server-side injection, violating critical pattern:secret-injection guidelines.
Connect to MySQL database using URL or config
Connect to MongoDB database using URL or config
Create a new table in the database
Get table structure
Execute an INSERT, UPDATE, or DELETE query
List all tables in the database
Execute a SELECT query
CRITICAL SECURITY: Database credentials (user, password, host, database) exposed as tool parameters. This violates pattern:secret-injection, credentials will appear in logs, traces, and prompt history. Must use environment variables or server-side vault injection.
Output schemas completely undocumented. LLMs cannot plan tool chaining without knowing what fields each tool returns. All tools lack returnType or documented response structure.
Parameter descriptions missing or incomplete. 'sql' in query/execute lacks guidance on acceptable query types, length limits, or injection concerns. 'params' array is undescribed regarding type coercion or null handling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Vague tool names cause disambiguation confusion. 'query' could mean SELECT or search; 'execute' could mean any SQL statement. 'query_database' and 'execute_update' would be clearer. The name 'execute' is too generic (see pattern:tool naming baseline, avoid 'process', 'handle', 'run', 'do').
No output pagination support documented. If list_tables returns thousands of tables, results will blow the context window. No limit parameter, no total_count, no next_cursor in documented schema.
No idempotency guarantees documented. Agents retry on failures, if create_table is not idempotent, retrying a failed creation could error with 'table already exists'. No documentation of create/update idempotency behavior.
Error handling is minimal and non-actionable. Code catches errors with McpError but provides no recovery guidance. E.g., 'Invalid query' tells LLM nothing, should be 'Query must be SELECT only. INSERT/UPDATE/DELETE require the execute tool.'
No destructiveHint or readOnlyHint annotations present. The toolAnnotations feature is false, but tools like 'execute' and 'delete' (if implicit) should declare destructiveHint:true so LLMs can apply caution.
MongoDB and MySQL tools mixed in single server without namespace separation. Both accept 'database' parameter but mean different things. A single 'query' tool cannot apply to both backends. Architecture violates single-responsibility principle.
No input validation constraints documented. 'table' in describe_table accepts any string, no guidance on case sensitivity, allowed characters, or SQL injection prevention. Parameter descriptions must include format and validation rules.