GTD Brain

move_card

Idempotent

Use this when the user wants a card in a different column — clarifying an Inbox item into Next Actions, Projects, Waiting For, Someday/Maybe, or Reference (worth keeping, no action), or into one of their own columns (a Done or Completed column, say) — or reordered within its column. 'Move it to done' means move_card into the user's column with that label (find it with list_columns), never archive_card. The card's kind follows the destination (Next Actions → action, Projects → project, normal columns → note, flexible columns keep it). Set the card's context, project, or who/since in the same call: clarifying or re-filing a card is one move_card on that card, never a new card plus archive_card on the old one. Do not use to only edit a card's text or tags — use update_card. Rejected for an archived card — use restore_card. Returns the moved card.

Input Schema

TableJSON Schema

Name	Required	Description
`who`	No	Optional, for Waiting For: who it is delegated to, e.g. 'Sam'.
`since`	No	Optional, for Waiting For: since when, e.g. '2026-09-01'.
`cardId`	Yes	The card id to move.
`context`	No	Optional context id to set as it moves, e.g. 'calls', or an empty string to clear it. GTD context id (e.g. calls, computer, errands, home). The user manages their own set — list_contexts shows it, create_context adds one; if unknown, the error lists the valid ids so you can retry.
`toIndex`	No	Optional 0-based position within the destination column, e.g. 0 for the top. Defaults to the end.
`projectId`	No	Optional project card id (from list_projects) when it lands in Next Actions as that project's next step; an empty string unlinks it.
`toColumnId`	Yes	Destination column id, from list_columns.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 28, 2026

addedInput schema / properties / context

Added value: +{
+  "description": "Optional context id to set as it moves, e.g. 'calls', or an empty string to clear it. GTD context id (e.g. calls, computer, errands, home). The user manages their own set — list_contexts shows it, create_context adds one; if unknown, the error lists the valid ids so you can retry.",
+  "type": "string"
+}

addedInput schema / properties / projectId

Added value: +{
+  "description": "Optional project card id (from list_projects) when it lands in Next Actions as that project's next step; an empty string unlinks it.",
+  "type": "string"
+}

addedInput schema / properties / since

Added value: +{
+  "description": "Optional, for Waiting For: since when, e.g. '2026-09-01'.",
+  "type": "string"
+}

addedInput schema / properties / who

Added value: +{
+  "description": "Optional, for Waiting For: who it is delegated to, e.g. 'Sam'.",
+  "type": "string"
+}

Changed2 schema fields changedSep 15, 2026

changedInput schema / properties / toColumnId / description

Previous value: -"The destination column id."New value: +"Destination column id, from list_columns."

changedInput schema / properties / toIndex / description

Previous value: -"Optional 0-based position within the destination column. Defaults to the end."New value: +"Optional 0-based position within the destination column, e.g. 0 for the top. Defaults to the end."

First observedSep 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare non-readonly, non-destructive, idempotent, so the safety bar is met; the description goes well beyond by disclosing the side effect that the card's kind follows the destination (Next Actions → action, Projects → project, etc.), the archived-card rejection, and that re-filing is one move rather than create+archive.

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?

Front-loads the core action and the key routing rule ('move it to done' → move_card), but the dense em-dash-embedded clauses make it long and slightly hard to scan. Every sentence carries information, so nothing is truly wasted.

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?

No output schema exists, so 'Returns the moved card' is a valuable addition, and the description covers error handling (archived rejection), kind side effects, the correct alternative tools, and how optional clarifying fields combine. Complete for a 7-param mutation tool.

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 baseline is 3. The description adds cross-parameter semantics the schema does not: context/project/who/since should be set in the same call, and who/since apply specifically when landing in Waiting For. It does not explain toIndex or the empty-string clearing behavior, so it isn't a full 5.

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 (moving a card between columns) and immediately distinguishes it from siblings: 'Do not use to only edit a card's text or tags — use update_card', 'never archive_card', 'use restore_card'. An agent can select it correctly 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 when-to-use (clarifying Inbox, reordering, moving to a Done-style column) and when-not (text/tag edits → update_card; archived → restore_card). It even decodes the ambiguous natural-language phrase 'move it to done' and routes it to the right column lookup via list_columns.

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

All GTD Brain tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?