killbottleneck-mcp

Official

Overview Schema Source Related Servers Discussions Admin

create_rule

Build automation rules for a map: define WHEN triggers and AND conditions fire, then run ordered actions on future UI, API, or agent changes—no retroactive runs.

Instructions

Create an automation rule on a map: WHEN trigger fires (and optional AND conditions match) DO the actions in order. Rules run for changes made in the UI, via API and by agents alike. Structural limits: 50 rules per map, 10 actions, 20 conditions — there is NO monthly run quota. A rule applies only to future events, never retroactively. node_id scopes the rule to one node (required for schedule rules whose actions target a node).

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>",
      "name": "<name>",
      "trigger": "<trigger>",
      "actions": "<actions>"
    },
    "name": "create_rule"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Human-readable rule name (max 120 chars)
`map_id`	Yes
`actions`	Yes	1-10 actions, executed in order
`enabled`	No	Default true
`node_id`	No	Optional: scope the rule to one node of the map
`trigger`	Yes
`conditions`	No	Optional AND chain checked on the trigger node

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.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: 50 rules per map, 10 actions, 20 conditions, explicitly no monthly run quota, and non-retroactive application. It omits what a successful call returns (rule id?) and any permission requirements, which would complete the picture for a creation tool.

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-loads the core model in one clause, then layers limits and the node_id caveat; almost every clause carries information. The limits sentence is slightly compressed into a dash-list, but nothing is padded or redundant.

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 7-parameter tool with deep nested objects and no output schema, the description supplies the mental model, hard limits, temporal scope, and the one non-obvious parameter constraint. Gaps are modest: no statement of the response, of what happens on validation failure, or how a created rule relates to templates.

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 71%, so the schema already explains most parameters in depth, and the description adds targeted meaning on top: node_id's scoping role and the special requirement for schedule rules whose actions target a node. The WHEN/AND/DO framing also structures trigger, conditions and actions conceptually, though it adds nothing about name, enabled, or ordering beyond 'in order'.

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?

Opens with a precise verb+resource ('Create an automation rule on a map') and immediately explains the WHEN/AND/DO semantics, so the agent knows exactly what will be built. It does not name sibling tools such as update_rule or save_rule_template, so differentiation is only implicit through the verb 'Create'.

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 useful operating context — rules fire for UI, API and agent changes, apply only to future events, and node_id is required for schedule rules targeting a node — which shapes whether this tool is the right one. However, it never states when to use an alternative (e.g. update_rule to modify an existing rule, save_rule_template to reuse one), so routing guidance stays implied.

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