Skip to main content
Glama
This connector has been deprecated

Replaced by io.github.no-fait/infinite-audience

Refresh Audience

refresh_audience
Destructive

Refresh one named member segment of an audience against the current IAG, then refresh the audience's own version/expiry. An audience is a composition of one or more member segments, possibly of different subtypes — there is no "primary" segment, so segment_id is required (400 SEGMENT_ID_REQUIRED if omitted, 400 SEGMENT_NOT_A_MEMBER if it is not part of this audience). Behaviour is specific to the chosen segment's subtype:

  • filter: synchronous — returns status: active immediately. record_count is null; call recount_audience if a fresh count is needed before quoting.

  • matched: with hitl false/unset (default): returns status: pending + upload_url. Instruct the user to upload their identity list to upload_url (same or updated file). After upload, call wait_for_segment(segment_id) to block until identity resolution completes. With hitl: true: the upload is staged instead — follow the analyze_audience_upload -> confirm_column_mappings / cancel_matched_upload -> wait_for_segment sequence documented on create_segment(subtype=matched) (confirm_column_mappings/cancel_matched_upload take this segment_id, not audience_id).

  • custom: immutable snapshot; returns 409 CUSTOM_REGENERATION_REQUIRED. Request a new internal data-team publication. Always call get_audience first to see the member segments and their subtypes, so you can pick (or have the user pick) the right segment_id. Async build completion or failure may notify configured external webhooks and opted-in users by email. Requires 'creator' scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "audience_id": "<audience_id>",
      "segment_id": "<segment_id>"
    },
    "name": "refresh_audience"
  }
}

Input Schema

NameRequiredDescriptionDefault
hitlNoIf true: stages a matched segment's re-upload instead of resolving automatically. Defaults to false.
segment_idYesWhich member segment of this audience to refresh. Required — there is no default/primary segment.
audience_idYesThe audience ID to refresh
compressionNoMatched subtype: replacement upload compression.none
shard_countNoMatched subtype: number of same-format shards. Every CSV shard must include its own header row.

Output Schema

NameRequiredDescriptionDefault
statusYes
subtypeYes
versionYes
guidanceNoInterpretation or recovery guidance for this result
next_stepYes
refreshedYes
count_unitNo
page_countNoNumber of objects on this page, not the organization total
segment_idYes
upload_urlNo
audience_idYes
count_stateNoUnknown means no count; available does not guarantee freshness. Recount for a current value.
upload_urlsNo
next_actionsNoSuggested next calls using returned IDs and available scopes. Not executed and not user consent.
workflow_run_idNo
population_inputNoPopulation input used for the preview; IDs refer to their current saved definitions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive/non-idempotent/open-world, and the description goes well beyond them: it discloses sync vs. async outcomes per subtype, the pending + upload_url return shape, specific failure codes (400 SEGMENT_ID_REQUIRED, 400 SEGMENT_NOT_A_MEMBER, 409 CUSTOM_REGENERATION_REQUIRED), that the upload may be the same or an updated file, webhook/email notifications, and the 'creator' scope requirement.

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 action and its cross-cutting constraints are front-loaded, then behavior is cleanly bulleted by subtype, which makes a long description easy to scan. It is dense rather than wasteful, though the subtype bullets pack several tool-name chains each, making it longer than strictly needed to select and invoke the tool.

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 five parameters, a mutation with destructive semantics, an output schema, and a branching workflow by segment subtype, the description covers everything an agent needs to call it correctly: prerequisites, ordering of follow-up calls, error cases, and the one subtype that must not be called at all.

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 coverage is 100%, so the baseline is 3, and the description adds real meaning on top: it explains why segment_id has no default (audiences are multi-segment compositions with no primary), and it explains what hitl actually changes (staging a matched re-upload rather than resolving automatically). It does not mention compression or shard_count at all, leaving those entirely to the schema.

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 first sentence names a specific verb and resource with precise scope: refreshing one named member segment against the current IAG and then the audience's own version/expiry. It explicitly disambiguates the required segment_id by stating there is no 'primary' segment, which prevents the most likely misuse of this tool versus the segment-level siblings.

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?

It prescribes the prerequisite ('Always call get_audience first') and then gives per-subtype when-to-use rules: filter is synchronous and needs recount_audience for a fresh count, matched requires the upload -> wait_for_segment sequence (or the staged hitl path via analyze_audience_upload/confirm_column_mappings/cancel_matched_upload), and custom is refused outright with the alternative (request a new data-team publication). Explicit alternative tools and conditions are named throughout.

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