killbottleneck-mcp

Official

Overview Schema Source Related Servers Discussions Admin

update_node

Update a killBottleneck node’s title, status, deadline, owner, planned work date, executor, and automation wish; marking it done can unblock dependent nodes and notify owners.

Instructions

Update fields of one node: title, status (todo/in_progress/done), description, deadline (YYYY-MM-DD, empty string clears), planned_on (YYYY-MM-DD, today to +7 days, empty string clears — WHEN the key owner plans to work on it; this is how killBottleneck expresses priority, never by moving the deadline), owner (e-mail, empty string clears), wait_for_children, colour, icon (one emoji), who performs it (executor_kind / executor_name) and the automation wish (automation_wanted / automation_note). Unknown fields are rejected with the list of allowed ones. Marking status done may unblock waiting nodes, notify their owners and trigger automations on them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "map_id": "<map_id>",
      "node_id": "<node_id>"
    },
    "name": "update_node"
  }
}

Input Schema

Name	Required	Description
`icon`	No	One emoji shown in front of the step; empty string clears.
`color`	No	Node colour as #rrggbb, empty string clears
`owner`	No	Accountable PERSON (e-mail of an instance member, see list_people). Stays a human even for AI/cron steps — this is who gets notified. Empty string clears. Unknown e-mails are rejected.
`title`	No
`map_id`	Yes
`status`	No
`node_id`	Yes
`deadline`	No
`planned_on`	No	YYYY-MM-DD, today to +7 days, empty string clears. WHEN the key owner plans to work on it — this is how killBottleneck expresses priority; never move the deadline to express priority.
`description`	No
`executor_kind`	No	Who performs the step. Default "human".
`executor_name`	No	Which automation handles this step, e.g. "n8n backup" — a record of what exists, not an instruction. Empty string clears.
`automation_note`	No	Optional context for the automation wish. Empty string clears.
`automation_wanted`	No	Wish that this step were automated; notifies the AI agent managers.
`wait_for_children`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.1Nov 9, 2026

addedInput schema / properties / icon

Added value: +{
+  "description": "One emoji shown in front of the step; empty string clears.",
+  "type": "string"
+}

changedInput schema / properties / owner / description

Previous value: -"Accountable PERSON (e-mail). Stays a human even for AI/cron steps — this is who gets notified. Empty string clears."New value: +"Accountable PERSON (e-mail of an instance member, see list_people). Stays a human even for AI/cron steps — this is who gets notified. Empty string clears. Unknown e-mails are rejected."

addedInput schema / properties / planned_on

Added value: +{
+  "description": "YYYY-MM-DD, today to +7 days, empty string clears. WHEN the key owner plans to work on it — this is how killBottleneck expresses priority; never move the deadline to express priority.",
+  "type": "string"
+}

First observedv0.33.2-betaAug 17, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that unknown fields are rejected with the allowed list and that marking status done may unblock waiting nodes, notify owners, and trigger automations, but it omits permissions, idempotency, and what the update response contains.

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 front-loaded with the operation and its fields, and every sentence contributes useful detail. It is dense but not wasteful; the parenthetical field explanations earn their space.

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?

For a 15-parameter mutation tool with no annotations and no output schema, the description covers most essential behavior: field formats, clearing semantics, validation of unknown fields, and side effects of status changes. Remaining gaps are permissions and return behavior, which are notable but not fatal.

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 53%, so the description must add meaningful parameter context. It does so especially for planned_on (priority expression and never moving the deadline), owner (accountable human even for AI/cron steps), executor_name (record rather than instruction), and clearing behavior via empty strings.

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

Purpose4/5

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

The description states a specific verb and resource: 'Update fields of one node,' then enumerates the updatable fields. It clearly identifies the operation, though it does not explicitly distinguish this tool from sibling update tools such as update_event or update_map.

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 description explains field semantics and side effects but gives no explicit guidance on when to choose update_node versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the phrase 'Update fields of one node.'

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