Skip to main content
Glama
delega-dev

delega-mcp

by delega-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_automation

Create admin-only automation rules that run actions in-process when an event fires and conditions match, so no webhook receiver is needed.

Instructions

Create an automation rule: when an event fires and all conditions match, run the actions in-process — no webhook receiver needed (admin only). Example: when a task labeled bug is created, assign it to an agent at priority 3. Safety: cascades are depth- and budget-capped, rules never react to tasks they created, and field mutations on tasks under a live claim are always skipped (comments are append-only and still allowed). Hosted API only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesShort human-readable rule name
eventYesEvent that triggers the rule
activeNoSet false to create the rule disabled
actionsYesActions to run in order
conditionsNoConditions, AND-combined; omit to match every event

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.19.0
    • removedInput schema / properties / conditions / items / properties / value / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / conditions / items / properties / value / type
      Added value: +[
+  "string",
+  "number"
+]
  2. Addedv1.18.2

TDQS

A4.4/5.0
Behavior5/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 so thoroughly: it discloses cascade depth/budget caps, self-reaction prevention ('rules never react to tasks they created'), the ordering of condition evaluation, and the subtle field-mutation-vs-comment behavior under live claims. This is exactly the safety context an agent needs before creating a rule.

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 core definition, then example, then safety notes and access constraint. Dense but every clause earns its place; the safety sentence is long but carries non-redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a rule-creation tool with no annotations and no output schema, the description covers execution model, access control, safety interactions, and a worked example. An agent has everything needed to construct a valid, safe request.

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 coverage is 100%, so enum values, placeholders, and field/op pairings are already documented in the schema. The description's example maps to a real parameter combination but adds no syntax guidance beyond what the schema provides. Baseline 3 applies.

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+resource ('Create an automation rule') and immediately describes the execution model ('when an event fires and all conditions match, run the actions in-process'). The example and the phrase 'no webhook receiver needed' cleanly distinguish it from create_webhook and create_ingress_source siblings.

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?

Clear context: admin-only and 'Hosted API only' give real gating conditions, and the concrete example shows a canonical use case. It doesn't explicitly point agents to update_automation for modifications, so it falls short of a full 5.

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

Deploy Server

Other Tools