killbottleneck-mcp

Official

Overview Schema Source Related Servers Discussions Admin

update_rule

Change an automation rule by toggling it or replacing its full trigger, actions, and conditions; edits apply to future events and clear the rule’s error state.

Instructions

Update an automation rule. Pass only enabled to toggle it on/off; otherwise pass the FULL new shape (name, trigger, actions, optional conditions/node_id) — partial field edits are not merged. Edits apply to future events only and clear the rule's error state.

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>",
      "rule_id": "<rule_id>"
    },
    "name": "update_rule"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`map_id`	Yes
`actions`	No
`enabled`	No
`node_id`	No
`rule_id`	Yes
`trigger`	No
`conditions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.0.1Nov 9, 2026

addedInput schema / properties / actions / items / properties / days

Added value: +{
+  "description": "set_deadline with advance weekly only: weekdays 1 = Monday … 7 = Sunday (e.g. [2,4] = Tuesday and Thursday); default = the weekday of the current deadline",
+  "items": {
+    "type": "integer"
+  },
+  "type": "array"
+}

addedInput schema / properties / actions / items / properties / every

Added value: +{
+  "description": "set_deadline with advance only: every N-th day/week/month (1-4, default 1)",
+  "type": "integer"
+}

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

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

changedInput schema / properties / actions / items / 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 / actions / items / 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"
+}

addedInput schema / properties / actions / items / properties / mode

Added value: +{
+  "description": "offer_assistant only: assistant package to open — rozbor (review the project/step), po_schuzce (write up after a meeting), priprava (meeting prep), revize (weekly review), trideni (sort notes), porada (morning briefing), nocni (evening planning); `to` as in notify (default node_owner)",
+  "enum": [
+    "porada",
+    "nocni",
+    "rozbor",
+    "trideni",
+    "po_schuzce",
+    "revize",
+    "priprava"
+  ],
+  "type": "string"
+}

addedInput schema / properties / actions / items / properties / month_day

Added value: +{
+  "description": "set_deadline with advance monthly only: day of the month 1-31 (a shorter month gets its last day, the next month this day again); default = the day of the current deadline",
+  "type": "integer"
+}

changedInput schema / properties / actions / items / properties / type / description

Previous value: -"What to do. run_agent and move_node target the trigger node; set_status/set_owner/set_deadline target the trigger node by default but accept `target` (a schedule rule needs node_id unless `target` is an explicit node id)."New value: +"What to do. reset_subtree = put the trigger node's sub-goals and tasks back to todo (a recurring step's checklist starts over; no parameters). offer_assistant = send the recipient a notification whose link opens the AI assistant in the given package (mode) for the trigger node/map — nothing runs until they click. run_agent and move_node target the trigger node; set_status/set_owner/set_deadline target the trigger node by default but accept `target` (a schedule rule needs node_id unless `target` is an explicit node id)."

changedInput schema / properties / actions / items / properties / type / enum

Previous value: -[
-  "set_status",
-  "set_owner",
-  "set_deadline",
-  "move_node",
-  "create_subnodes",
-  "notify",
-  "run_agent"
-]New value: +[
+  "set_status",
+  "set_owner",
+  "set_deadline",
+  "move_node",
+  "create_subnodes",
+  "notify",
+  "run_agent",
+  "offer_assistant",
+  "reset_subtree"
+]

First observedv0.33.2-betaAug 17, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral burden. It usefully discloses that partial edits are not merged, edits apply to future events only, and the rule's error state is cleared, but it does not cover permissions, reversibility, or response behavior.

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 short and front-loaded: it first states the operation, then the toggle/full-update rule, then side effects. Every sentence contributes useful information without unnecessary wording.

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 complex mutation tool with nested objects, no annotations, and no output schema, the description covers the critical non-obvious behavior: replacement semantics, toggle mode, and future-event-only effects. It is somewhat incomplete on required identifiers and error/response behavior, but the schema carries much of the structural detail.

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 description coverage is 0%, so the description must compensate. It adds key semantics for `enabled` versus full replacement and lists the full-shape fields, but it omits explanation of required `map_id` and `rule_id` and relies on the nested schema for trigger/action details.

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 an automation rule." It is clear what the tool does, but it does not explicitly differentiate from sibling operations such as create_rule or delete_rule.

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?

It gives important invocation guidance: pass only `enabled` to toggle, otherwise pass the full new shape. However, it does not explain when to use this tool versus alternatives, nor does it mention prerequisites such as required permissions.

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