Loading ToolBench
MCP server with task management and YouTube video summarization capabilities
This server exhibits significant definition quality gaps across nearly all 7 tools. Most tool descriptions are either missing or minimal, input schemas are underdocumented or rely on vague type declarations, and parameter descriptions are sparse or absent. The server uses FastMCP and HTTP transport, but the tool definitions do not meet production-grade standards. Only 3 of 7 tools have semi-structured descriptions (using the RichToolDescription model); 4 tools lack formal parameter documentation. Parameter schemas for 'create_task' are minimally typed (object with no required fields declared). No tool output schemas are documented. Error handling is minimal, tools return simple success messages without recovery guidance or classification. The 'about' and 'validate' tools are informational but trivial. The core task-management tools (list_tasks, create_task, delete_task, update_task) lack clear descriptions of expected inputs and outputs. The YouTube summarizer tool has no parameter documentation. Overall, this server reads as a rapid prototype with limited attention to LLM-friendly interface design.
Returns server name and description including information about the task manager and YouTube summarizer capabilities
Create a new task with title, due date, and status. Always follow up with listing tasks to confirm creation. You have to return the title of the task, the due date and the status of the task in the following format strictly of JSON object without any markdown or any other formatting example is show below: { "title": "Task Title", "dueDate": "Due date mentioned by the user", "status": "Pending" }
Delete a task by its ID. If you don't have the ID, first call list_tasks to retrieve it. If user wants you to delete all the tasks, then delete them one by one. Do not ask user to proceed further. Just do what is necessary to server user's query. If the user wants to delete all the tasks at once then fetch taks IDs of all the tasks and then delete one-by-one.
Retrieve all current tasks from the database as JSON (for AI) and markdown (for human display).
Summarize YouTube video using the link provided by the user.You have to summarize the video transcript in detail.
create_task input schema is vague and lacks required field declarations. The 'task' parameter is typed as object with nested properties (title, dueDate, status) but does not declare which are required, their exact types (string vs enum), or constraints (e.g., date format).
summarize_youtube_video has only a bare parameter 'video_link' with minimal type info. No validation rules (must be valid YouTube URL), no handling of invalid URLs, no output schema documented.
delete_task and update_task descriptions are overly verbose, contain procedural instructions for the LLM ('Do not ask user to proceed further. Just do what is necessary...'), and lack clarity on what the tool actually returns. The delete_task description is 437 chars (exceeds 1024 threshold guidance but is awkwardly detailed for operational clarity).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Update the status of a task by its ID. If you don't have the ID, first call list_tasks to retrieve it. Do not ask user to proceed further. Just do what is necessary to server user's query. If you get any task ID related errors just call the list_task tool and then proceed further. At first you will not be given the task ID, you will be given all the data from the database and based on that data you have to find the task ID and then pass that task ID to the tool's argument. Then the task will be deleted.
Validation tool to confirm the MCP server is reachable.
No tool output schemas documented. Callers cannot know what fields to expect (e.g., is 'tasks_json' always present? What are the field types? Is 'message' a success indicator or error?). This forces LLMs to reason about response structure instead of relying on formal schema.
delete_task and update_task parameters (task_id, status) lack enum constraints or validation rules. task_id is a bare string, no description of what constitutes a valid MongoDB ObjectId format. status has no enum (pending, started, completed) declared, inviting hallucinated values.
Error handling is minimal. create_task, delete_task, and update_task return a 'message' field but do not classify errors (retryable vs user-fixable vs fatal) or provide recovery guidance. If delete_task fails (e.g., invalid ObjectId), the LLM has no hint what to do next.
Credentials and config (MongoDB connection string, TOKEN, MY_NUMBER) appear to be hardcoded or blank in the tool.py sample. No evidence of secret injection via environment variables or vault. If TOKEN or MY_NUMBER are meant to be secrets, they must not appear in tool parameters.
No permission checks or scope declarations. delete_task and update_task are destructive but lack authorization gates. No audit trail or logging of who called what tool at what time.
Tool descriptions contain instructions for the LLM (e.g., 'Always follow up with listing tasks to confirm creation') rather than declarative descriptions of what the tool does. This conflates agent orchestration with tool semantics and bloats descriptions with procedural guidance the LLM should infer from context.
validate() returns MY_NUMBER, which is blank in the sample. This tool's purpose is unclear, validation should confirm reachability or health, not return an opaque number. If this is a debug token, it should not be exposed as a tool.