Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
TaskTracker MCP shows consistent structure across 15 tools with descriptions and typed input schemas, but lacks depth in LLM-critical areas. All tools have descriptions (10-30 chars average, some quite terse), and all visible tools have JSON Schema inputs with proper types. However, descriptions are significantly below the 50-200 char baseline for production tools and lack actionable context (WHEN to use, HOW to recover from errors, WHAT the response structure is). Parameter descriptions are present but minimal (e.g., 'The ID of the task to retrieve' is generic). No output schemas are documented anywhere, tools return List[Dict] or Dict but LLMs don't know what fields to expect. Error handling is absent; tools return bare {'error': 'not found'} with no recovery guidance. Tool naming is consistent (verb_noun pattern) but lacks distinguishing detail, get_task vs get_task_tool is redundant. No idempotency, retry guidance, or confirmation steps for destructive operations (delete_task, delete_plan_step). The server is functionally complete for the domain but underutilized in LLM optimization.
Output schemas completely undocumented. Tools return List[Dict] or Dict but no field names, types, or example structures are documented. LLMs cannot plan downstream calls or extract data reliably.
Descriptions are too terse (10-35 chars, well below 50-200 char production baseline). Most are bare imperatives ('Get a specific task by ID') lacking WHEN to use, dependencies, or result hints. E.g., get_notes_tool is just 'Get all notes in the system', what format are notes? Plain text? Markdown?
Document output schemas for all tools. Example: add_task should specify 'Returns: {task_id: string (UUID), title: string, description: string, priority: 1|2|3, status: string, created_at: ISO8601 timestamp}'. Use a consistent schema format (JSON Schema or prose) and include in tool description.
Expand descriptions to 50-150 characters with actionable context. Change 'Get a specific task by ID' to 'Retrieve a task by its ID. Returns task title, description, priority (1-3), and status. Call get_all_tasks_tool first to find the task ID.'
Add enum constraints to JSON Schema for priority and status parameters. Instead of relying on description text, define priority: {type: 'integer', enum: [1, 2, 3], description: '1=highest, 2=medium, 3=lowest'} and status: {type: 'string', enum: ['not_started', 'in_progress', 'completed']}.
Implement pagination for get_all_tasks_tool and get_all_plan_steps_tool. Add optional parameters: limit (1-100, default 20) and offset (default 0). Return: {items: [...], total: number, offset: number, limit: number, has_more: boolean}. Cap default results at 20 to prevent context bloat.
Add recovery guidance to error responses. Instead of {'error': 'Task not found'}, return {'error': 'Task ID xyz not found.', 'available_actions': ['Call get_all_tasks_tool() to list all task IDs', 'Check task_id for typos'], 'suggestion': 'Did you mean task abc123?'} if applicable.
Implement confirmation pattern for destructive operations. delete_task should return {status: 'confirmation_required', message: 'About to delete task: "Buy groceries"', confirmation_token: 'tkn_xyz'} and accept a confirm_deletion parameter before actually deleting. Prevents accidental loss.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error recovery guidance. Tools return bare {'error': 'Task not found'} with no actionable next steps. Spec requires error responses to guide LLM action (retry? lookup? user input?). Example: delete_task on missing task should return 'Task ID abc not found. Call get_all_tasks_tool to list valid task IDs.'
Destructive tools (delete_task, delete_plan_step, import_data) lack confirmation/dry-run pattern. Agents make mistakes, these operations should support a confirmation_required response before executing. Currently irreversible with no warnings.
Tool naming redundancy: get_all_tasks_tool vs get_all_tasks resource; get_task_tool vs get_task resource. The '_tool' suffix is unnecessary, MCP distinguishes tools and resources by protocol, not naming. Rename to get_all_tasks, get_task, etc. LLMs also conflate the similar names.
No pagination support for list operations. get_all_tasks_tool and get_all_plan_steps_tool return all records unbounded. If a user has 500 tasks, the response bloats the context window. Should accept limit and offset params and return a count.
Parameter descriptions lack format/constraint details. E.g., priority is 'Priority level (1-3, with 1 being highest)' but no enum declared in schema; status is 'Current status (not_started, in_progress, completed)' but LLM must parse the description to know allowed values. Should use JSON Schema enums.
Optional parameters not clearly marked. add_task has description, priority, status, unclear which are required. update_task marks all optional in description but schema doesn't reflect required vs optional fields. JSON Schema should use 'required' array.
No idempotency guarantees. If an LLM retries add_task after a transient network error, does it create a duplicate? Agents rely on idempotent tools for safe retry. Should either document idempotency or provide deduplication keys.
file_path in export_data and import_data is a bare string with no validation hints. Should enforce path restrictions to prevent directory traversal attacks (e.g., 'must be under ~/.tasktracker'). Agents can be tricked into passing '../../../etc/passwd'.
export_dataimport_data
Rename tools to remove '_tool' suffix. get_all_tasks_tool → get_all_tasks, get_task_tool → get_task, etc. The '_tool' suffix is redundant in MCP's protocol grammar and adds noise. Keep resources as-is (tasks://all, tasks://{task_id}).
Mark required vs optional parameters explicitly in JSON Schema using the 'required' array. add_task's title should be required; description, priority, status should be optional with sensible defaults (priority=2, status='not_started').
Add idempotency documentation. For add_task, state: 'This tool is idempotent when called with the same title and description within 60 seconds. Subsequent identical calls within that window return the existing task instead of creating a duplicate.' Provide a deduplication key if applicable.
Secure file_path parameters. Add validation: 'file_path must be a filename under ~/.tasktracker/ directory (e.g., export.json). Paths containing .. or / are rejected to prevent directory traversal.' Implement this check in the tool handler.
Add batch variants for efficiency. Create add_tasks (array of task objects) and delete_tasks (array of task IDs) to enable agents to compose multiple changes in one call instead of N sequential calls, reducing latency and token waste.
Document tool dependencies in descriptions. E.g., update_task's task_id parameter should note: 'Use get_all_tasks_tool to list available task IDs if you don't know the ID.' This guides multi-step planning and prevents discovery loops.