Loading ToolBench
MongoDB MCP Server for AITimes article management with Supabase image storage
This MCP server has 6 tools with explicit schema registration via the @tool decorator. However, there are significant gaps in parameter descriptions, schema completeness, and error handling guidance. All tools have basic descriptions (10-50 chars), which are below the production baseline of 194 chars. Parameter descriptions are sparse or missing for several tools. Error handling returns only a generic success/error structure without recovery guidance. The tool composition is reasonable (CRUD operations on articles + file upload), but descriptions lack the 'WHAT, WHEN, WHY' clarity needed for robust LLM-driven selection.
Create a new article with thumbnail and optional video upload to Supabase
Delete an article and its thumbnail
Get an article by ID
List articles with pagination
Update an article by ID
Upload a video file to Supabase
Parameter descriptions are minimal or absent. Most parameters (e.g., 'article_id', 'limit', 'offset', 'id', 'title', 'subtitle', 'video_file_path') have 1-line descriptions that do not explain format, constraints, or dependencies. The rubric requires non-empty descriptions for every parameter explaining what it controls, expected format, and any constraints.
Tool descriptions are too brief (10-30 characters, well below the 194-char baseline). Descriptions lack 'WHEN to use this tool' context and do not explain dependencies or prerequisites. For example, 'Create a new article with thumbnail and optional video upload to Supabase' (70 chars) is functional but lacks context on when the LLM should choose this vs. other tools, or what happens if both thumbnail and video are provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No output schema documentation. Tools return success/error structures, but the response shape is not formally documented in tool metadata. The rubric requires documented return types so LLMs know what fields to expect (e.g., when create_article returns, does it include created_at? is the article object complete or summarized?). This forces LLMs to guess and risks downstream tool call failures if expected fields are missing.
Error handling provides no recovery guidance. All tools catch exceptions and return {'success': False, 'error': str(e)}. This raw error string (e.g., 'Supabase connection timeout') gives the LLM no actionable next step. The rubric requires errors to tell the agent: can I retry? Should I call a discovery tool first? Is this unrecoverable? Example: delete_article returns 'Article not found' vs. 'Article not found. Call list_articles to see available articles.'
Parameter name inconsistency in update_article. The schema defines 'id' as the article identifier, but get_article and delete_article use 'article_id'. The rubric requires matching naming across tools: if SearchMessages returns 'message_id', ReplyToMessage must accept 'message_id', not 'id'. This inconsistency forces the LLM to reason about field mappings, increasing errors.
No enum constraints for categorical fields. Parameters like 'limit' (integer, no bounds), and hypothetical status/priority fields (if they exist in the domain) lack constraints. The rubric requires bounds (e.g., limit 1 - 100) and enums for known sets of values to prevent hallucinated inputs.
No confirmation or dry-run for delete_article. Irreversible operations (delete, send, publish) should support a dry-run or confirmation step per the rubric. Agents make mistakes, delete_article should offer a 'confirm_deletion' or at least a preview of what will be deleted.
create_article and update_article expose file paths as parameters ('thumbnail_image_url', 'thumbnail_image_html_screenshot_path'). The rubric discourages exposing file-system details; better to accept a public URL or a resource identifier, and handle file I/O server-side. Exposing paths risks path traversal attacks if LLMs are tricked into passing malicious paths.
Missing pagination metadata in list_articles response. The tool accepts limit and offset and returns a 'count' field, but no 'total' or 'has_more' flag. The rubric requires pagination tools to return sufficient metadata (total count, next_cursor, or has_more) so the LLM can reason about whether more results exist.
No tool annotations. The source code shows no use of 'readOnlyHint', 'destructiveHint', or 'idempotentHint' in tool metadata. The current spec (2026-07-28) recommends tool annotations to help agents reason about side effects and idempotency. list_articles and get_article should be marked readOnly; delete_article should be marked destructive.