Skip to main content
Glama
Sign In

Mailercloud

by com.mailercloud.mcp
OverviewDiscussionsAdmin

create_segment

Create an audience segment: a saved, dynamic filter over contacts. match all|any combines the rules; lists (by NAME) narrows the base, omitted = all contacts. 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"}. Rules are validated before any API call; set dry_run: true to preview.

Input Schema

NameRequiredDescriptionDefault
nameYesSegment name, 1-100 characters, unique
listsNoList NAMES to evaluate (max 150). Omit to evaluate all contacts
matchYesall = every rule must match; any = one rule is enough
rulesYesAt least one rule
dry_runNoValidate the rules and show the request without creating anything

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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)"
  2. Changed9 schema fields changed
    • changedInput schema / properties / match / description
      Previous value: -"all = every rule must match; any = one rule is enough,required"New value: +"all = every rule must match; any = one rule is enough"
    • addedInput schema / properties / match / enum
      Added value: +[
+  "all",
+  "any"
+]
    • changedInput schema / properties / name / description
      Previous value: -"Segment name, 1-100 characters, unique,required"New value: +"Segment name, 1-100 characters, unique"
    • changedInput schema / properties / rules / description
      Previous value: -"At least one rule,required"New value: +"At least one 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"
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare the write, open-world, non-idempotent, non-destructive profile; the description adds that rules are validated before any API call, dry_run previews the request, and a rule cannot target one specific campaign. It also notes the current custom-field limitation, though permissions and response behavior are left unstated.

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?

The description is front-loaded and generally efficient, but it is a single dense paragraph that mixes schema-restated field enumerations with genuinely useful examples and constraints. The length is largely justified by the complex nested rule schema, though it could be structured more scanably.

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 complex nested rule builder, it covers the essential branches, examples, validation, and dry_run preview. It leaves the created segment's return shape and any permission assumptions unstated, so an agent can invoke it correctly but has minor gaps about the result.

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?

Even with 100% schema coverage, the description adds cross-parameter meaning: how match combines rules, how list names narrow the base or default to all contacts, and how each filter_type pairs with operators, filter_by values, and value shapes. The two JSON examples make the nested rule object clearer than the schema alone.

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?

The description opens with a precise verb and resource ('Create an audience segment') and defines it as 'a saved, dynamic filter over contacts,' which clearly separates it from list_segments, get_segment, update_segment, and from create_list/create_tag by resource. An agent can identify the operation without opening the schema.

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

Usage Guidelines4/5

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

It explains how to populate match, lists, and rules, and when to use dry_run for previewing. However, it never explicitly names update_segment/list_segments as alternatives or states when not to use this tool, so it is clear context but not full when/when-not routing.

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