Skip to main content
Glama

Change an audience segment

update_contact_segment
Idempotent

Rename a segment, change its description, or REPLACE its filter — facets are not merged, so pass every facet the segment should keep. Omit all facets to leave the filter as it is; clear_filters: true widens it to every contact. A new filter is checked against the site's values and refused if it matches nobody (unless allow_empty). Changing membership starts no journey and emails nobody.

Input Schema

NameRequiredDescriptionDefault
nameNo
tagsNoTags the contact must carry — ALL of them. Values exactly as list_contact_filter_vocabulary returns them, capitals and spaces included
fieldsNoCustom field filters: field_key → exact value, e.g. {"budget":"high"}. Keys from list_contact_filter_vocabulary; a select field's value must be one of its options
searchNoFree text matched against email, first name, last name and company
statusNoPipeline status the contact must have
site_idYesThe site, from list_sites
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
segment_idYesA segment id, from list_contact_filter_vocabulary
allow_emptyNo
appointmentNoAppointment state: upcoming (booked, still to come), pending (upcoming, waiting for the owner to confirm), needs_time (asked for an appointment, waiting for the owner to pick a time), had (has had one before)
descriptionNo
field_rulesNoTyped custom-field rules, all must match. op "in"/"not_in" take values (e.g. countries ["BR","IN"]); "gt"/"lt" take a numeric value (numeric fields only); "before"/"on_or_after" take value "YYYY-MM-DD"; "is_set"/"is_not_set" take nothing. Prefer this over `fields` for anything but one exact value
clear_filtersNotrue widens the segment to every contact; cannot be combined with facets
acquisition_sourceNoLead source, exactly as list_contact_filter_vocabulary returns it
acquisition_campaignNoAcquisition campaign, exactly as list_contact_filter_vocabulary returns it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses critical non-obvious behavior beyond annotations: facets are replaced rather than merged, omitting all facets preserves the filter, clear_filters widens to every contact, new filters are validated and refused if they match nobody unless allow_empty, and changing membership triggers no journey or emails. These details substantially clarify the safety and side-effect profile despite annotations already marking the tool as idempotent and non-destructive.

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

Conciseness5/5

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

Four sentences, each carrying essential information, front-loaded with the core operations and the most dangerous gotcha (replacement vs merge). No redundant or filler content.

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?

Given the complexity of 15 parameters and no output schema, the description covers the most important behavioral rules an agent needs: replacement semantics, omission behavior, validation, and side effects. Combined with rich schema descriptions and annotations, it is complete enough to call the tool correctly.

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 description coverage is 80%, so most parameters are already documented. The description adds crucial semantics for the filter facets: they are REPLACED not merged, omission preserves the filter, clear_filters widens to all contacts, and allow_empty controls validation refusal. This goes beyond the schema's individual field descriptions.

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 specific operations — rename, change description, replace filter — on a segment, which is a precise verb+resource statement. It clearly distinguishes this tool from create_contact_segment and preview_contact_segment by focusing on modifying an existing segment.

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 clearly establishes the context for use: modifying an existing segment's name, description, or filters. It also gives concrete conditions such as omitting facets to leave the filter unchanged and using clear_filters to widen to all contacts, though it does not explicitly name sibling alternatives like preview_contact_segment for testing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources