Skip to main content
Glama

Metadata MCP Connector

Search LinkedIn Engagement Sources

search_linkedin_engagement_sources
Read-only

Find which LinkedIn campaigns or pages to retarget, for a chosen engagement source type. STEP 2 of the LinkedIn Engagement Retargeting flow.

            Each result's `id` is the LinkedIn URN to pass as `engagement_source_urns` to
            create_linkedin_engagement_retargeting_audience. The audience will contain people who
            engaged with the sources you select, so this choice determines who is in it.

            REQUIRED FIRST: call get_linkedin_engagement_source_types and pick an
            `engagementSourceType` plus an `engagementTrigger`.

            **ALWAYS PASS engagement_trigger AND lookback_window_days TOGETHER.** With both, every
            candidate carries `engagementCount`, the volume of engagement behind it, sorted
            highest-first — which is the only way to tell which sources are worth retargeting.
            Without the pair the platform returns no counts and the order is not meaningful.
            Use the same trigger and lookback you intend to create the audience with, or the
            numbers describe a different audience than the one you are about to build.

            DO NOT CALL THIS FOR THE WEBSITE SOURCE TYPE. Website retargeting is defined by URL
            match rules, not by picking sources, and this tool refuses it. Go straight to the
            create tool with `page_set_name` and `url_match_groups`.

            READING THE RESULTS:
            - `id` — the LinkedIn URN (e.g. `urn:li:sponsoredCampaign:743409464`). Pass it
              verbatim. It is NOT the numeric campaign id and must never be reconstructed.
            - `name` — the campaign or page name, for telling the user what you picked.
            - `engagementCount` — how many engagements that source drew under the trigger and
              lookback you passed. Absent when you did not pass both.
            - `engagementMetricLabel` / `engagementMetric` — WHAT was counted, which follows the
              trigger: "Total Engagement" for an any-interaction trigger, "Opens" for a
              conversation open, clicks for a chargeable-click one. Quote this label when you
              report numbers, so "1,200 opens" is not reported as impressions.
            - `status` — the campaign's state. `PENDING_DELETION` campaigns still appear and are
              still valid engagement history, but prefer live ones when both have volume.
              ORGANIZATION_PAGES candidates carry no status; that is normal, not missing data.

            HOW TO CHOOSE:
            - Prefer sources with real `engagementCount`. A source with 0 builds an audience
              that will stay empty however long LinkedIn is given.
            - Selecting several sources is normal and usually right: the audience is the UNION of
              everyone who engaged with any of them, so more sources means more reach.
            - IF EVERY CANDIDATE SHOWS 0, do not silently build from all of them. That means the
              account has no engagement of this kind in the window. Say so, and offer the real
              options: a longer lookback, a shallower trigger, a different source type, or
              waiting until campaigns have run. Building anyway produces an empty audience the
              user will believe is populated.
            - Only the top `limit` results come back, not the whole account. Narrow with `search`
              rather than assuming the list is complete.

            WHEN TO USE:
            - After picking a source type, to find what can be retargeted
            - "Which of my video campaigns got the most engagement?"
            - "Find my lead gen form campaigns"
            - To resolve a campaign the user named to its URN, via `search`

            PARAMETERS:
            - engagement_source_type: an `engagementSourceType` from step 1 (required).
              WEBSITE is not valid here.
            - engagement_trigger: a trigger valid for that source type. Pass it WITH
              lookback_window_days to get engagement counts and a meaningful order.
            - lookback_window_days: 30, 60, 90, 180 or 365. Pairs with engagement_trigger.
            - search: narrow by name, case-insensitive substring. Use it when the user named a
              campaign, or when the account has many campaigns.
            - limit: how many to return (default 12, max 100).

            RETURNS:
            - sources[]: the candidates, as described above
            - engagementMetricLabel: what the counts measure
            - count: how many came back
            - next_step: which tool to call next

            IMPORTANT NOTES:
            - ORGANIZATION_PAGES returns exactly one candidate, the account's own company page.
              That is the whole result set, not a truncated one.
            - An empty `sources` list means the account has nothing of that type. Report that and
              suggest a different source type rather than retrying the same call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many candidates to return. Default 12, max 100. Results are the TOP N by engagement, not the whole account.
searchNoNarrow candidates by name (case-insensitive substring). Use when the user named a specific campaign, or when the account has more campaigns than `limit`.
engagement_triggerNoAn `engagementTrigger` valid for this source type. Pass together with lookback_window_days to get `engagementCount` per candidate, sorted highest-first. Use the same trigger you will create the audience with.
lookback_window_daysNoWindow the engagement counts are measured over. Pass together with engagement_trigger, and use the same value you will create the audience with.
engagement_source_typeYesAn `engagementSourceType` from get_linkedin_engagement_source_types (e.g. VIDEO_ADS, SINGLE_IMAGE_ADS, DOCUMENT_ADS, CONVERSATION_ADS, LEAD_GEN_FORMS, ORGANIZATION_PAGES). WEBSITE is not valid here — it has no sources to pick.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, the description discloses meaningful behaviors: the tool refuses WEBSITE, returns only the top `limit` results, omits `engagementCount` when trigger/lookback are not paired, returns exactly one candidate for ORGANIZATION_PAGES, and treats empty sources as a real absence of engagement data. Nothing contradicts the annotations.

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 long but well-organized with clear headings, scannable bullets, and front-loaded constraints. Every section contributes operational guidance rather than restating boilerplate, and the length is justified by the number of edge cases an agent must get right.

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 fully compensates by documenting each result field, explaining edge cases like PENDING_DELETION and ORGANIZATION_PAGES, and naming the `next_step` tool. Nothing needed to call the tool correctly is missing.

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?

Even with 100% schema coverage, the description adds critical semantics the schema cannot convey: the two-parameter pairing requirement, URN vs numeric id distinction, WEBSITE invalidity, and the intended use of `search` when a user names a campaign. This goes well beyond baseline schema documentation.

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: 'Find which LinkedIn campaigns or pages to retarget, for a chosen engagement source type' and positions it as STEP 2 of an explicit flow. It also names the adjacent create_linkedin_engagement_retargeting_audience tool, so an agent can distinguish this search step from the audience-creation step.

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 explicitly says to call get_linkedin_engagement_source_types first, gives concrete query examples, and states a hard exclusion: DO NOT CALL THIS FOR THE WEBSITE SOURCE TYPE, routing instead to the create tool. It also instructs the agent to use the same trigger/lookback as the audience it will build and how to handle all-zero results.

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