This GTD MCP server has 2 tools with significant definition gaps. Both tools have input schemas present but descriptions lack context about when to use them vs alternatives. The naming is action-verb compliant (handle_change_status, handle_empty_trash), but descriptions are brief (under 100 chars) and missing critical details about prerequisites, side effects, and error recovery. No parameter descriptions visible for handle_change_status's 'new_status' enum values, the description lists valid statuses but does not explain what each status means or when to transition to it. The empty_trash tool is a destructive operation with no confirmation pattern, dry-run option, or recovery guidance. Output schemas are not documented. Error handling guidance is absent, an LLM calling these tools has no recovery path if a transition fails or if the trash is already empty.
Tools (2)
handle_change_statuswritesource verified53/100
Changes status for multiple items - validates status and updates nota_map.
handle_change_status description is too brief and lacks guidance on status semantics. 'Changes status for multiple items - validates status and updates nota_map.' (79 chars) does not explain when each status (inbox, next_action, waiting_for, later, calendar, someday, done, reference, trash, project, context) should be used, what prerequisites exist (e.g., calendar status requires start_date), or what happens to dependent items when a task moves to done or trash.
handle_change_status lacks parameter descriptions for enum values. The 'new_status' parameter lists 10 valid values but provides no description of what each status means or when an LLM should choose it. An LLM cannot reason about status transitions without understanding GTD semantics (e.g., what distinguishes 'next_action' from 'later'?). This violates the pattern requirement that every parameter must have a non-empty, actionable description.
handle_change_status
CRITICAL
Recommendations
Expand handle_change_status description to 150-250 chars. Include: 'Transitions one or more items to a new status in the GTD workflow. Supports status values: inbox (new), next_action (ready), waiting_for (blocked), later (planned), calendar (scheduled), someday (deferred), done (completed), reference (archived), trash (deleted), project (goal), context (category). For calendar status, start_date is required; other statuses treat it as optional. Returns per-item status, affected count, and any validation errors. Idempotent: retrying with same IDs/status succeeds.'
Add per-status guidance in parameter description for 'new_status': 'Target status. inbox: newly captured items. next_action: ready to do now. waiting_for: blocked on external input. later: not ready yet. calendar: scheduled for specific date (requires start_date). someday: future possibility. done: completed. reference: no longer active. trash: marked for deletion. project: multi-step goal. context: tagging category.'
Document handle_change_status output schema: 'Returns { success: bool, changed_count: int, failed_ids?: string[], errors?: { id: string, reason: string }[] }. If any item fails, the response includes failed_ids and per-item error reasons. LLMs should inspect failed_ids to decide whether to retry with valid IDs or ask the user.'
Add error recovery guidance to handle_change_status: 'If validation fails (e.g., invalid status), returns error with the invalid value. If item does not exist, includes it in failed_ids. If start_date is required for calendar but omitted, returns error asking LLM to retry with start_date. All errors are retryable.'
handle_empty_trash is a destructive operation with no confirmation pattern, dry-run support, or recovery guidance. Calling this tool irreversibly deletes all trash items. The description does not warn of this consequence, offer a preview of what will be deleted, or guide the LLM on how to undo the action. An agent making a mistake has no recourse.
No output schemas documented for either tool. The descriptions do not specify what fields the tools return, what structure the response has, or what the LLM can extract for downstream calls. This violates the pattern that all tools must document their return types so agents can plan chained calls.
Error handling is absent. Neither tool description explains what errors might occur (e.g., invalid status, non-existent item ID), how to recover, or what the LLM should do next. A tool that fails with a generic error message leaves the agent stuck.
handle_change_status parameter 'start_date' is documented as 'Optional start date in YYYY-MM-DD format, required for calendar status' but no validation guidance is provided. What happens if an LLM omits start_date when setting status to calendar? Does the tool accept it and set a default, or fail? The description must explicitly state the behavior.
handle_change_status uses array of 'ids' with type string but no description of what constitutes a valid ID format, expected length, character restrictions, or examples. An LLM cannot reliably generate valid IDs without format guidance.
handle_change_status
Replace handle_empty_trash with a two-step pattern: (1) list_trash_preview tool to show what will be deleted (returns count and sample items). (2) confirm_empty_trash tool that requires an explicit 'confirm: true' parameter. Document: 'Permanently deletes all items with status=trash. Call list_trash_preview first to review count and sample items. Then call confirm_empty_trash with confirm=true. This is irreversible, no undo available.'
Add ID format guidance to handle_change_status 'ids' parameter: 'Array of item IDs to transition. Each ID is a string of 1-256 characters, alphanumeric plus underscore/hyphen. Example: ["task_001", "review_q4_planning"]. Invalid IDs are returned in failed_ids; valid IDs are processed.'
Add per-item result detail to handle_change_status output: 'Returns per-item confirmation: { id: string, old_status: string, new_status: string, updated_at: ISO8601 }. This lets the LLM confirm the transition and extract updated_at for downstream logging or ordering.'
Document idempotency: 'Both tools are idempotent. Calling handle_change_status twice with the same IDs and status is safe, the second call succeeds with changed_count=0. Calling handle_empty_trash twice is safe if the trash was already empty; the second call returns success with deleted_count=0.'
Add scope annotation to handle_empty_trash: 'This tool requires write:trash permission. It is a destructive operation. Agents should confirm user intent before calling. After execution, provide feedback: "Permanently deleted N items from trash. This cannot be undone."'