Skip to main content
Glama

Setup Linkedin Monitoring

setup_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 — pass members as their LinkedIn profile URLs or vanity slugs; 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. Kicks off the first run immediately, then runs on run_weekdays (default Mon/Thu, in the user's timezone). That 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/engager_icp/ comment_scope/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).

fetch_engagers has two optional companions, both handed to the woken new_post_engagers run on the event. engager_icp filters WHO is collected (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 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes'network' (1st-degree feed), 'list' (explicit people), 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 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 engagers are filtered by (ICP, titles, exclusions). Blank collects everyone. Only meaningful when fetch_engagers is on.
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).
comment_scopeNooptional — which post types are worth a drafted comment, in the user's words. Blank keeps the built-in criteria only.
draft_commentsNoqueue a drafted comment per discovered post.
fetch_engagersNocapture each post's engagers and wake this agent when new people engage.
engager_instructionsNooptional — what to do with captured engagers. 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. Changed5 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "description": "The agent this monitor lives on.",
      +  "type": "integer"
      +}
    • changedInput schema / properties / engager_instructions / description
      Previous value: -"optional — what to do with captured engagers. Blank\nmeans collect them into the task's Output list and take no action."New value: +"optional — what to do with captured engagers. Blank\nmeans collect them into the agent's Output list and take no action."
    • changedInput schema / properties / fetch_engagers / description
      Previous value: -"capture each post's engagers and wake this task when\nnew people engage."New value: +"capture each post's engagers and wake this agent when\nnew people engage."
    • removedInput schema / properties / task_id
      Removed value: -{
      -  "description": "The task this monitor lives on.",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "task_id",
      -  "name",
      -  "mode"
      -]New value: +[
      +  "agent_id",
      +  "name",
      +  "mode"
      +]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false secret; the description carries the full behavioral burden and exceeds it. It discloses that the first run starts immediately, that reusing a name updates and re-activates a monitor, that list discovery is cookieless, that auto-approval governs whether comments post, that a zero-balance list monitor won't run, and the full credit-cost model.

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 long but every sentence carries operational value; it is front-loaded with a summary and high-level behavior. It loses one point because the density and long paragraphs make it harder to scan quickly for an agent deciding among 13 parameters, and it could benefit from headings or bullets around modes, cost, and update semantics.

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 complex tool with 13 parameters, no output schema, and multiple modes, this description is remarkably complete. It covers mode differences, connection prerequisites, schedule and recency behavior, cost with a concrete example, update semantics, keyword query grammar, engager event behavior, and cross-tool routing. Nothing necessary for correct invocation is left to guesswork.

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?

Although schemas coverage is 100%, the description adds substantial meaning beyond the property descriptions: keyword boolean syntax and plan caps, recency_days max and cost implications, run_weekdays timezone rules, members re-setup semantics, and what blank engager_instructions does. This is precisely the guidance an agent needs to set parameters correctly.

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: 'Set up recurring LinkedIn post monitoring on an agent.' It immediately distinguishes itself from related tools like edit_monitor_members and stop_linkedin_monitoring by describing what setup does versus membership tweaks and by naming the sibling explicitly.

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?

The description gives explicit when-to-use and when-not-to-use guidance: use edit_monitor_members for membership tweaks, use setup's members only for initial membership or full reset, and it details mode-specific choice criteria for network/list/topic. It also states when LinkedIn must be connected versus when list mode works cookieless.

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