🪲 Bugs
Open

MCP API — Task Context is silently read-only, can't link Task to Project

Problem

Context is editable in the UI (Object Types → Task → Properties → Context, relation, under Priority) but not through the API. getObjectTypeShape("Task") returns 7 writable properties — title, tags, status, date, deadline, priority, icon — plus "1 read-only property definition(s) omitted". That omitted one is Context.

Sending context in frontmatter via updateObjectViaMD or createObjectViaMD returns success, does not change lastUpdated, and the property stays empty on read. No error, no warning — the value is silently discarded.

Steps to reproduce

Create a Task via API.

updateObjectViaMD with context: "[[Some Project]]" in frontmatter → success response.

getObjectContent on the same task → Context empty, lastUpdated unchanged.

Set the same value in the UI → saves correctly.

Expected

Context writable through the API/MCP, so an AI agent can assign a Task to its Project at creation time. If it is intentionally a reverse relation, return an explicit error instead of discarding the write silently.

Why it matters

Context is the only link between a Task and its parent Project. Without API write access every programmatically created task lands orphaned and needs a manual UI step to be filed — which is precisely the work the API should remove.

Environment

Capacities API via MCP (api.capacities.io/mcp), web app. Reproduced repeatedly on multiple tasks.

3 Comments

Sign in to comment

A✨
Aglaé ✨·19 days ago

This would be super powerful!

DB
Denn Bo·2 months ago

I can also confirm this behaivor.

L
Lukas·2 months ago

Can confirm — hit the same issue today creating a batch of ~30 tasks via MCP for a client project. All tasks were created successfully with tags and deadlines, but none showed up under the Project's Tasks tab since Context stayed empty. Had to go back and set it manually on each one in the UI, which defeats the purpose of batch-creating via API in the first place.

The silent-fail part is the more concerning bit for me: no error on write, no change to lastUpdated, so there's no signal at the API level that something didn't take. Would strongly support either making Context writable, or at minimum surfacing a clear error so this doesn't fail silently.