Loading ToolBench
Spring Boot starter for MCP MongoDB tools (multi-instance, find, aggregate, count)
This Spring Boot MCP MongoDB tools server provides 5 read-only tools with solid foundational structure but several notable gaps in parameter documentation and output schema specification. Tool names follow verb_noun convention well (mongo_find, mongo_count, mongo_list_collections, mongo_aggregate, mongo_list_databases). Descriptions are present and reasonably specific (avg ~120 chars), explaining what each tool does and noting MongoDB syntax usage. However, parameter descriptions lack critical constraint details (e.g., filter/projection JSON format requirements, pipeline array structure, limit bounds). Output schemas are not documented in the source, LLMs cannot infer what fields mongo_find returns or how results are structured. All tools are read-only which is appropriate, but the server provides no error handling guidance, no pagination for potentially large result sets, and no validation feedback for invalid JSON filters. The multi-instance database registry pattern is well-designed, allowing users to specify which MongoDB instance via the 'database' parameter.
Executes a MongoDB aggregation pipeline on a collection. The pipeline is a JSON array of stages.
Counts documents in a MongoDB collection, with optional filter
Finds documents in a MongoDB collection. Filter and projection use MongoDB JSON syntax. Default: max 50 documents.
Lists all collections in the configured MongoDB database
Lists the MongoDB instances configured in the MCP server. Each name can be used as the 'database' parameter in other MongoDB tools.
Output schemas not documented. The source code does not specify what fields mongo_find, mongo_count, mongo_list_collections, mongo_aggregate, and mongo_list_databases return. LLMs cannot plan downstream operations or extract specific fields without knowing the response structure.
Parameter descriptions lack constraint specifications. The 'filter' and 'projection' parameters in mongo_find and mongo_count state 'JSON filter, e.g. {"status": "active"}' but do not explain what happens if invalid JSON is passed, whether empty filters are allowed, or if MongoDB special operators ($gt, $in, etc.) are supported. The 'pipelineJson' in mongo_aggregate similarly lacks stage documentation. LLMs will guess on valid input formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No error handling guidance. The source shows tool implementations but no documented error recovery paths. What happens if a collection does not exist? If JSON parsing fails? If a filter matches too many documents? Providing error classification and recovery suggestions (e.g., 'Collection not found. Call mongo_list_collections to see available collections.') would prevent LLM dead-ends.
No pagination support. The mongo_find tool accepts a 'limit' parameter (default 50, max 200) but there is no cursor, offset, or next_token mechanism for iterating large result sets. If a collection has 10,000 matching documents, the LLM cannot retrieve them all or continue from a position. This blocks common patterns like 'show me all documents matching this filter'.
Database parameter resolution is implicit. The 'database' parameter description states 'If omitted, uses the first available.' This is vague, which MongoDB instance is 'first'? What order are they registered in? An LLM cannot reliably pick the intended database without explicit enumeration. Consider returning an enum of available database names or requiring explicit selection.
No result count guidance. The mongo_find description states 'Default: max 50 documents' but does not clarify whether the agent should expect exactly 50, up to 50, or whether the limit can be increased. The 'limit' parameter description says 'default 50, max 200' but does not warn about performance implications of large limits or explain the result structure (is it a list? a map with 'results' and 'count' fields?).