amazing-marvin-complete-mcp

mark_done

Idempotent

Instructions

Mark a task as done and clean up its reminders as the app does. Reads the task, runs /markDone (configured timezone) and then does what the app does: the server entries T and M are removed and reminderTime is cleared; the reminders list remains. Projects: /markDone responds 400 (tasks only); projects are closed with mark_project_done. 404 = does not exist, 400 = already done or a project. Habit task (field habitId): the habit is also recorded with /updateHabit at 12:00 on the task's day, and habitRepAt is set. Habit with a count (recordType number): value is recorded with the current time; the task is checked off only once the day's total reaches the target — otherwise it stays open and the response shows the total. Recurring occurrence: safe (deterministic id). After completion: the next occurrence is created +N days later. With a future day the tool does what the app does: the occurrence is moved to today before it is checked off, and the next one is counted from today. If a step fails the response says which steps were done. Running time tracking is stopped and written to task.times. /markDone does not set workedOnAt and does not stamp fieldUpdates, which the app does.

Input Schema

Name	Required	Description	Default
`value`	No	Habit task with a count only: the value to record (default 1)
`item_id`	Yes	Task ID (NOT a project — mark_project_done closes those)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.7.3Oct 13, 2026

changedInput schema / properties / item_id / description

Previous value: -"Task ID (NOT a project — see description)"New value: +"Task ID (NOT a project — mark_project_done closes those)"

addedInput schema / properties / value

Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Habit task with a count only: the value to record (default 1)"
+}

First observedv1.3.0Aug 29, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations present the bar is lower, yet the description goes well beyond them: it enumerates exactly what is removed (server entries T and M, reminderTime cleared, reminders list kept), how habits are recorded, how recurring occurrences shift, that running time tracking is stopped and written to task.times, and the notable gaps (/markDone does not set workedOnAt or stamp fieldUpdates). That is unusually rich side-effect disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The paragraph is long and dense, but nearly every sentence carries behavioral information rather than filler, and the core action is front-loaded ahead of the edge cases. A tighter grouping of the habit/recurring/future-day branches would read better than the current run-on flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, yet the description still tells the agent that partial failures report which steps succeeded. Combined with the edge-case coverage for habits, recurring tasks, and future days, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics for `value`: it defines the habit-with-count case, that the value is recorded with the current time, and that the task only closes once the day's total reaches the target. `item_id`'s task-not-project constraint is reinforced in prose as well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Mark a task as done') and immediately scopes it by naming the sibling it is not: 'tasks only ... projects are closed with mark_project_done'. An agent can distinguish this from mark_project_done, unmark_done, and record_habit without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules: projects get a 400 here and must use mark_project_done; 404 vs 400 are decoded; habit and recurring cases are given their own conditions. This is genuine when/when-not guidance, not inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server