Skip to main content
Glama
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA

Create Segment

create-segment

Build a dynamic, rules-based audience for campaigns using contact attributes, lists, tags, engagement, or events. The audience is recomputed regularly and before each campaign send.

Instructions

Create a segment: a dynamic audience defined by rules, which campaigns target through segment_ids. Its members are recomputed regularly, and again before a campaign sends to it.

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.

The segment comes back with status: processing while its members are computed in the background. Call get-segment until it is ready, then tell the user its contact_count. Creating a segment messages nobody.

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": {
      "name": "<name>",
      "filter": "<filter>"
    },
    "name": "create-segment"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
filterYes
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 only say it is a non-destructive, non-idempotent write. The description adds substantial behavior beyond them: asynchronous `status: processing` computation, the need to poll get-segment, the refusal of undefined properties/event fields, the structured error path format (`conditions.1.operator`), and that membership is recomputed regularly and before sends.

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?

Long but front-loaded and organized with bold section headers, so an agent can scan to the relevant part. Some content (the rolling-window vs. fixed-date distinction, rule descriptions) is partly duplicated in the schema, which costs a point on tightness.

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 complex nested-schema creation tool with no output schema, it covers everything an agent needs: prerequisites, tree construction, rule selection, failure recovery, and the async lifecycle through to reporting `contact_count`. No significant gap remains.

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?

The reported 0% coverage is misleading because the nested $defs carry rich per-field descriptions, yet the description still adds real meaning on top: the invariant that the filter root is always a group, how and/or nest for 'A and (B or C)', the 100-rule/10-level limits, which rules accept a rolling `time_window`, and how `negate` and `does_not_exist` express absence.

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: 'Create a segment: a dynamic audience defined by rules, which campaigns target through `segment_ids`.' It further defines what a segment is (dynamically recomputed membership), which separates it from update-segment and get-segment without naming them.

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 pre-work routing ('Property keys come from list-contact-properties, event names ... from list-events, list and tag ids from list-lists and list-tags') and a per-rule decision table for which of the seven rule types to use. It also states the post-create workflow (poll get-segment until `ready`) and the safety fact that 'Creating a segment messages nobody.'

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