Skip to main content
Glama

List Segments

list_segments
Read-onlyIdempotent

List a page of visible, non-archived saved segments with subtype, status, and record counts. Use when the user asks what segments they have; filter by subtype or pass a limit of 1–100. For one complete definition, call get_segment with its segment_id. Requires 'discovery' scope.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of segments to return (default 10; maximum 100)
cursorNonext_cursor from a previous response
compactNoReturn small summaries by default. Set false to include saved filter_groups on filter segments; get_segment retrieves one complete definition.
subtypeNoOptional: filter results to a specific segment subtype ('filter', 'matched', 'similarity', 'propensity')
include_archivedNoInclude archived objects so they can be found and restored

Output Schema

NameRequiredDescriptionDefault
totalYesNumber of segments on this page
guidanceNoInterpretation or recovery guidance for this result
segmentsYesSaved segment summaries
count_unitNo
page_countNoNumber of objects on this page, not the organization total
count_stateNoUnknown means no count; available does not guarantee freshness. Recount for a current value.
next_cursorYesCursor for the next page, or null
next_actionsNoSuggested next calls using returned IDs and available scopes. Not executed and not user consent.
money_displayNoCurrency amounts formatted once from source paths ending in _cents. Use verbatim; do not divide again. Null/missing source amounts are omitted, not zero.
population_inputNoPopulation input used for the preview; IDs refer to their current saved definitions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • addedInput schema / properties / compact
      Added value: +{
      +  "default": true,
      +  "description": "Return small summaries by default. Set false to include saved filter_groups on filter segments; get_segment retrieves one complete definition.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "next_cursor from a previous response",
      +  "type": "string"
      +}
    • addedInput schema / properties / include_archived
      Added value: +{
      +  "description": "Include archived objects so they can be found and restored",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / limit / default
      Added value: +10
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of segments to return (default 50; REST maximum 100)"New value: +"Maximum number of segments to return (default 10; maximum 100)"
    • addedOutput schema / properties / count_state
      Added value: +{
      +  "description": "Unknown means no count; available does not guarantee freshness. Recount for a current value.",
      +  "enum": [
      +    "unknown",
      +    "available"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / count_unit
      Added value: +{
      +  "const": "records",
      +  "type": "string"
      +}
    • addedOutput schema / properties / guidance
      Added value: +{
      +  "description": "Interpretation or recovery guidance for this result",
      +  "type": "string"
      +}
    • addedOutput schema / properties / money_display
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "description": "Currency amounts formatted once from source paths ending in _cents. Use verbatim; do not divide again. Null/missing source amounts are omitted, not zero.",
      +  "propertyNames": {
      +    "type": "string"
      +  },
      +  "type": "object"
      +}
    • addedOutput schema / properties / next_actions
      Added value: +{
      +  "description": "Suggested next calls using returned IDs and available scopes. Not executed and not user consent.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "arguments": {
      +        "additionalProperties": {},
      +        "propertyNames": {
      +          "type": "string"
      +        },
      +        "type": "object"
      +      },
      +      "reason": {
      +        "type": "string"
      +      },
      +      "tool": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "tool",
      +      "arguments",
      +      "reason"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / page_count
      Added value: +{
      +  "description": "Number of objects on this page, not the organization total",
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
    • addedOutput schema / properties / population_input
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Population input used for the preview; IDs refer to their current saved definitions",
      +  "propertyNames": {
      +    "type": "string"
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already carry the read-only, idempotent, closed-world, non-destructive profile, so the description correctly spends its words elsewhere: the visibility rule (only visible, non-archived segments are listed), pagination via cursor, and the 'discovery' scope authorization requirement, which appears nowhere in the structured fields. It doesn't discuss ordering or what happens at the end of pagination, but that is minor given an output schema exists.

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?

Three short sentences, front-loaded with purpose before usage and the alternative. The '1–100' limit clause duplicates the schema and is the one sentence fragment that doesn't earn its place.

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 read-only list tool with full schema coverage, an output schema, and rich annotations, the description covers purpose, trigger, alternative, pagination, and the required auth scope. Only marginal gaps remain (result ordering), and those are low-stakes for this operation.

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

Parameters3/5

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

Schema coverage is 100%, so all five parameters, ranges, defaults, and the subtype enum are already documented. The description adds only the implicit default of excluding archived segments and restates the 1–100 limit already in the schema; subtype and compact are not elaborated beyond what the schema says. Baseline 3 is appropriate.

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 (list saved segments) plus the scope qualifiers (visible, non-archived, paged) and the fields returned (subtype, status, record counts). It explicitly routes the singular case to get_segment, so an agent can separate it from get_segment, count_segment, and list_audiences without opening any schema.

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 an explicit trigger ('when the user asks what segments they have') and an explicit alternative with its selecting condition ('For one complete definition, call get_segment with its segment_id'). No inference about which sibling to use is left to the agent.

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