Loading ToolBench
MCP server for MongoDB user management and data search operations
The server has 2 tools with explicit schemas and basic descriptions. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names are action-oriented (insert_user, search_data) which is positive. Parameter descriptions exist but are minimal and lack formatting constraints. Schemas are present as Zod objects but output schemas are not formally documented. Error messages are returned but lack recovery guidance. The server is at the C/D boundary, functional but with substantial room for improvement.
Insert a new user into MongoDB
Search data from any MongoDB collection dynamically
Parameter descriptions are minimal and lack actionable constraints. E.g., 'Name is required' (name param) and 'Invalid email' (email param) do not explain format, length, or examples. 'Invalid email' is not a description of what the parameter does, it's a validation error message.
Output schemas are not documented. The tools return JSON text in a content array, but there is no formal declaration of what fields the response will contain, their types, or their purpose. LLMs cannot plan downstream calls or extract structured data without knowing the output shape.
Error handling is present (isError flag, error text) but does not guide recovery. Errors return raw exception messages (e.g., 'Error searching data: <error.message>') without suggesting what the LLM should do next. A 'not found' error should suggest alternative tools or show available options.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
The search_data tool accepts any collection name as input without validation or enumeration. This is a security risk, an LLM could be tricked into querying internal/sensitive collections (e.g., 'admin', 'logs'). Additionally, the description says the tool is for 'dynamic' querying but does not enumerate available collections or document the permission model.
Tool descriptions lack context on when to use each tool vs alternatives. 'Insert a new user into MongoDB' tells the LLM what the tool does but not why it should choose this over other methods or what prerequisites must be met (e.g., must have email uniqueness validation).
The search_data tool has no result limit enforcement in the description. While the schema sets max=100 and default=20, the description does not state this limit. LLMs may not realize that results are capped and may expect a full dataset, leading to incorrect usage.
insert_user adds a 'createdAt' field server-side but does not document this in the output. The LLM (and the user) will be surprised to see this field in the response. Document what fields are returned and why.
The insert_user tool does not check for email uniqueness before inserting. MongoDB will accept duplicates unless a unique index is declared. If duplicate emails should be prevented, add validation or document this limitation.