Skip to main content
Glama

Metadata MCP Connector

Create Audience from Segment

create_audience_from_segment

Create a dynamic Insights Retargeting audience from a saved Insights (Spotlight) segment: the companies matching the segment inside a lookback window, refreshed automatically as the journey data changes.

TWO VARIANTS (audience_type):

  • "contacts" (default): Insights Retargeting Contacts, platform type WEBSITE_RETARGETING. Contacts at the matching accounts, matched through the Metadata contact graph; usable on LinkedIn, Facebook, Instagram, X and Reddit.

  • "accounts": Insights Retargeting Accounts, platform type WEBSITE_ACCOUNT_RETARGETING. The matching COMPANIES pushed to LinkedIn as a matched company audience; LinkedIn only. The shape for account-level INCLUSION or EXCLUSION on LinkedIn, e.g. suppressing accounts that already received 200+ impressions from a sequenced program.

WHEN: behaviour- or CRM-state-based retargeting and suppression ("retarget accounts that visited pricing", "exclude accounts we already saturated", "high engagement score not in the CRM"). NOT for firmographic / technographic / intent asks (use those audience tools), and NOT for LinkedIn ad-engagement retargeting (create_linkedin_engagement_retargeting_audience works off LinkedIn's own engagement signals; this one works off the Spotlight journey: website visits, impressions, clicks, scores, CRM state).

WORKFLOW (each step is checked and a failure is refused with the reason):

  1. list_segments, then get_segment_criteria(segment_id, lookback_window): the segment must exist, be READY, and match at least one account in the window. A segment matching 0 accounts is refused (widen the window, or create_segment with looser criteria).

  2. lookback_window in days (1 to 365): the window the segment's metrics are evaluated over ("in the last 90 days" = 90).

  3. Call this tool with a descriptive name. The audience appears in the library as "Insights Retargeting Contacts (Dynamic)" or "Insights Retargeting Accounts (Dynamic)".

RETURNS: {success, id, audience_id, audience_name, status, audience_type, platform_audience_type, segment_id, segment_name, lookback_window, accounts_in_window, channels, expectedNumberOfCompanies, expectedNumberOfContacts, criteria}. Member matching is asynchronous: -1 or 0 right after creation means "not matched yet"; check again later with get_deep_audience_details.

USED AS AN EXCLUSION: Ann attaches it through add_and_edit_campaign_elements (exclude_audiences) on the campaign that must not reach those accounts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the new audience. Unique and descriptive, e.g. 'Exclude: 200+ LinkedIn impressions, 90d'.
segment_idYesThe id of a READY segment from list_segments / create_segment.
audience_typeNocontacts (default): people at the matching accounts, multi-channel. accounts: the matching companies as a LinkedIn matched audience, LinkedIn only; use it for account-level LinkedIn exclusions.
lookback_windowYesDays the segment is evaluated over. Range 1 to 365. 30 for the last month, 90 for the last quarter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already mark it as a non-read, non-destructive operation; the description adds useful behavioral detail by describing a checked workflow that fails with a reason and a RETURNS section. No contradiction with annotations.

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

Conciseness2/5

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

Organized into sections, but substantially overlong and repetitive; a shorter description would serve an agent better.

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?

Covers variants, when to use, workflow/failure behavior, returns, and exclusion usage. With no output schema, the RETURNS section helps fill the gap. Slightly too noisy to merit a 5.

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?

The input schema already documents all parameters with descriptions (100% coverage), so the description adds little beyond what the schema provides; baseline 3 is appropriate.

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?

States a specific verb and resource ('Create an Audience from a Segment') and explains the two audience_type variants. It does not explicitly contrast with sibling create_*_audience tools, so it falls short of a 5.

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?

Provides a dedicated WHEN section and a USED AS AN EXCLUSION note, giving an agent explicit context for when to invoke it. It does not name an alternative sibling tool, so not a 5.

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