Kit MCP Server

Overview Schema Source Related Servers Discussions Admin

Update a sequence email

update_sequence_email

Destructive

Modify a sequence email's subject, body, position, schedule, or publish state in Kit; requires confirm=true because changes can affect delivery, audience, or irreversible state.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`content`	No	New HTML body content of the email
`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.
`subject`	No	New subject line for the email
`email_id`	Yes	Positive email id.
`position`	No	New zero-based position of the email in the sequence
`published`	No	Pass `true` to publish a draft email or `false` to unpublish it
`send_days`	No
`delay_unit`	No	New delay unit. Use `days` for schedule-aware delivery, `hours` for a fixed hourly delay
`delay_value`	No	New delay value
`sequence_id`	Yes	Positive sequence id.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`preview_text`	No	New preview text shown in email clients before the email is opened
`email_template_id`	No	New email template ID for layout and styling. Pass `null` to clear

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv3.0.0Oct 7, 2026

addedInput schema / $defs

Added value: +{
+  "send_days": {
+    "description": "Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)",
+    "items": {
+      "type": "string"
+    },
+    "type": [
+      "array",
+      "null"
+    ]
+  }
+}

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 / payload / properties / send_days / $ref
```
Added value: +"#/$defs/send_days"
```

removedInput schema / properties / payload / properties / send_days / description

Removed value: -"Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)"

removedInput schema / properties / payload / properties / send_days / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / payload / properties / send_days / type
```
Removed value: -[
-  "array",
-  "null"
-]
```
addedInput schema / properties / send_days / $ref
```
Added value: +"#/$defs/send_days"
```

removedInput schema / properties / send_days / description

Removed value: -"Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)"

removedInput schema / properties / send_days / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / send_days / type
```
Removed value: -[
-  "array",
-  "null"
-]
```

First observedv2.0.1Oct 2, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value on top by enumerating what can be affected — delivery behavior, audience membership, published data, irreversible state — and by flagging the confirm=true gate, which tells the agent this is a high-consequence mutation rather than a routine edit.

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 with the impact warning front-loaded ahead of the confirmation requirement. No filler, no repetition of schema detail.

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?

With 15 parameters, a nested payload object, three mutually exclusive body-input styles, and no output schema, the description is thin, though the 93% schema coverage absorbs most of the burden. It conveys risk and the confirm gate but says nothing about choosing between individual flags, payload, and payload_file, or about partial-update semantics.

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%, so the schema already documents all 15 parameters, including the nested payload fields, send_days reset semantics, and the payload/payload_file mutual exclusion. The description reinforces confirm=true but contributes no syntax, format, or constraint detail the schema does not already provide; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb+resource ("Update a sequence email") but this largely restates the name and title verbatim, adding no differentiation from siblings like create_sequence_email or delete_sequence_email. The second sentence does broaden the picture by naming impact areas (delivery, audience membership, published data), which gives some sense of scope beyond a pure tautology.

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 actionable guidance is "Requires confirm=true," which is a precondition rather than a when-to-use rule. It never says when to choose this tool over delete_sequence_email, update_sequence, or create_sequence_email, and gives no conditions under which it should be avoided.

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

Deploy Server

Update a sequence email

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools