Loading ToolBench
MCP Server for MongoDB access to search cars
The server defines 2 tools with proper FastMCP registration and JSON Schema input schemas. However, critical issues significantly limit quality: (1) Schema completeness is weak, the `query` parameter in get_cars accepts a generic dict/object without field constraints, limiting LLM understanding of valid MongoDB queries; (2) Descriptions are verbose and include implementation details (e.g., escaped quotes syntax, attribute listing) that clutter rather than clarify intent; (3) No structured output schema documentation, tools return strings (likely JSON-serialized), but the expected response structure is undocumented, forcing LLMs to parse unstructured text; (4) Parameter validation and error handling are minimal; (5) No tool annotations (readOnlyHint, destructiveHint) despite clear risk profiles (get_cars is read-only, save_to_file is destructive).
Get cars from MongoDB database. Args: query (dict): Dict query in JSON format for mongoDB, with -attributes- for search cars. limit (int): Limit the number of output. 0 = No limit. sort_by (str): Optional. Field name to sort the results by. sort_dir (str): Optional. Sorting direction. Use 'asc' for ascending or 'desc' for descending. Examples: # Correct format with escaped quotes: {`query`: `{\"year\": 2025}`} # Multiple fields example: {`query`: `{\"year\": 2025, \"brand\": \"Toyota\"}`} # Sort {`query`: `{\"year\": 2025}`, `sort_by`: `price`} {`query`: `{\"year\": 2025}`, `sort_by`: `price`, `sort_dir`: `asc`} Attributes: brand (str), model (str), year (int), price (float), engine (str), fuel_type (str), color (str), mileage_km (int), doors (int), transmissio (str), segment (str), cargo_capacity_liters (int), suspension (str), drivetrain (str), fuel_consumption_km_per_l (float), horsepower_hp (int)
Save content to a PDF file. Args: title (str): The title for the document and file, with a maximum of 150 characters. content (str): The pure text content to be saved in the file. Instructions: Do not use HTML, Markdown, Json or XML sintaxe
Missing output schema documentation for both tools. get_cars returns string (likely JSON), save_to_file returns string (unclear format). LLMs cannot plan downstream operations without knowing response structure.
The 'query' parameter in get_cars is an unconstrained generic object/dict with no field validation, pattern, or examples of valid MongoDB query syntax. This violates the constrained-input pattern and leaves LLMs guessing valid query structure.
Tool descriptions include implementation details (e.g., 'escaped quotes', backtick syntax examples in get_cars; 'Do not use HTML, Markdown, Json or XML' without rationale in save_to_file) that should be in internal docs, not LLM-facing descriptions. Descriptions should focus on WHAT and WHEN, not HOW.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No tool annotations present. get_cars should declare readOnlyHint=true (safe to retry); save_to_file should declare destructiveHint=true (creates file, side effect). Annotations guide agent retry logic.
'title' parameter in save_to_file specifies 'maximum of 150 characters' in description but not in JSON Schema (no maxLength). Schema constraints are not enforced, forcing validation at runtime with unclear error messaging.
No error handling or recovery guidance documented. What happens if MongoDB is unreachable? If query is syntactically invalid? If title contains invalid filename characters? Error responses should categorize as retryable/user-fixable/fatal and suggest next steps.
get_cars accepts an unconstrained 'limit' integer (default 0 = no limit). No bounds documented. LLMs could pass limit=999999, causing excessive database load or timeout. Should enforce minValue/maxValue in schema.