Nodiom Cloud

Read a board

board_read

Read-onlyIdempotent

Returns a board's columns and cards as JSON, including each card's id, owner and acceptance criteria. Read the board before you pick up, add or move work. Cards are addressed by id, never by position. A card a person has approved or sent back carries review_notes, oldest first: when a card comes back to you, its last note says what to change.

Input Schema

Name	Required	Description	Default
`doc_id`	Yes	The board's document id, as returned by board_create or nodiom_list_docs.

Output Schema

Name	Required	Description
`title`	Yes
`columns`	Yes
`problems`	No	Things wrong with the document a person should know about.

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": {
+    "columns": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "a_person_approves_from_here": {
+            "type": "boolean"
+          },
+          "cards": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "brief": {
+                  "type": "string"
+                },
+                "criteria": {
+                  "description": "Acceptance criteria.",
+                  "items": {
+                    "additionalProperties": false,
+                    "properties": {
+                      "done": {
+                        "type": "boolean"
+                      },
+                      "text": {
+                        "type": "string"
+                      }
+                    },
+                    "required": [
+                      "text",
+                      "done"
+                    ],
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "done": {
+                  "description": "Ticked: true in the last column.",
+                  "type": "boolean"
+                },
+                "id": {
+                  "description": "The card's permanent id, e.g. c_7f3a.",
+                  "type": "string"
+                },
+                "owner": {
+                  "description": "Who last moved it.",
+                  "type": "string"
+                },
+                "review_notes": {
+                  "description": "Review decisions and replies, oldest first.",
+                  "items": {
+                    "additionalProperties": false,
+                    "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"
+                  },
+                  "type": "array"
+                },
+                "title": {
+                  "type": "string"
+                },
+                "updated": {
+                  "description": "When it last changed, as an ISO time.",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "id",
+                "title",
+                "done"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "finished_work_goes_here": {
+            "type": "boolean"
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "cards"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "problems": {
+      "description": "Things wrong with the document a person should know about.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "columns"
+  ],
+  "type": "object"
+}

First observedOct 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint false). The description adds genuinely new behavioral facts: cards are addressed by id and never by position, and review_notes are returned oldest first with the last note carrying the required change when a card comes back. It does not mention behavior on a missing or malformed doc_id.

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?

Three sentences, front-loaded with the return shape, then the usage condition, then the review_notes detail. Every sentence carries information, though the review_notes sentence is somewhat dense and could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be re-explained, and the annotations carry the safety profile; the description fills in the remaining gaps an agent needs (when to read, how cards are identified in subsequent calls, how review feedback surfaces). Only error/empty-board behavior is unaddressed.

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 description coverage is 100% for the single doc_id parameter, and the schema already says where the id comes from ('as returned by board_create or nodiom_list_docs'). The description adds nothing about the parameter itself; the 'addressed by id' statement concerns cards inside the document, not the input. Baseline 3 with the schema doing the work.

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 ('Returns a board's columns and cards as JSON') and enumerates what comes back (card id, owner, acceptance criteria). The routing advice about reading before picking up, adding or moving work also separates it in practice from sibling writers like board_add_card and board_move_card.

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?

'Read the board before you pick up, add or move work' gives a concrete trigger tied to the sibling write tools, so an agent knows when to reach for this rather than one of them. It stops short of naming alternatives explicitly (e.g., board_wait for blocking, board_reply for responding), so no true when-not-to-use guidance.

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.