Skip to main content
Glama
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA

Update Segment

update-segment
Destructive

Rename a segment, change its description, or replace its full rule tree; omitted fields remain unchanged.

Instructions

Rename a segment, change its description or replace its rules. Omitted fields are unchanged.

filter REPLACES the whole rule tree: to change one rule, read the tree with get-segment, edit it and send all of it back. New rules change who the campaigns and automations using the segment reach, scheduled campaigns included, so before sending filter you MUST confirm with the user, naming the segment. The members are then recomputed in the background, and status is processing until they are.

Look up what the rules will name before writing them. Property keys come from list-contact-properties, event names and their fields from list-events, list and tag ids from list-lists and list-tags, and campaign ids from the channel's campaign list tool. A filter naming a property or an event field the organization has not defined is refused.

Shape. filter is a tree whose root is always a group. A group joins its conditions with and or or, and a condition is a rule or another group, so "A and (B or C)" is an and group holding A and an or group of B and C. A filter needs at least one rule and holds at most 100, in groups nested at most 10 deep.

Choosing a rule.

  • Who they are, or a custom property: attribute.

  • The lists they are in or the tags they carry: list_membership, tag.

  • Whether a channel can reach them (subscribed, deliverable): channel_status.

  • How often they engaged with messages, optionally in a recent window: engagement_count.

  • When they last engaged, or that they never did: last_engagement.

  • What they did with one specific campaign or automation: message_engagement.

  • What they did in the app, site or store: event.

Recent activity. Only engagement_count and event take a rolling time_window. Dates in attribute and last_engagement are fixed and do not move with time, so "opened an email in the last 30 days" is an engagement_count of at least 1 with a 30-day window, not a last_engagement date.

Absence. negate: true on list_membership, tag, message_engagement or event matches the contacts the rule would leave out, and last_engagement with does_not_exist matches contacts who never did the action. "Ordered before, but not in the last 90 days" is an and group of a plain event rule and the same rule with a 90-day window and negate: true.

Reaching people. A segment holds every contact its rules match, whatever their consent. Add a channel_status rule when it should hold only contacts a channel can message.

If the filter is refused, the error gives the path of each problem inside the tree (e.g. conditions.1.operator). Fix those and call again.

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": {
      "id": "<id>"
    },
    "name": "update-segment"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe segment id.
nameNo
filterNo
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description supplies the concrete consequences: `filter` replaces the whole rule tree, affects who campaigns and automations reach including scheduled sends, members are recomputed in the background, and `status` is `processing` meanwhile. It also documents refusal behaviour with error paths (e.g. `conditions.1.operator`) and structural limits of 100 rules and 10 nesting levels.

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?

Bold section headings, bullets and examples keep a long description navigable, and the most dangerous fact (replacing the rule tree, confirm with the user) is front-loaded. There is mild redundancy, e.g. the rolling-window point is restated in both the 'Recent activity' paragraph and the rule list.

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 four-parameter tool with a deeply nested filter union and no output schema, the description covers structure, per-rule semantics, negation, consent caveats via `channel_status`, and error recovery. An agent has enough to construct a valid tree and recover from a refusal without opening other docs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level schema coverage is low (25%), and the description compensates heavily: it explains the group-root tree shape for `filter`, that omitted fields are unchanged, which rule types carry a rolling `time_window` versus fixed dates, and `negate` semantics on four rule types. It adds meaning well beyond what the schema alone states.

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?

Opens with a specific verb-and-resource statement plus a partial-update contract: 'Rename a segment, change its description or replace its rules. Omitted fields are unchanged.' This separates it from create-segment and from get-segment, which is explicitly named as the read counterpart.

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?

Gives explicit when-to guidance (read the tree with get-segment, edit, send the whole tree back), a mandatory pre-condition (confirm with the user, naming the segment, before sending `filter`), lookup prerequisites via list-contact-properties/list-events/list-lists/list-tags, and rule-selection routing between attribute, list_membership, tag, channel_status, engagement_count, last_engagement, message_engagement and event.

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