Skip to main content
Glama

get_provider_moves

Read-only

Get moves between providers

The from→to matrix of participants that changed Access Point provider in a trailing window: who lost participants to whom, for the whole network or for one country (country), in one call. The top largest providers on each side keep their identity (from = sources, to = destinations; a provider can be on both). Every other provider folds into one "Other" node per side, and other gives the number of folded providers and their participants.

pairs is the COMPLETE folded matrix, largest first: a null from or to is the "Other" node of that side, zero cells are omitted, and the values sum to total exactly. A node's value is all its moves in the window, also the moves to or from a folded provider.

A move inside one provider (between two of its own Access Points) is not counted. Every day is the PROBE-OBSERVATION day — when the change scan saw the SMP record change — not the day a migration was executed. A window with no moves returns total: 0 and empty lists.

PLATFORM MOVES. A mover is a platform move when the platform that serves the participant stayed and only the certificate Seat changed: it is not a customer decision. The verdict is per DIRECTED provider pair (from → to), over all its movers since 2026-08-02, with one of two reasons (same_host, sub_provider): at least 90% of the movers whose endpoint host can be compared (5 or more, and at least 50% of all movers of the pair) kept their endpoint host, or at least 90% of 25 or more movers still carry, at the new provider, the sub-provider brand of the provider they left. It is a CURRENT judgment, computed again on every rollup cycle. The movers of a platform-move pair are in no node, in no cell and not in total: platform gives their number and the number of directed provider pairs they come from. The matrix has Providers only; a Vendor is not in it.

With country, the matrix holds the moves of the participants of that country: card country first, the country of the ICD prefix as fallback. The window is then one day longer (from = today − days), the same days as the country_*_{7,30,90}d fields of GET /v1/aps?country=. platform_by_provider gives the platform moves of EVERY provider of that country (not limited by top): what a net-growth chart takes out of a provider's movers to show its organic net. A move with no attributable country is dropped, so the countries do not add up to the network. A platform move is judged per provider pair across the whole network, not per country.

country_share gives the movers of one country (the country param, else FR) among all movers of the window that have a country. This share includes the platform moves.

Input Schema

NameRequiredDescriptionDefault
topNoHow many providers keep their identity on each side. The matrix has at most `(top + 1)²` cells.
daysNoThe trailing window in days, ending today (UTC).
countryNoScope the matrix to one market: an ISO 3166-1 alpha-2 code (e.g. `BE`), case-insensitive. Anything that is not exactly two letters is a 400. Omit it for the whole network.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "Scope the matrix to one market: an ISO 3166-1 alpha-2 code (e.g. `BE`), case-insensitive. Anything that is not exactly two letters is a 400. Omit it for the whole network.",
      +  "pattern": "^[A-Za-z]{2}$",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

The readOnlyHint annotation only covers safety; the description goes much further by disclosing top-provider folding, the "Other" node, omission of zero cells, sums to total, the empty-window return shape, exclusion of platform moves from nodes/cells/total, and that the platform-move verdict is recomputed on every rollup cycle. It also explains country attribution fallback and dropping unattributable moves.

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 with its purpose and organized into logical blocks for matrix behavior, platform moves, and country behavior. It is dense and long, but most detail earns its place because there is no output schema and the result semantics are complex.

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?

With no output schema, the description carries the burden of explaining return semantics, and it does so thoroughly: pairs, total, other, platform, platform_by_provider, and country_share are all defined along with edge cases. It provides enough context for an agent to invoke the tool and interpret the result correctly.

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?

Schema coverage is already 100%, but the description adds substantial meaning: top controls how many providers keep identity on each side with others folded into "Other", country scopes the matrix using card country then ICD fallback and lengthens the window by one day, and country_share defaults to FR. It also notes that platform_by_provider is not limited by top.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Get moves between providers," and clarifies that it returns a from→to matrix of participants that changed Access Point provider in a trailing window. It is clear about scope and structure, but it does not explicitly differentiate itself from sibling tools such as list_cohort_moves or get_country_churn.

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

Usage Guidelines3/5

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

Usage is implied through the migration-matrix framing and the note that a net-growth chart uses platform_by_provider to remove platform moves. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative for related provider/country churn tools.

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