A secure, vector-based task management server for Claude Desktop using sqlite-vec and sentence-transformers for semantic search and task retrieval
Vector Task MCP has a solid foundation with 10 well-named tools using verb_noun conventions (task_create, task_update, task_delete, task_get, task_list, task_search, task_stats, task_add_comment, task_normalize_tags, cookbook). Descriptions are present for all tools and most parameters. However, critical gaps exist: (1) Output schemas are NOT documented anywhere in the source, LLMs cannot see what fields are returned, which violates the 'Document the output schema' pattern; (2) Several parameter descriptions lack specificity about format/constraints (e.g., priority values 'low, medium, high, critical' are stated in the description but not as enums in the schema, forcing LLMs to infer valid values); (3) Task tags are described as 'List of tags (optional)' without specifying max length, character restrictions, or deduplication rules; (4) Similarity threshold parameters (threshold 0-1) lack guidance on what values mean (0.5 = moderate similarity? 0.9 = very similar?); (5) Descriptions are generally adequate (100-150 chars) but miss context about when to use related tools (e.g., when to call task_search vs task_list). The security validation module is present and used (validate_tags, validate_task_list_params), showing good internal discipline, but this is not visible in the tool definitions themselves. Naming is A-grade; schema/output documentation is C-grade.
Quick reference guide for vector task MCP with 5 modes: init (quick start), docs (usage guide), cases (use cases), categories (case categories), all (everything)
Add a comment to a task
Create a new task with optional parent task, tags, priority, estimate, and order
Delete a task by ID
Get a task by ID with full details
List tasks with filtering and pagination
Normalize and deduplicate similar tags across all tasks using semantic similarity
Output schemas are not documented. Tool definitions show input schemas but provide no specification of what fields are returned by each tool. This prevents LLMs from knowing what data is available for downstream tool calls or response composition.
Priority and status enum values are documented in descriptions ('low, medium, high, critical' and 'open, in_progress, resolved, closed') but NOT defined as JSON Schema enums. LLMs cannot reliably parse prose enumerations and may hallucinate invalid values. Use proper 'enum' constraints in the input schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Search tasks using vector embeddings for semantic similarity
Get task statistics and breakdown by status, priority, and tags
Update an existing task's properties (status, priority, content, tags, estimate, time spent, etc.)
Parameter descriptions lack format/constraint details. Examples: 'estimate' is 'Time estimate in hours (optional)' but no min/max specified (0-1000 hours? fractional hours allowed?); 'tags' is 'List of tags (optional)' with no length, character, or dedup rules; 'threshold' (0-1) has no guidance on semantic interpretation. Add ranges, patterns, and examples to descriptions.
Destructive tool descriptions lack guidance. task_delete says 'Delete a task by ID' but does not state whether this cascades to subtasks, is reversible, or affects historical records. Agents need to know consequences before executing irreversible operations.
No tool-selection guidance in descriptions. task_search and task_list both retrieve tasks; the descriptions do not explain when to use each (semantic vs. filter-based). Add dependency hints like 'Use task_search for natural-language queries; use task_list for structured filtering by status/priority/tags.'
Missing error-recovery guidance. No descriptions explain what to do if a task_create fails (e.g., 'If parent_id does not exist, call task_get to verify the parent task first'). Error responses are not documented.