Loading ToolBench
Tasqr MCP server — task state management for AI agents
Tasqr MCP has well-structured tool names (verb_noun pattern) and reasonable descriptions (80-120 chars), but critical gaps undermine production readiness. Input schemas are present but lack parameter-level type definitions and descriptions, parameters like 'task_id', 'title', 'description', 'metadata', 'output', 'note' have no individual descriptions explaining constraints, formats, or validation rules. Output schemas are completely undocumented, LLMs cannot infer what fields are returned or plan downstream calls. Error handling is absent from visible code; no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Security concern: credentials stored in plaintext INI files (~/.config/tasqr/credentials) with chmod 0o600, but no mention of encryption at rest or key rotation. Encryption is mentioned in descriptions but implementation details (algorithm, key derivation) are opaque to the LLM. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write semantics.
Claim the next available task from the queue with decrypted sensitive fields
Create one or more tasks with encrypted sensitive fields (title, description, metadata)
Retrieve one or more tasks by ID with decrypted sensitive fields
List tasks with pagination and filtering, with decrypted sensitive fields
Update one or more existing tasks with encrypted sensitive fields (title, description, metadata, output, note)
Output schemas completely undocumented. LLMs cannot infer what fields are returned by create_tasks, update_tasks, get_tasks, list_tasks, or claim_next_task. This breaks tool chaining, if get_tasks returns task_id, agents cannot plan to pass it to update_tasks without guessing.
Input parameters lack individual descriptions and type constraints. 'metadata' is typed as 'object' with no description of its structure, required fields, or validation rules. 'task_id' has no description of format (UUID? string? length?). LLMs cannot validate inputs or self-correct.
No error handling guidance visible. No indication of retryability, user-fixable errors, or recovery paths. If create_tasks fails due to invalid metadata, LLM has no guidance on what to do next.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2025-06-18+ | v2 |
No tool annotations despite clear semantics. get_tasks and list_tasks should have readOnlyHint=true. create_tasks, update_tasks, claim_next_task should have destructiveHint=true. Agents cannot distinguish safe from risky operations.
Encryption implementation opaque to LLM. Descriptions say 'encrypted' but do not specify algorithm, key derivation, or whether decryption is automatic. LLMs cannot reason about data sensitivity or compliance implications.