Lightbringer

Update innovation in Lightbringer

update_innovation

DestructiveIdempotent

Updates one or more sections of an existing innovation record with new content and reports, per section, whether it was applied. Overwrites the specified sections. Text the agent leaves as read keeps its comment threads and pending changes; an applied section also lists any markdown it could not store (dropped), any comment threads whose text the write removed (detached_threads), and whether the write was too large to keep every comment anchor on the edited paragraphs (marks_incomplete); smaller writes keep them.

Input Schema

Name	Required	Description	Default
`sections`	Yes	Named invention sections and their full replacement text
`invention_id`	Yes	The innovation identifier (invention_id)

Output Schema

Name	Required	Description	Default
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedOutput schema / properties / results / additionalProperties / properties / marks_incomplete / description

Previous value: -"The write was too large to match every edited paragraph to its stored one, so some were stored as new, without their comment anchors and pending changes; the threads on those are listed as detached. Smaller writes keep them."New value: +"The write was too large to match every edited paragraph to its stored one, so some were matched only roughly: their pending changes stay, but comment anchors on the edited text may have come off; those threads are listed as detached. Smaller writes keep them."

Changed3 schema fields changedOct 29, 2026

addedOutput schema / properties / results / additionalProperties / properties / detached_threads

Added value: +{
+  "description": "Comment threads whose anchored text this write removed. They still exist but no longer point at any text; re-anchor or resolve them in the app.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "quote": {
+        "description": "The text the thread was anchored on before this write",
+        "type": "string"
+      },
+      "thread_id": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "thread_id",
+      "quote"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / results / additionalProperties / properties / dropped

Added value: +{
+  "description": "Markdown the write could not store. Empty when everything was kept.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "description": "What was dropped: image, footnote, horizontalRule or unsupported",
+        "type": "string"
+      },
+      "text": {
+        "description": "The markdown as written, shortened when long",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "text"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / results / additionalProperties / properties / marks_incomplete

Added value: +{
+  "const": true,
+  "description": "The write was too large to match every edited paragraph to its stored one, so some were stored as new, without their comment anchors and pending changes; the threads on those are listed as detached. Smaller writes keep them.",
+  "type": "boolean"
+}

AddedSep 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the bar is lower, yet the description still adds substantial behavior: omitted sections are preserved with their comment threads and pending changes, specified sections are overwritten, and each applied section reports dropped markdown, detached_threads, and marks_incomplete. The "smaller writes keep them" note explains when anchors survive the write, which an agent cannot get from the annotations.

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-loaded with the core action and result shape, and no sentence is filler. The second sentence is a long parallel clause carrying several distinct behaviors at once, which is efficient but denser than ideal; it could be split for faster scanning.

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?

This is a destructive mutation on a nested-section object, and the description covers overwrite scope, omission behavior, and the per-section outcome fields, while an output schema exists so full return-value explanation is unnecessary. Remaining gaps are minor: nothing about what happens if invention_id does not exist, and the return-field naming is stated slightly redundantly against the output schema.

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% and each section field already documents full-replacement and empty-string-clears semantics, so the baseline is 3. The description adds genuinely new meaning beyond the schema: partial update via omission preserves existing text and comment state, which is not stated anywhere in the nested object schema.

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?

"Updates one or more sections of an existing innovation record with new content and reports, per section, whether it was applied" gives a specific verb (updates), a specific resource (innovation record sections), and a scope (partial, per-section). The resource name plus per-section reporting separates it from read siblings like get_innovation and from update_asset/update_company_context without needing to name them.

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

Usage Guidelines3/5

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

No explicit when-to-use/when-not-to-use or alternative tool is named. The clause "Text the agent leaves as read keeps its comment threads and pending changes" implicitly tells the agent to omit sections it does not want to change, which is real usage guidance, but it must be inferred rather than stated as a rule, and nothing says when to prefer update_innovation vs. register_innovation or edit_strategy.

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

All Lightbringer tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.