Nodiom Cloud

Edit a card

board_update_card

DestructiveIdempotent

Changes a card's title, brief or acceptance criteria in place. It keeps its id, column, owner and review notes. Give only the parts to change; criteria replace the whole list, so send every criterion you want kept, ticking the ones that are met. On a board with a review step, cards waiting for review or already approved can't be edited.

Input Schema

Name	Required	Description
`agent`	No	Who is editing it. Defaults to this API key's name.
`brief`	No	A new brief. An empty string removes it.
`title`	No	A new one-line title.
`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.
`criteria`	No	The full list of acceptance criteria: plain strings, or { text, done } to tick one.

Output Schema

Name	Required	Description	Default
`column`	Yes
`card_id`	Yes
`updated`	Yes

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"
+    },
+    "column": {
+      "type": "string"
+    },
+    "updated": {
+      "const": true,
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "card_id",
+    "column",
+    "updated"
+  ],
+  "type": "object"
+}

First observedOct 18, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true): it discloses what is preserved (id, column, owner, review notes), what the destructive behavior actually means (criteria replace the entire list, so omitted criteria are dropped), and a state precondition tied to the review workflow. That is exactly the kind of context structured hints cannot convey.

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

Conciseness5/5

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

Three sentences, all load-bearing: what it does, how to send partial updates and the list-replacement rule, then the review-state exclusion. Front-loaded with the core action and free of filler.

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?

For a partial-update mutation with 6 params and an output schema (so return values need no explanation), the description covers scope, preservation semantics, list-replacement behavior, and the blocking precondition. Nothing material is missing for correct invocation.

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, and the description earns an extra point by clarifying the non-obvious replacement semantics of the criteria array ('send every criterion you want kept, ticking the ones that are met') — a behavior the schema cannot express despite its detailed field descriptions.

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 ('changes') plus resource ('a card') and enumerates exactly which fields are editable (title, brief, acceptance criteria). The phrase 'in place' and the field list separate it from board_move_card, board_add_card, and board_delete_card without needing to open 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 Guidelines4/5

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

Gives an explicit when-not condition ('on a board with a review step, cards waiting for review or already approved can't be edited') and partial-update guidance ('give only the parts to change'). It never names a sibling alternative for a given intent, so it stops short of a 5.

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

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.