Nodiom Cloud

Move a card

board_move_card

Idempotent

Moves a card to another column in one atomic step — it never exists twice or not at all, even while other agents are writing. Move a card when you pick it up, as you work it, and when it's finished. Moving to the last column ticks it done. If the board has a review column, tick the criteria you met (board_update_card), then move finished work there and stop: only a person, or a key the owner allowed to review, can approve it into the last column or send it back, and moves that would skip review are refused. When you pick up a card that was sent back, the reply includes what the reviewer said.

Input Schema

Name	Required	Description
`to`	Yes	The destination column's name, exactly as board_read shows it.
`note`	No	Only when a reviewer key approves or sends back a card: what to tell the agent. Written into the card as a review note.
`agent`	No	Who is moving it. Defaults to this API key's name.
`doc_id`	Yes	The board's document id, as returned by board_create or nodiom_list_docs.
`card_id`	Yes	The card's id, e.g. c_7f3a. See board_read.

Output Schema

Name	Required	Description
`to`	Yes
`tip`	No
`from`	Yes
`next`	No	What to do now, e.g. stop and wait for review.
`card_id`	Yes
`reviewer_said`	No	The note on a card that was sent back to you.
`criteria_unticked`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "card_id": {
+      "type": "string"
+    },
+    "criteria_unticked": {
+      "type": "integer"
+    },
+    "from": {
+      "type": "string"
+    },
+    "next": {
+      "description": "What to do now, e.g. stop and wait for review.",
+      "type": "string"
+    },
+    "reviewer_said": {
+      "additionalProperties": false,
+      "description": "The note on a card that was sent back to you.",
+      "properties": {
+        "at": {
+          "description": "When, as an ISO time.",
+          "type": "string"
+        },
+        "by": {
+          "description": "Who decided, or who replied.",
+          "type": "string"
+        },
+        "decision": {
+          "description": "A person's decision, or an agent's reply to one.",
+          "enum": [
+            "approved",
+            "sent_back",
+            "reply"
+          ],
+          "type": "string"
+        },
+        "text": {
+          "description": "What they said; may be empty.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "decision",
+        "text"
+      ],
+      "type": "object"
+    },
+    "tip": {
+      "type": "string"
+    },
+    "to": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "card_id",
+    "from",
+    "to"
+  ],
+  "type": "object"
+}

First observedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, idempotent=true, destructive=false), while the description adds atomicity guarantees ('never exists twice or not at all, even while other agents are writing'), the review-gate permission model, refusal of review-skipping moves, and the reviewer-note-on-return behavior. That is substantial behavioral context beyond the structured fields.

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 atomicity guarantee and routing triggers before the review-workflow detail, and every sentence carries workflow or constraint information. The pickup/work/finish cadence is slightly repetitive but not wasted for a multi-state tool.

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?

A stateful mutation tool with a review gate is fully covered: entry conditions, refusal cases, the alternative for criteria updates, and what comes back when picking up a sent-back card. An output schema exists, so return values need no further explanation.

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

Parameters3/5

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

Schema coverage is 100%, so all five parameters, including `to`, `note`, and `agent`, are already fully documented in the schema. The description reinforces the reviewer-only use of `note` but adds no format or syntax detail beyond it, so the baseline of 3 is correct.

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 and resource with scope: 'Moves a card to another column in one atomic step.' This distinguishes it cleanly from siblings like board_update_card (which ticks criteria) and board_add_card, so an agent can route 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?

Gives explicit when-to-use triggers ('when you pick it up, as you work it, and when it's finished'), names the alternative for criteria ('board_update_card'), and states the stop condition at a review column plus which moves are refused. Nothing is left to inference.

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

All Nodiom Cloud 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.