killbottleneck-mcp

Official

Overview Schema Source Related Servers Discussions Admin

save_rule_template

Create or update reusable automation rule templates in an instance-wide library for applying trigger-and-action rules without map or node scope.

Instructions

Save a rule shape into the instance-wide template library (create, or update with template_id — only the author or an admin may update). Templates carry no map and no node scope; create_subnodes may only use parent=trigger_node. Template names are unique.

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

Input Schema

Name	Required	Description
`name`	Yes	Unique template name (max 120 chars)
`actions`	Yes
`trigger`	Yes
`conditions`	No
`template_id`	No	Update an existing template (author or admin only); omit to create

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 load and does disclose key behavior: authorization for updates, the instance-wide scope, the fact that templates carry no map or node scope, the create_subnodes parent constraint, and name uniqueness. It stops short of describing what is returned or what happens on a name conflict, but it covers the main mutation risks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with the core create/update operation and permission rule front-loaded, followed by scope constraints and uniqueness. No redundant wording and every sentence adds information.

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?

Given a complex nested schema and no output schema, the description covers the critical behavioral constraints an agent needs: authorization, scope, parent constraint, and uniqueness. The remaining gaps, such as return value and conflict handling, are modest against the rich schema.

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?

Schema description coverage is 40%, so the description should compensate. It clarifies template_id's update semantics, name uniqueness, and the create_subnodes parent restriction, but adds nothing for trigger, actions, or conditions beyond what the already-detailed schema provides. Partial compensation only.

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 gives a specific verb and resource: 'Save a rule shape into the instance-wide template library', and its parenthetical clarifies create versus update via template_id. It is distinguishable from delete_rule_template and list_rule_templates by the 'template library' framing, though it never explicitly names or contrasts a sibling.

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 states the create-vs-update condition and the authorization rule ('only the author or an admin may update'), which is useful context. However, it gives no guidance on when to call this instead of create_rule, update_rule, or list_rule_templates, leaving the sibling routing implicit.

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