HelpWell

Update a newsletter

update_newsletter

Destructive

Changes a draft or ready newsletter: name, audience, subject, preheader, From name or body fields, or marks it ready (ready: true) or back to draft. Changing a body field rebuilds the body from the plain fields, replacing block edits made in the editor; subject, preheader, From name and audience changes keep the body. Pass document to replace the whole email document as get_newsletter returns it.

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": {
      "campaignId": "<campaignId>"
    },
    "name": "update_newsletter"
  }
}

Input Schema

Name	Required	Description
`html`	No	Optional: a full HTML body instead of the blocks (it is sanitized; the brand header, address and unsubscribe footer are added).
`name`	No
`ready`	No	true marks it ready to schedule or use in a journey; false back to draft.
`title`	No	The headline.
`ctaUrl`	No	Button link (https).
`layout`	No
`eyebrow`	No	Small line above the title.
`signoff`	No	Closing line.
`subject`	No	Subject line.
`audience`	No	Who it goes to: contacts in ANY (match "any") or ALL (match "all") of the included segments, tags and filters, minus the excluded ones. Nothing included means every contact of the product. Consent and suppressions are always applied on top.
`ctaLabel`	No	Button label.
`document`	No	Optional: the complete email document (as get_newsletter returns it).
`fromName`	No	This email's own From name, like "AIMEE from Acme". Empty uses the sender name in Settings → Email.
`sections`	No	Body sections, each with a heading and body text.
`subjectB`	No	Optional second subject for an A/B test (half the audience gets each).
`preheader`	No	Preview text after the subject.
`productId`	No	Product id, or null for every product.
`campaignId`	Yes	Newsletter id from list_newsletters.
`introduction`	No	Opening paragraph(s). {{first_name}} and other merge tags work.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / fromName

Added value: +{
+  "description": "This email's own From name, like \"AIMEE from Acme\". Empty uses the sender name in Settings → Email.",
+  "maxLength": 100,
+  "type": "string"
+}

Changed10 schema fields changedOct 26, 2026

changedInput schema / properties / audience / properties / excludeFilters / description

Previous value: -"Conditions on contact fields. mode \"all\" or \"any\"; each rule is { field, operator, value }. Fields: contact.name, contact.email, contact.consent (subscribed | unknown | unsubscribed), contact.email_status, contact.product_id, contact.created_at, contact.last_seen_at, contact.attributes.<field> (tags are contact.attributes.tags), contact.events.<event>. Operators: is, is_not, contains, not_contains, gt, lt, exists, missing, before, after (dates are ISO or now-7d)."New value: +"Conditions on contact fields. mode \"all\" or \"any\"; each rule is { field, operator, value }. Fields: contact.name, contact.email, contact.consent (subscribed | unknown | unsubscribed), contact.email_status, contact.product_id, contact.created_at, contact.last_seen_at, contact.attributes.<field> (tags are contact.attributes.tags), contact.events.<event>. Operators: is, is_not, contains, not_contains, gt, gte, lt, lte, between (value and value2), any_of and none_of (value is a list of strings), exists, missing, before, after (dates are ISO or now-7d)."

changed

Input schema / properties / audience / properties / excludeFilters / properties / rules / items / properties / operator / enum

Previous value: -[
-  "is",
-  "is_not",
-  "contains",
-  "not_contains",
-  "gt",
-  "lt",
-  "exists",
-  "missing",
-  "before",
-  "after"
-]New value: +[
+  "is",
+  "is_not",
+  "contains",
+  "not_contains",
+  "gt",
+  "gte",
+  "lt",
+  "lte",
+  "between",
+  "any_of",
+  "none_of",
+  "exists",
+  "missing",
+  "before",
+  "after"
+]

added

Input schema / properties / audience / properties / excludeFilters / properties / rules / items / properties / value / anyOf

Added value: +[
+  {
+    "type": [
+      "string",
+      "number",
+      "boolean"
+    ]
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

removedInput schema / properties / audience / properties / excludeFilters / properties / rules / items / properties / value / type
```
Removed value: -[
-  "string",
-  "number",
-  "boolean"
-]
```
addedInput schema / properties / audience / properties / excludeFilters / properties / rules / items / properties / value2
```
Added value: +{
+  "type": [
+    "string",
+    "number"
+  ]
+}
```

changedInput schema / properties / audience / properties / filters / description

Previous value: -"Conditions on contact fields. mode \"all\" or \"any\"; each rule is { field, operator, value }. Fields: contact.name, contact.email, contact.consent (subscribed | unknown | unsubscribed), contact.email_status, contact.product_id, contact.created_at, contact.last_seen_at, contact.attributes.<field> (tags are contact.attributes.tags), contact.events.<event>. Operators: is, is_not, contains, not_contains, gt, lt, exists, missing, before, after (dates are ISO or now-7d)."New value: +"Conditions on contact fields. mode \"all\" or \"any\"; each rule is { field, operator, value }. Fields: contact.name, contact.email, contact.consent (subscribed | unknown | unsubscribed), contact.email_status, contact.product_id, contact.created_at, contact.last_seen_at, contact.attributes.<field> (tags are contact.attributes.tags), contact.events.<event>. Operators: is, is_not, contains, not_contains, gt, gte, lt, lte, between (value and value2), any_of and none_of (value is a list of strings), exists, missing, before, after (dates are ISO or now-7d)."

changedInput schema / properties / audience / properties / filters / properties / rules / items / properties / operator / enum

Previous value: -[
-  "is",
-  "is_not",
-  "contains",
-  "not_contains",
-  "gt",
-  "lt",
-  "exists",
-  "missing",
-  "before",
-  "after"
-]New value: +[
+  "is",
+  "is_not",
+  "contains",
+  "not_contains",
+  "gt",
+  "gte",
+  "lt",
+  "lte",
+  "between",
+  "any_of",
+  "none_of",
+  "exists",
+  "missing",
+  "before",
+  "after"
+]

addedInput schema / properties / audience / properties / filters / properties / rules / items / properties / value / anyOf

Added value: +[
+  {
+    "type": [
+      "string",
+      "number",
+      "boolean"
+    ]
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

removedInput schema / properties / audience / properties / filters / properties / rules / items / properties / value / type
```
Removed value: -[
-  "string",
-  "number",
-  "boolean"
-]
```
addedInput schema / properties / audience / properties / filters / properties / rules / items / properties / value2
```
Added value: +{
+  "type": [
+    "string",
+    "number"
+  ]
+}
```

First observedOct 18, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only say destructiveHint=true; the description goes far beyond that by explaining exactly what gets destroyed — changing a body field rebuilds the body and replaces block edits made in the editor, while subject/preheader/fromName/audience changes preserve the body. It also explains that 'document' wholesale-replaces the email document as get_newsletter returns it, which is precisely the destructive path an agent needs warned about.

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?

Two sentences, front-loaded with the verb and the affected fields, then the destructive caveat. The second sentence is dense with semicolon-separated clauses but every clause carries a distinct behavioral fact; nothing is padding.

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 19-parameter destructive mutation with nested audience objects and no output schema, the description covers the highest-risk semantics (body rebuild, document replacement, ready toggle). It leaves out partial-update semantics (are unmentioned fields untouched?) and the html-vs-sections interaction, which are the remaining meaningful gaps.

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 89%, so the baseline is 3; the description still adds real meaning by grouping parameters into body-rebuilding versus body-preserving sets, and by pointing at get_newsletter as the source shape for 'document'. It does not cover productId's null-means-all semantics or the html-vs-sections precedence, but the marginal value over the schema is genuine.

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+resource ('Changes a draft or ready newsletter') and enumerates the mutable surface: name, audience, subject, preheader, From name, body fields, and the ready/draft toggle. It does not differentiate itself from siblings like create_newsletter, update_email_template, or schedule_newsletter, which is the only thing keeping it from a 5.

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?

The phrase 'draft or ready newsletter' and 'marks it ready (ready: true) or back to draft' imply when this tool applies versus schedule_newsletter, but that routing is left to inference. There is no explicit 'use X instead when Y' statement and no prerequisites or exclusions named.

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

All HelpWell tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?