Loading ToolBench
MCP server for database operations supporting MongoDB, PostgreSQL, and MySQL
dbmcp-server provides 13 tools across MongoDB and MySQL with basic schema coverage, but suffers from significant gaps in naming consistency, parameter descriptions, and output documentation. All tools ARE registered with schemas and descriptions (visible in source), but many descriptions are perfunctory (20-40 chars), parameter annotations lack detail, and output structures are undocumented. Tools mix database types (MongoDB + MySQL) without clear domain separation. No tool-chaining IDs explicitly documented in responses. Error handling is delegated to generic handleError() but lacks recovery guidance. This is a functional but below-average implementation.
Run an aggregation pipeline on a collection
Describe the indexes for a collection
Describe the schema for a collection
Gets the size of the collection
Get column types for a table
Count documents in a collection matching a filter
Returns statistics that reflect the use state of a single database
list-databases has NO description (empty string). Violates pattern:tool-description which requires every tool to have a non-empty, actionable description so LLMs can decide when to call it.
Multiple tools have perfunctory descriptions under 50 characters (e.g. 'Describe the indexes for a collection', 'Gets the size of the collection'). These lack context on WHEN to call the tool vs alternatives, WHY it exists, and what the LLM should expect.
Parameter descriptions are minimal or absent. 'filter' params in find(), count(), aggregate(), explain() are documented only as 'MongoDB filter query as JSON string', no hint on format (JSON object stringified?), no examples of valid filters, no link to MongoDB docs. LLMs cannot infer validity constraints from bare descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Explain the query plan for a find operation
Query documents in a collection
List all collections in a database
List all databases
Get logs from MongoDB database
Execute a SQL query
Output schemas are completely undocumented. None of the 13 tools document what fields are returned, what types they have, or what IDs/references are needed for tool chaining. A find() response structure is unknown, does it return documents as an array? Does it include total count? Are pagination cursors present? LLMs cannot compose downstream calls (e.g. aggregate on filtered results) without knowing output structure.
Mixed database domains (MongoDB + MySQL) with no clear separation or delegation logic. Tools are registered with names like 'query' (MySQL) and 'find' (MongoDB), similar sounding, different databases. LLMs may confuse which to call. Source does not show explicit filtering/gating to prevent cross-DB calls (e.g. calling 'query' when only MySQL is connected).
Generic error handling via handleError() method returns only 'Error running {tool}: {message}' with no recovery guidance. Rubric pattern:recovery-guide requires errors to tell LLM what to do next (retry? ask user? search for alternative?). No categorization of retryable vs fatal errors. No actionable suggestions like 'Try list-databases() first to verify connection.'
No pagination support visible in list-* or find tools. If list-collections or find return many results, no limit/offset/page parameters are documented. Absence forces LLMs to request thousands of items and blow context window.
Tool names are descriptive but not action-centric. 'collection-indexes', 'collection-schema', 'collection-storage-size' use noun_noun pattern rather than action verbs. Better: 'get-indexes', 'describe-schema', 'get-storage-size'. Current names require LLM to infer 'get' intent.
No tool annotations for safety/idempotency. Code defines ToolAnnotations with title/description but does NOT populate destructiveHint or idempotentHint. All 13 tools are READ_ONLY so should explicitly mark them as idempotent + readonly for agent confidence. Current spec expects tool annotations for operation classification.