Loading ToolBench
A MongoDB interface for AI agents using Model Context Protocol
MongoDB MCP server provides 5 tools with explicit schemas and descriptions. All tools have documented input schemas (critical baseline met). However, several gaps emerge: (1) tool descriptions are minimal (13 - 26 chars), falling far below the 194-char baseline and failing the 20-char floor for meaningful descriptions; (2) output schemas are completely undocumented, responses are inferred but never formally defined; (3) error handling provides no recovery guidance; (4) parameter descriptions exist but lack detail on format, constraints, or expected values; (5) no indication of pagination support in list operations. The tools themselves are well-named and directly mapped to MongoDB operations, but execution quality is constrained by incomplete documentation.
Create a new index on a collection
Delete a single document from a collection
Drop an index from a collection
List all indexes for a collection
List all available collections in the database
Output schemas completely undocumented. Tool responses (content, isError, _meta) are inferred from BaseTool.to_dict() but never formally declared. LLMs cannot know what fields to expect or plan downstream calls.
Tool descriptions far too short (13 - 26 chars vs. 194-char baseline). 'List all available collections in the database' (13 chars, for listCollections) and 'Delete a single document from a collection' (20 chars, for deleteOne) provide minimal context for LLM selection. Descriptions should explain WHAT, WHEN, and any prerequisites. See rubric pattern:tool-description baseline (194 chars, p10=34, p90=392). Descriptions under 20 chars trigger mandatory floor score cap.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter descriptions lack actionable detail. 'Filter to select the document to delete' (for deleteOne.filter) is vague, expected format (MongoDB query object), constraints, and examples are missing. 'Name of the collection to create an index on' (for createIndex.collection) omits valid character ranges, naming conventions, or size limits. No descriptions explain format (ISO 8601 for dates?), ranges (numeric mins/maxs?), or alternatives (ID vs. name acceptance).
No error recovery guidance. Tools return errors via handle_error() (e.g., 'Collection name must be a string') but never suggest next steps. Pattern:recovery-guide requires: 'User not found. Try search_users() with a partial name.' Current errors leave the LLM stuck.
deleteOne is destructive but lacks confirmation/dry-run support. No evidence of a confirm_before_execute pattern. Irreversible operations should allow agents to review impact before committing. See pattern:confirmation-request.
listCollections and indexes have no pagination support. Input schemas lack limit, offset, or page parameters. Tool description says nothing about result capping. If a database has 1000 collections, will listCollections return all? Uncapped result sets blow context windows and violate mxe:enforce-result-limits.
Parameter 'filter' in deleteOne accepts untyped object with no format specification. 'Filter to select the document to delete' does not explain MongoDB query syntax (equality, $eq, $gt, etc.). LLMs may pass invalid query shapes.
No tool annotation hints. No evidence of readOnlyHint, destructiveHint, or idempotentHint in schema declarations. These are optional but improve agent safety planning (current spec baseline reward for inclusion).