Nodiom Cloud

Create a board

board_create

Creates a board: a shared Markdown document whose columns are ## headings and whose cards are checklist items. Returns its doc_id. Columns default to Backlog, In Progress, Needs Review, Done. For work handed from one agent to another, use Received, Doing, Done. The last column is where finished work goes; review_column is where a person signs off before it does.

Input Schema

Name	Required	Description
`title`	Yes	The board's name. Its doc_id is derived from it.
`columns`	No	Column names, in order.
`review_column`	No	The column where a person approves work before it moves to the last column: any column but the first and the last. null for no review step. Left out, a column whose name mentions review or approval is used if there is one.

Output Schema

Name	Required	Description
`doc_id`	Yes	The document id.
`columns`	Yes
`review_column`	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": {
+    "columns": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "doc_id": {
+      "description": "The document id.",
+      "type": "string"
+    },
+    "review_column": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "doc_id",
+    "columns",
+    "review_column"
+  ],
+  "type": "object"
+}

First observedOct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare the write/idempotency/destructive profile, so the bar is lower. The description adds real behavioral context beyond them: the return value (doc_id), the default column set when columns is omitted, and the ordering semantics of the last column and review_column.

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?

Four sentences, no filler, and the definition of the artifact is front-loaded before the defaults and column semantics. Slightly dense but every sentence carries information an agent needs.

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?

An output schema exists, so return-value detail is not required, yet the doc_id mention ties the artifact to it. Combined with defaults, handoff conventions, and review-column semantics, the description is complete for a 3-parameter creation tool with full schema coverage.

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 meaning the schema does not: the concrete default column names, the agent-handoff convention, and the semantic role of the last column versus review_column, which clarifies intent beyond the schema's structural rules.

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?

The description gives a specific verb and resource ('Creates a board') and then defines what a board actually is ('a shared Markdown document whose columns are ## headings and whose cards are checklist items'), which lets an agent distinguish it conceptually from nodiom_create_doc among the siblings. It also states the returned handle (doc_id).

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?

It gives concrete usage context: default columns, and a named alternative column set ('Received, Doing, Done') for work handed between agents. It does not explicitly state when NOT to use this tool or name which sibling handles a similar need, so it stops short of full routing 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

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.