Skip to main content
Glama

list_cohort_moves

Read-only

List bulk AP migrations

Detected bulk migrations between Access Points, largest first. A cohort is a gap-≤3-day island of (from_provider, to_provider) mover days that clears three thresholds: at least 25 participants, at least 40 % of them on the busiest day (which rejects a steady drip), and at most 20 active days for the pair over the trailing 40 days (which rejects a recurring partnership).

Every day is the PROBE-OBSERVATION day — the day the change scan saw the SMP record change, not the day the migration was executed — so a cohort is always a [first_day, last_day] range and peak_day is the busiest observation day. Render the range, never a single date.

top_country is derived from the ICD prefix of the participant identifiers, not from business-card country fields. merge_suspect marks a cohort large enough (or whose source provider no longer resolves in the directory) to be a provider merge or a renamed provider rather than that many independent customer decisions — the canonical case is Sovos → Sage, 10,574 participants. Such rows are data events, not customer decisions; verify one before quoting it. The flag is a CURRENT judgment, re-evaluated on every recompute, not frozen at detection.

from/to are OVERLAP bounds (a cohort counts when its range intersects the window), defaulting to the trailing 90 days the detector re-clusters. Mover history begins 2026-07-24, so no cohort predates it. id is a request-lifetime handle for the participant drill-down — never persist one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoInclusive upper bound of the observation window (`YYYY-MM-DD` UTC); a cohort matches when its `first_day` is at or before it. Defaults to today.
fromNoInclusive lower bound of the observation window (`YYYY-MM-DD` UTC); a cohort matches when its `last_day` is at or after it. Defaults to 90 days ago.
limitNoPage size, clamped to [1, 200]. Defaults to 50.
cursorNoOpaque pagination cursor returned as `next_cursor` by the previous page.
providerNoOnly cohorts involving this Provider key (`/v1/aps/{key}`). Matches EITHER side unless `direction` narrows it.
directionNoWhich side of the `provider` filter to take: `in` = cohorts the provider received, `out` = cohorts it lost, `both` = either. Only meaningful together with `provider`.both
merge_suspectNoHow to treat probable provider merges / slug changes: `include` (default), `exclude` for real customer migrations only, or `only` to review the flagged rows.include
min_participantsNoOnly cohorts with at least this many participants. The detector's own floor is 25, so a lower value cannot surface smaller groups.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses substantial behavioral nuances: cohorts are based on probe-observation day rather than execution day, `top_country` derives from ICD prefixes, `merge_suspect` is a re-evaluated current judgment, and `id` is only request-lifetime. It also explains what the thresholds reject (steady drip, recurring partnership), giving the agent a mental model of the tool's behavior.

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?

The description is longer than average, but every sentence earns its place by explaining non-obvious semantics or trapping pitfalls. It is front-loaded with the core purpose and detection definition, then organizes filters and output-field caveats in coherent paragraphs. There is no fluff or repetition of schema defaults.

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 read-only list tool with no output schema, the description covers the essential response-field semantics (`top_country`, `merge_suspect`, `peak_day`, `first_day`, `last_day`, `id`), ordering ('largest first'), date-range behavior, defaults, and data-history boundary. An agent has enough context to call the tool correctly and interpret results confidently.

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?

Although the schema already provides 100% coverage of parameter names and defaults, the description adds material meaning: `from`/`to` are overlap bounds tied to the detector's re-clustering window, `min_participants` cannot surface groups below the detector's floor, and `merge_suspect` is a live judgment rather than a frozen flag. This goes well beyond a bare schema and genuinely helps an agent choose and set values correctly.

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 specific verb and resource ('List bulk AP migrations') and immediately distinguishes the tool's subject by defining a 'cohort' with precise detection thresholds. It clearly differentiates this from the sibling drill-down tool by framing the output as the cohort list itself, and it even explains what the returned `id` is for.

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?

The description provides ample context on when to use the tool: bulk migrations, detection criteria, observation-day semantics, and filter behavior. It does not explicitly name alternative tools or state 'when not to use this,' but the context is clear enough that an agent can infer the appropriate scenario. It misses explicit exclusions or comparison to sibling tools like list_cohort_move_participants.

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