Kit MCP Server

Overview Schema Source Related Servers Discussions Admin

Create a sequence

create_sequence

Destructive

Create a new email sequence for subscriber automation. Requires confirm=true as it may change delivery, audience membership, or published data.

Instructions

Create a sequence. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

Input Schema

TableJSON Schema

Name	Required	Description
`hold`	No	When `true`, subscribers added via Visual Automations stay in the sequence after receiving the last email.
`name`	No	The name of the sequence.
`active`	No	`true` to activate the sequence, `false` to deactivate it.
`repeat`	No	When `true`, subscribers can restart the sequence multiple times.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`send_days`	No	The days of the week to send the sequence on. Must be one of: `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`, `sunday`.
`send_hour`	No	The hour of the day to send the sequence at. Must be an integer between 0 and 23.
`time_zone`	No	The timezone to use for the sequence. Must be a valid IANA timezone string.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No	The sending email address to use. Uses the account's sending email address if not provided.
`email_template_id`	No	Id of the email template to use.
`exclude_subscriber_sources`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv3.0.0Oct 7, 2026

addedInput schema / $defs

Added value: +{
+  "exclude_subscriber_sources": {
+    "description": "The subscriber sources to exclude from the sequence.",
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "ids": {
+          "items": {
+            "description": "The ids of the subscriber sources to exclude.",
+            "type": "integer"
+          },
+          "type": "array"
+        },
+        "type": {
+          "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "ids"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / exclude_subscriber_sources / $ref
```
Added value: +"#/$defs/exclude_subscriber_sources"
```
removedInput schema / properties / exclude_subscriber_sources / description
```
Removed value: -"The subscriber sources to exclude from the sequence."
```

removedInput schema / properties / exclude_subscriber_sources / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "ids": {
-      "items": {
-        "description": "The ids of the subscriber sources to exclude.",
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "type": {
-      "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / exclude_subscriber_sources / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / exclude_subscriber_sources / $ref
```
Added value: +"#/$defs/exclude_subscriber_sources"
```
removedInput schema / properties / payload / properties / exclude_subscriber_sources / description
```
Removed value: -"The subscriber sources to exclude from the sequence."
```

removedInput schema / properties / payload / properties / exclude_subscriber_sources / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "ids": {
-      "items": {
-        "description": "The ids of the subscriber sources to exclude.",
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "type": {
-      "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / exclude_subscriber_sources / type
```
Removed value: -"array"
```

First observedv2.0.1Oct 2, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that by naming the blast radius — delivery, audience membership, published data, irreversible state — and restating the confirm gate, which is exactly the kind of context an agent should weigh before a destructive call.

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?

Two short sentences, zero filler, with the risk warning and the confirm requirement front-loaded. Nothing is padded or repeated.

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

Completeness3/5

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

For a 14-parameter, destructive, nested-object tool with no output schema, the description covers consequences and the confirm gate but omits sibling routing and the mutual exclusivity between payload, individual body flags, and payload_file that the schema mentions. It is adequate given 93% schema coverage and strong annotations, but leaves real 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?

Schema description coverage is 93% across 14 parameters, so the schema already documents name, active, send_days, time_zone, payload_file and the rest. The description adds no parameter detail beyond echoing the confirm requirement that the schema itself already explains. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ("Create a sequence"), which is unambiguous on its own. However, it does nothing to distinguish itself from the many sibling sequence tools (create_sequence_email, update_sequence, delete_sequence, add_subscriber_to_sequence), so an agent still has to reason about scope from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is the confirm=true prerequisite, which is a precondition rather than a when-to-use/when-not instruction. There is no mention of when to choose this over update_sequence or create_sequence_email, and no stated context about when creating a sequence is appropriate.

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

Deploy Server

Create a sequence

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools