Loading ToolBench
MCP server for integrating with Habitica task management and gamification platform
Server has 5 tools with basic descriptions and parameter schemas, but significant gaps limit production readiness. Tool names follow verb_noun convention (get_, update_, add_) which is good. However, descriptions lack depth, most are 1-2 sentences without WHEN to use guidance or prerequisites. Parameter descriptions exist but are minimal (e.g., 'The ID of the task to retrieve'). No output schemas documented. The update_task tool accepts a free-form dict with 20+ allowed fields documented only in the docstring, not in schema constraints, LLMs cannot validate these without parsing text. Error handling is absent: no recovery guidance, no categorization of retryable vs fatal errors. No pagination support despite get_user_tasks potentially returning large lists. Credentials (API_KEY, USER_ID) are injected via environment, which is correct, but no mention of rate limiting or permission scopes.
Add a tag to a task Args: task_id: The task _id or alias tag_id: The tag id (UUID)
Get a specific task by ID Args: task_id: The ID of the task to retrieve
Get all user tags for the authenticated user as an array of tag objects
Get all tasks for the authenticated user Args: task_type: Optional filter for task type (habits, dailys, todos, rewards, completedTodos)
Update a specific task by ID Args: task_id: The ID of the task to update updates: Dictionary containing the fields to update and their new values. Allowed fields: - text (str): The text to be displayed for the task - attribute (str): User's attribute to use. Options: "str", "int", "per", "con" - collapseChecklist (bool): Determines if a checklist will be displayed. Default: false - notes (str): Extra notes - date (str): Due date to be shown in task list. Only valid for type "todo" - priority (float): Difficulty. Options: 0.1 (Trivial), 1 (Easy), 1.5 (Medium), 2 (Hard). Default: 1 - reminders (list): Array of reminders, each with UUID, startDate and time - frequency (str): For daily tasks. Options: "daily", "weekly", "monthly", "yearly". Default: "weekly" - repeat (dict): For daily tasks with weekly frequency. Days: su, m, t, w, th, f, s - everyX (int): For daily tasks. Days until task is available again. Default: 1 - streak (int): For daily tasks. Consecutive days checked off. Default: 0 - daysOfMonth (list): For daily tasks. Array of integers - weeksOfMonth (list): For daily tasks. Array of integers - startDate (str): For daily tasks. Date when task becomes available - up (bool): For habits. Enables "+" for "Good habits". Default: true - down (bool): For habits. Enables "-" for "Bad habits". Default: true - value (float): For rewards. Cost in gold. Default: 0
update_task accepts a free-form dict with 20+ allowed fields documented only in docstring text, not in JSON Schema. LLMs cannot validate field names or types without parsing natural language. This violates constrained-input pattern.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., task_id from get_user_tasks result). Violates tool-description and response-shaper patterns.
get_user_tasks lacks pagination (limit, offset, page_size params) and no mention of result capping. Large task lists will blow context window. Violates paginated-result pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No error handling guidance. Exceptions are raised as generic 'Failed to X' messages with no recovery hints, categorization, or actionable next steps. Violates recovery-guide and error-classification patterns.
Descriptions are too brief (10-50 chars) and lack context. E.g., 'Get a specific task by ID' does not explain when to use this vs get_user_tasks, or what fields the response contains. Violates tool-description baseline (target 50-200 chars).