Skip to main content
Glama

Set up LinkedIn monitoring

set_up_linkedin_monitoring

An agent can host several named monitors. mode='network' watches the user's whole 1st-degree feed; mode='list' watches an explicit set of people and company pages — pass members as profile URLs or vanity slugs for people, and the full linkedin.com/company/... URL for a company page (a bare company name or slug is read as a person's slug); mode='topic' searches all of LinkedIn for posts matching keywords, beyond the user's network. Watching the user's own profile (their URL in members) is how a user gets engager capture on their own posts. writing_instructions steer the comment voice. An edit to an already-active list monitor waits for its next scheduled run, because every list run bills each watched profile; every other call kicks off a run immediately, so a new monitor or an edit shows results within minutes. After that it runs on run_weekdays (default Mon/Thu, in the user's timezone). The first run covers only the members present at creation, and edit_monitor_members starts no run — so create a list monitor with its complete membership in this one call (assemble a large or query-derived list in run_code and pass the whole variable), since members added afterward miss the backlog their first scheduled run would have caught. Comments land in the approval queue by default — they post without review only if the user has enabled auto-approve for the linkedin_comment subtype.

list mode works even when the user hasn't connected LinkedIn: discovery is cookieless and drafting never touches their session, so drafted comments hold in the approval queue and post once they connect. network/topic discover through the user's own LinkedIn session, so those two need it connected first.

Schedule and recency are per-monitor. run_weekdays is which days the monitor runs — weekday ints Mon=0 … Sun=6 in the user's local timezone (e.g. [3] = Thursdays only, [0,1,2,3,4] = every weekday). recency_days is how fresh a post must be to earn a drafted comment: only posts published within that many days are commented on (default 7, max 7). Set these when the user asks for a cadence ("once a week on Thursdays") or freshness rule ("only comment on posts from the last 3 days") — those are the knobs, not the agent goal text. A recency_days shorter than the gap between runs deliberately skips the older posts in that gap: narrow it for a user who wants only the freshest posts, or to trim a list monitor's per-post cost (see Cost — a shorter window pulls fewer posts, though the per-profile floor dominates a large list's cost). Leave it at the default week to comment on everything since the last run. Omitting run_weekdays, recency_days, or (on a list monitor) members on a re-setup keeps the monitor's current value; the other fields overwrite on every re-setup, so re-pass writing_instructions/draft_comments/fetch_engagers/capture_authors/ engager_icp/post_filter/engager_instructions when editing rather than dropping them. For membership tweaks (add or drop a few people) use edit_monitor_members — it takes only the changes, so you never re-echo the whole list (dropping a URL on the re-echo silently stops watching that person).

Cost: a queued drafted comment costs 1 credit (all modes). list mode additionally bills for the paid cookieless scraper's per-event usage (1 credit = $0.10): 0.04 credit per post it returns plus 0.02 credit per watched profile that posted nothing in the window — every watched profile is billed on every scheduled run whether or not it posted, so the per-profile floor (not the per-post charge) dominates a large list. That floor is a hard minimum: a run costs at least 0.02 × number of watched profiles (a silent profile exactly that, a posting one more), so a 2,000-profile list is ≥ 40 credits every scheduled day. Because that recurs per run, recommend a reduced cadence for a large list: the default is Mon/Thu, and for lists in the high hundreds or more, suggest weekly (run_weekdays=[0]). Other levers are trimming the member list; narrowing recency_days only trims the smaller per-post component. Flag this to the user when setting up a list monitor, especially a big one; a zero-balance list monitor won't run at all (even for engager capture). network/topic discovery is free (Unipile session). Engager capture bills 0.04 credits per reaction, comment or reply each fetch pulls, and pulls a post again once it's 5 days old, so its early engagers cost 0.08 credits each.

The capture actions share two optional companions, both handed to the woken new_post_engagers run on the event. engager_icp filters WHO is collected, engagers and authors alike (ICP, titles, exclusions); blank collects everyone. engager_instructions decides WHAT HAPPENS to them; blank means they are recorded into the agent's Output list and nothing else is done. Capture never sends outreach on its own — if the user wants a sequence or a connection request, it has to be spelled out in engager_instructions.

keywords is a LinkedIn boolean query. Combine topics with OR and quote multi-word phrases: "creator economy" OR "influencer marketing". AND narrows, NOT excludes, and parentheses group: ("seed" OR "series a") AND fundraising. Operators must be UPPERCASE (lowercase and/or/not are read as literal words). The combined AND+OR count is capped by the user's LinkedIn plan (free/premium 5, Sales Navigator 15, Recruiter unlimited; NOT doesn't count) — past the cap LinkedIn silently returns nothing, so cover many topics with several monitors each within the cap, not one giant OR. A single unquoted topic (fundraising) is fine. A malformed query (unbalanced quotes/parens, dangling operators) is rejected.

For network, leave keywords empty in almost all cases — the feed is already ranked and the per-post draft step skips anything not worth commenting on; set a narrow query only when the user wants one specific slice. list mode ignores keywords — it watches the named people's and pages' recent posts directly, and the draft step is the relevance gate. For mode='topic', keywords is required and is the only filter.

Reusing an existing name updates that monitor (and re-activates it if it was stopped) — this is also how you edit one. Prefer edit_monitor_members for a list monitor's membership; reserve setup's members for the monitor's full initial membership or a deliberate full reset. Dict with status ('active' or 'error'), name, message, and additional keys.

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": {
      "agent_id": "<agent_id>",
      "name": "<name>",
      "mode": "<mode>"
    },
    "name": "set_up_linkedin_monitoring"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYes'network' (1st-degree feed), 'list' (explicit people and company pages), or 'topic' (keyword search across all of LinkedIn).
nameYesshort label for this monitor (e.g. 'founders-i-follow').
membersNolist mode only — LinkedIn profile URLs/slugs and company page URLs to watch. Required when creating a list monitor; omit on a re-setup of an existing list monitor to keep its current members (use `edit_monitor_members` to add or drop individuals).
agent_idYesThe agent this monitor lives on.
keywordsNoa LinkedIn boolean query — required for topic mode, an optional relevance narrowing for network, ignored for list. Combine topics with OR (`"a" OR "b"`), AND to narrow, NOT to exclude; the AND+OR count is capped by the user's plan (see the keyword note above).
engager_icpNooptional — targeting criteria the collected people are filtered by (ICP, titles, exclusions). Blank collects everyone. Only meaningful when fetch_engagers or capture_authors is on.
post_filterNooptional — which posts the user wants, in their words (roles, topics, post types). Blank keeps every post. On a topic monitor posts are checked minutes after they go up, so a minimum-engagement rule sets most of them aside.
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
recency_daysNoonly comment on posts published within this many days (1–7, default 7). Omit to keep the current value.
run_weekdaysNowhich weekdays the monitor runs — ints Mon=0 … Sun=6 in the user's timezone (e.g. [3] = Thursdays only). Omit to keep the current value (default Mon/Thu on a new monitor).
draft_commentsNoqueue a drafted comment per discovered post.
fetch_engagersNocapture each post's engagers and wake this agent when new people engage.
capture_authorsNotopic mode only — capture the person who wrote each kept post and wake this agent when new authors are saved.
engager_instructionsNooptional — what to do with the captured people. Blank means collect them into the agent's Output list and take no action.
writing_instructionsNooptional voice/style guidance for the drafts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

With only readOnlyHint=false/destructiveHint=false supplied, the description carries the full burden and delivers: credit costs per action and per watched profile, the hard per-profile floor for large lists, that a zero-balance list monitor won't run, that list-mode edits defer to the next scheduled run while other calls run immediately, that reusing `name` updates/re-activates, that omitted fields persist while others overwrite, and that capture never sends outreach on its own.

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

Conciseness3/5

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

Front-loaded correctly and every section is substantive, but the prose is a single sprawling wall of text with visible redundancy — the per-profile cost floor is restated three times in the Cost paragraph, and the keyword operator cap is explained both here and in the schema. Paragraph breaks and tighter phrasing would preserve the information at half the length.

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 15-parameter tool with no output schema, the description plus the `<returns>` block leaves nothing an agent needs unstated: modes, prerequisites (LinkedIn connection per mode), billing, scheduling semantics, edit vs re-setup behavior, and the approval-queue default are all covered.

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%, yet the description adds substantial meaning: member URL vs slug formats and the bare-company-name trap, full boolean query syntax with plan-based operator caps and failure modes, run_weekdays encoding, the recency_days × cadence interaction, and the `engager_icp` (who) vs `engager_instructions` (what happens) distinction.

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 opening sentence gives a specific verb and resource ('Set up recurring LinkedIn post monitoring on an agent') and immediately decomposes the three modes and three independent per-post actions. It distinguishes itself from `edit_monitor_members`, `stop_linkedin_monitoring`, and `get_linkedin_monitors` by naming them and describing the division of labor.

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?

Explicitly states when to use each mode, when to leave `keywords` empty for network/list, when `keywords` is required (topic), when to prefer `edit_monitor_members` over re-passing `members`, and that 'all off' is a valid surface-only configuration. It also names the trigger conditions for non-default cadence and recency settings.

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