killbottleneck-mcp

Official

Overview Schema Source Related Servers Discussions Admin

add_nodes

Adds a subtree of goal or task nodes under an existing map parent (or apex) to create new work items, then returns the updated map tree.

Instructions

Add a subtree of nodes to an existing map under parent_id (or under the apex when parent_id is omitted). A node is a goal; a node with an assignee (owner) OR a deadline IS a task — that is the only kind of task in killBottleneck (there is no separate task record; new work = new node). NOTE: this re-computes the layout of the whole map. Max 200 nodes per call. Returns the updated tree.

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>",
      "items": "<items>"
    },
    "name": "add_nodes"
  }
}

Input Schema

Name	Required	Description
`items`	Yes
`map_id`	Yes
`parent_id`	No	Existing node id to attach under; omit for apex

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.1Nov 9, 2026

addedInput schema / properties / items / items / properties / icon

Added value: +{
+  "description": "One emoji shown in front of the step (optional).",
+  "type": "string"
+}

changedInput schema / properties / items / items / properties / owner / description

Previous value: -"Accountable PERSON: e-mail of an instance member. Stays a human even when the step is performed by an automation — this is who gets notified."New value: +"Accountable PERSON: e-mail of an instance member (see list_people). Stays a human even when the step is performed by an automation — this is who gets notified. Unknown e-mails are rejected."

addedInput schema / properties / items / items / 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

A4.1/5.0

Behavior4/5

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

With no annotations supplied, the description carries the burden and does well: it warns that the whole map layout is re-computed (a non-obvious side effect), caps batch size at 200, and states the return value is the updated tree. It leaves out permission requirements and what happens if the batch fails partway.

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 action and placement rule, then the domain model, then the operational note. Every sentence is relevant, though the emphatic capitalized phrasing and mid-sentence domain aside make it slightly denser than needed.

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 3-parameter batch-create tool with no output schema, the description covers placement semantics, the goal/task model, batch limits, and the side effect on layout. Error handling and partial-failure behavior are the remaining gaps.

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?

Top-level schema coverage is low (33%), and the description compensates for parent_id by explaining the apex default. It also adds the semantic rule that a node with an owner OR a deadline becomes a task, which is real meaning beyond the schema. However map_id receives no explanation, and nesting behavior is only implied by 'subtree'.

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 (add a subtree of nodes) plus the target container (an existing map). The clause 'there is no separate task record; new work = new node' pre-empts the most likely confusion and separates this tool from create_map and from any imagined create_task.

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?

Gives clear conditions: works on an existing map, attaches under parent_id or at the apex when omitted, max 200 nodes per call. It implies that modifying existing nodes belongs to update_node rather than stating it, so the alternative is not named explicitly.

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