A task management MCP server that provides tools to list, create, and update tasks stored in a SQLite database
Task-manager has three tools with basic schemas and minimal descriptions. All tools have input schemas with proper JSON types, but descriptions are extremely terse (10-14 chars), violating the 10-1024 char guideline and failing to explain WHEN/WHY to use each tool. No parameter descriptions exist, LLMs cannot infer what 'title', 'description', 'status', or 'id' mean in context. No output schema documentation. Error handling is absent; tool failures return generic strings with no recovery guidance. Naming is acceptable (verb_noun pattern) but descriptions are critically underdeveloped.
Create a new task
List all tasks
Update task
All tool descriptions are under 20 characters and provide no context for LLM selection. 'List all tasks', 'Create a new task', 'Update task' fail to explain WHEN to use each tool, what they return, or prerequisites.
No parameter descriptions exist. LLMs cannot infer that 'title' is required, 'description' is optional, 'status' accepts specific values, or 'id' is a task identifier. Parameters lack type hints in descriptions.
No output schema documented. LLMs do not know what fields task_list returns, what create_task returns (just ID? full task object?), or what update_task confirms. Breaks downstream tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
No error handling or recovery guidance. Tool failures return generic strings ('Unknown tool', 'No fields to update') with no actionable next steps for the LLM.
update_task accepts 'status' as free-form string with no enum constraint. LLMs will hallucinate invalid status values. No validation or constraint documentation.