lightbulb-mcp

Overview Schema Source Related Servers Discussions Admin

monday_get_board

Read-onlyIdempotent

Retrieve a Monday.com board from your project's governed connector account. This read-only action returns board data within the approved Lightbulb MCP platform.

Instructions

Monday connector operation get_board (platform tool monday.get_board).

Routes only through the exact project/account governed connector authority.

Args: arguments: JSON string of arguments for the connector operation. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Required and must be read; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema

Name	Required	Default
`effect`	Yes
`arguments`	No	{}
`project_id`	No
`project_ref`	No
`approval_ref`	No
`idempotency_key`	No
`connector_account_ref`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.1Sep 7, 2026

addedInput schema / properties / approval_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}

addedInput schema / properties / connector_account_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}

addedInput schema / properties / effect

Added value: +{
+  "const": "read",
+  "title": "Effect",
+  "type": "string"
+}

addedInput schema / properties / idempotency_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}

addedInput schema / properties / project_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}

addedInput schema / properties / project_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}

addedInput schema / required
```
Added value: +[
+  "effect"
+]
```

First observedv0.1.0Jun 25, 2026

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the burden on the description. The description adds some value by disclosing the governed-authority routing constraint and that 'effect' must be 'read' and is Spring-verified; the approval_ref note about 'resuming a write' is generic platform boilerplate and does not contradict the read-only annotation.

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?

The description is compact and well-structured: a one-line operation identifier, a one-line routing constraint, and a bulleted parameter list. For a 7-parameter tool with 0% schema coverage, the per-parameter glosses earn their place and the layout is scannable.

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

Completeness3/5

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

The presence of an output schema and strong read-only/idempotent annotations lightens the burden considerably. The main gap is domain semantics: there is no guidance on how to target a specific board (presumably via the arguments JSON), no error behavior, and no distinction from list_boards — leaving an agent to guess the actual call payload.

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?

With 0% schema description coverage, the description must compensate, and it does list all 7 parameters with one-line glosses (e.g., project_id is an 'Authenticated Project UUID', arguments is a 'JSON string'). However, the glosses are generic envelope boilerplate — the domain-critical argument payload (which board to fetch) is left opaque inside the 'arguments' JSON string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description's core clause — 'Monday connector operation `get_board` (platform tool `monday.get_board`)' — simply restates the tool name with a platform qualifier; it never states what getting a board does or returns. It does not differentiate from siblings like monday_list_boards or monday_query_data, so an agent cannot tell why it would pick this over a sibling without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The only guidance is 'Routes only through the exact project/account governed connector authority,' which is a routing/governance constraint, not a when-to-use directive. No alternatives, exclusions, or selection conditions are given relative to the many monday_* siblings.

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

Deploy Server