`update_todo` silently reports success on project/heading IDs; no way to move a project between areas

[willhains]

Environment: things-mcp v0.8.1 (FastMCP 3.x, things.py 0.0.15) · macOS · Things 3 · driven via MCP.

Summary

A small family of related issues where the MCP reports success but the underlying Things operation either doesn't happen or isn't possible, with nothing relayed back to the caller:

1. update_todo on a project ID — reports success, changes nothing.
2. update_todo on a heading ID — same.
3. No way to move a project between areas at all.

In cases 1 and 2 the MCP returns Updated, but Things pops a "Cannot update … because it does not exist" dialog and nothing changes. That failure isn't relayed through the MCP, so from the API side the call looks like it worked.

1. update_todo on a project ID

Passing a project UUID to update_todo returns Updated, but the edit silently no-ops (Things shows "… does not exist").

• Reproduced on v0.8.1: editing a project's notes via update_todo returned Updated, yet the notes were unchanged. The same edit via update_project worked.
• Workaround: use update_project for all project-level edits.

2. update_todo on a heading ID

Same pattern when the UUID belongs to a heading: update_todo reports success, Things can't find a to-do with that ID, and the failure is swallowed.

• Related: headings appear to have no API path to completion or deletion at all — those remain manual steps in Things.

3. No way to move a project between areas

update_project (v0.8.1) exposes no area / area_id parameter, so a project's area can't be changed through the MCP.

• For contrast, moving a to-do between projects or areas works reliably via update_todo's list_id (and bulk_update_todos' list / list_id). The gap is specific to project → area moves.

Suggested fixes

• Validate the target type up-front: if a UUID passed to update_todo resolves to a project or a heading, either route it to the right operation or return a clear error — rather than reporting success.
• Where Things raises its own "does not exist" error, relay that back through the MCP instead of swallowing it.
• Add an area / area_id parameter to update_project; or, if upstream doesn't support it, document that project → area moves aren't possible via the MCP.

Not in scope

The slash-in-a-string-parameter case (#47) and the ampersand-in-an-area-name case are already fixed in v0.8.0 / v0.8.1, so they aren't part of this report.