Loading ToolBench
Terminal-based habit tracking application with MCP server capabilities
HabitMCP has 9 tools with basic naming and descriptions, but significant gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (Login, Register, GetHabits, etc.), which is good. However, descriptions are minimal (10-50 chars) and lack context on when to use each tool or what happens on failure. Input schemas are present but sparse: most parameters lack type constraints, enums, or validation guidance. No output schemas are documented. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. The server appears to be a TUI wrapper around a habit-tracking API, but the tool definitions do not reflect production-grade agent integration patterns.
Mark a habit as completed on a specific date
Create a new habit for the authenticated user
Delete a habit
Retrieve the current authenticated user's information
Retrieve all habits for the authenticated user
Authenticate user with username and password, returns access token
Register a new user with username and password
Remove a habit completion record for a specific date
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., habitID returned by CreateHabit). Responses are opaque.
Descriptions are too brief (10-50 chars) and lack context. No explanation of when to use each tool, what happens on success/failure, or prerequisites (e.g., Login must be called before GetHabits).
No error handling guidance. Tools do not indicate which errors are retryable, user-fixable, or fatal. No recovery paths (e.g., 'If login fails, try Register first').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
Update an existing habit
Parameter descriptions are generic or missing validation rules. E.g., 'date' parameter in CompleteHabit says 'YYYY-MM-DD format' but no regex pattern or example. 'habitID' is an integer but no range or validation guidance.
No confirmation or dry-run pattern for destructive operations. DeleteHabit is marked DESTRUCTIVE but has no safeguard, confirmation step, or undo tool.