Skip to main content
Glama
Sign In

Mailercloud

by com.mailercloud.mcp
OverviewDiscussionsAdmin

update_segment

DestructiveIdempotent

Change a segment. Give only what changes: name, match, lists (list names, or all_contacts: true for every contact) or rules; everything left out is kept from the current definition. Rules are replaced as a set, so to change one rule pass all of them (get_segment shows the current rules). The preview shows the full result; it needs confirm: true to apply. Each rule has a filter_type: contact_details (built-in field: email_status, verification_status, contact_rating, email_domain, mailbox_provider, signup_source; mailbox_provider and signup_source take operator was or was_not), contact_property (a built-in contact field such as country, city, state or job_title, with property_type text|number|date; Mailercloud does not yet accept custom fields here, so a segment on a custom field is built in Mailercloud under Audience > Segments), tag (operator is_tagged|is_not_tagged, filter_by any_of|all_of, value = tag IDs), or activity (category + activity + filter_by). Operators ending in is_known/is_unknown take no value; any_of takes an array; between/date_between take {from,to}; in_the_last_days takes 1-200 days. For campaign activity, filter_by is one of for, between, any_of_the_last_five, all_of_the_last_five, any_of_last_seven_day, any_of_last_one_month, any_of_last_three_month; for an exact number of days use category subscriber_opened or subscriber_clicked (with match all). The API does not let a rule target one specific campaign. Example 1, contacts who opened any campaign in the last month: {"filter_type":"activity","category":"campaign","activity":"opened","filter_by":"any_of_last_one_month"}; for exactly 30 days: {"filter_type":"activity","category":"subscriber_opened","filter_by":"in_the_last_days","value":30}. Example 2, country is India: {"filter_type":"contact_property","field":"country","property_type":"text","operator":"equal_to","value":"India"}. Set dry_run: true to preview.

Input Schema

NameRequiredDescriptionDefault
nameNoNew segment name; leave out to keep the current one
listsNoNew list NAMES the segment evaluates; leave out to keep the current lists
matchNoall or any; leave out to keep the current one
rulesNoThe complete new rule set, replacing every current rule; leave out to keep the current rules (get_segment shows them)
confirmNoMust be true to replace the segment. Leave it out first to get a preview, show it to the user, and ask them to confirm
dry_runNoValidate the rules and show the request without changing anything
segment_idYesSegment ID (as returned by create_segment)
all_contactsNoSet true to evaluate all contacts instead of specific lists

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / lists / description
      Previous value: -"List NAMES the segment evaluates. Give lists, or set all_contacts: true"New value: +"New list NAMES the segment evaluates; leave out to keep the current lists"
    • changedInput schema / properties / match / description
      Previous value: -"all or any (full replace)"New value: +"all or any; leave out to keep the current one"
    • changedInput schema / properties / name / description
      Previous value: -"Segment name (full replace: pass it even if unchanged)"New value: +"New segment name; leave out to keep the current one"
    • changedInput schema / properties / rules / description
      Previous value: -"The COMPLETE new rule set; it replaces every existing rule"New value: +"The complete new rule set, replacing every current rule; leave out to keep the current rules (get_segment shows them)"
    • changedInput schema / properties / rules / items / properties / field / description
      Previous value: -"contact_details: email_status, verification_status, contact_rating, email_domain, mailbox_provider or signup_source. contact_property: the field key from list_custom_fields (letters, digits, underscore)"New value: +"contact_details: email_status, verification_status, contact_rating, email_domain, mailbox_provider or signup_source. contact_property: a built-in contact field such as country, city or job_title (custom fields are not yet accepted by Mailercloud here)"
    • changedInput schema / required
      Previous value: -[
-  "segment_id",
-  "name",
-  "match",
-  "rules"
-]New value: +[
+  "segment_id"
+]
  2. Changed13 schema fields changed
    • addedInput schema / properties / all_contacts
      Added value: +{
+  "description": "Set true to evaluate all contacts instead of specific lists",
+  "type": "boolean"
+}
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Must be true to replace the segment. Leave it out first to get a preview, show it to the user, and ask them to confirm",
+  "type": "boolean"
+}
    • changedInput schema / properties / lists / description
      Previous value: -"List NAMES. Omit to evaluate all contacts; [] clears the lists"New value: +"List NAMES the segment evaluates. Give lists, or set all_contacts: true"
    • changedInput schema / properties / match / description
      Previous value: -"all or any (full replace),required"New value: +"all or any (full replace)"
    • addedInput schema / properties / match / enum
      Added value: +[
+  "all",
+  "any"
+]
    • changedInput schema / properties / name / description
      Previous value: -"Segment name (full replace: pass it even if unchanged),required"New value: +"Segment name (full replace: pass it even if unchanged)"
    • changedInput schema / properties / rules / description
      Previous value: -"The COMPLETE new rule set; it replaces every existing rule,required"New value: +"The COMPLETE new rule set; it replaces every existing rule"
    • addedInput schema / properties / rules / items / properties / category / enum
      Added value: +[
+  "campaign",
+  "automation",
+  "engagement_status",
+  "global_engagers",
+  "global_openers",
+  "subscriber_opened",
+  "subscriber_clicked"
+]
    • changedInput schema / properties / rules / items / properties / filter_type / description
      Previous value: -"contact_details | contact_property | tag | activity,required"New value: +"contact_details | contact_property | tag | activity"
    • addedInput schema / properties / rules / items / properties / filter_type / enum
      Added value: +[
+  "contact_details",
+  "contact_property",
+  "tag",
+  "activity"
+]
    • addedInput schema / properties / rules / items / properties / property_type / enum
      Added value: +[
+  "text",
+  "number",
+  "date"
+]
    • changedInput schema / properties / rules / items / properties / value / description
      Previous value: -"string or number; string array for any_of (tag rules: tag IDs); {from,to} for between/date_between; integer 1-365 for in_the_last_days; omit for is_known/is_unknown style operators"New value: +"string or number; string array for any_of (tag rules: tag IDs); {from,to} for between/date_between; integer 1-200 for in_the_last_days; omit for is_known/is_unknown style operators"
    • changedInput schema / properties / segment_id / description
      Previous value: -"Segment ID (as returned by create_segment),required"New value: +"Segment ID (as returned by create_segment)"
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description adds the crucial mechanics: fields left out are preserved, but rules are replaced as a complete set. It also explains the preview/confirm gate and the dry_run mode, which are not derivable from annotations alone.

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

Conciseness3/5

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

Front-loads the partial-update rule well, but the body is a dense single paragraph mixing purpose, workflow, and a lengthy rule taxonomy that substantially restates schema descriptions. Examples earn their place, but the wall-of-text format hurts scanability and duplicates structured data.

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 destructive nested-rule update with no output schema, the description covers everything needed: partial-update semantics, full rule replacement, preview/confirm flow, dry_run, rule-type taxonomy, and concrete examples. An agent can call this correctly from the description alone.

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?

With 100% schema coverage the baseline is 3, and the description earns a bump by explaining rule construction: operator/value shapes (any_of arrays, between {from,to}, in_the_last_days 1-200), list names vs all_contacts, and campaign activity filter_by values. It duplicates some schema text, so it does not fully transcend the structured fields.

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 and resource ('Change a segment') and immediately scopes it to partial updates, which cleanly distinguishes it from create_segment. It also names get_segment as the source of current rule state, so an agent can route between the two without opening schemas.

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

Usage Guidelines5/5

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

Provides explicit workflow guidance: omit fields to keep them, pass all rules to replace the set, preview first without confirm, show the preview to the user, then pass confirm:true. It also points to get_segment for the existing rules and to dry_run for validation.

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

All Mailercloud toolsInspect
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