Skip to main content
Glama

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

Launch LinkedIn Campaign

li_launch_campaign
Destructive

Launch a created campaign. Two things happen: every already-connected prospect on it (startStage "message" — an inbound invitation you accepted, or anyone already 1st-degree) has their first message scheduled immediately — with NO check that the connection actually exists, so anyone whose invitation was not really accepted fails permanently at send time rather than waiting, and the first pending connection invite is enqueued. The worker drips later invites with humanized delays; the acceptance poller marks accepted invites, then post-acceptance messages auto-send sequentially with reply checks. THIS IS THE CONFIRM STEP for a batch ingested with launch:false — a campaign holding only already-connected people launches fine and returns messageStage.started, and no invite is ever sent to them.

MANY AT ONCE: pass campaignIds (up to 100) or namePrefix (+ sessionLabel to narrow it to one account) instead of campaignId. Without confirmLaunch it lists every matched campaign with its account, status, people and notStartedYet, and which would be refused; confirmed, each launches exactly as the single form, with its own ownership check and its own result line — one refusal does not stop the rest. A namePrefix launch also needs expectCount (the number the preview listed): without it the call only previews, and a different count refuses.

Input Schema

NameRequiredDescriptionDefault
sessionIdNoWith namePrefix only: match on this account only
campaignIdNoOne campaign id from li_list_campaigns. Or campaignIds / namePrefix.
namePrefixNoBulk: every campaign you can see whose name starts with this (case-insensitive, the same match as li_list_campaigns), at most 100; listed before anything is launched
campaignIdsNoBulk: up to 100 campaign ids, each launched as the single form would be
expectCountNoWith namePrefix only: the number of campaigns the preview listed. Required to confirm, so nothing is launched that the preview did not show.
sessionLabelNoWith namePrefix only: match on this account only
confirmLaunchYesMust be true to enqueue the first connection invite

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / campaignId / description
      Previous value: -"Campaign id from li_create_campaign or li_list_campaigns"New value: +"One campaign id from li_list_campaigns. Or campaignIds / namePrefix."
    • addedInput schema / properties / campaignId / minLength
      Added value: +1
    • addedInput schema / properties / campaignIds
      Added value: +{
+  "description": "Bulk: up to 100 campaign ids, each launched as the single form would be",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}
    • addedInput schema / properties / expectCount
      Added value: +{
+  "description": "With namePrefix only: the number of campaigns the preview listed. Required to confirm, so nothing is launched that the preview did not show.",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / namePrefix
      Added value: +{
+  "description": "Bulk: every campaign you can see whose name starts with this (case-insensitive, the same match as li_list_campaigns), at most 100; listed before anything is launched",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / sessionId
      Added value: +{
+  "description": "With namePrefix only: match on this account only",
+  "type": "string"
+}
    • addedInput schema / properties / sessionLabel
      Added value: +{
+  "description": "With namePrefix only: match on this account only",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "campaignId",
-  "confirmLaunch"
-]New value: +[
+  "confirmLaunch"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / campaignId / description
      Added value: +"Campaign id from li_create_campaign or li_list_campaigns"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructive/openWorld/idempotent annotations: no check that a connection exists so unaccepted invites fail permanently at send, worker drips invites with humanized delays, acceptance poller then auto-sends post-acceptance messages with reply checks, and bulk mode isolates failures per campaign. These are real operational consequences an agent must know before invoking.

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?

Front-loaded with the core action and the confirm-step framing, and nearly every sentence carries non-obvious information (failure modes, preview behavior, per-campaign isolation). It is long and dense with nested parentheticals and em-dash clauses, though, which slightly hurts scanability for a 7-param 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?

With no output schema, the description still tells the agent what comes back (preview listing account/status/people/notStartedYet/would-be-refused, and messageStage.started on a connected-only launch) and how partial refusals surface. For a tool this complex, nothing material is missing.

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 interaction semantics the schema cannot express: campaignIds/namePrefix/sessionLabel mutual roles, the expectCount anti-drift guard, and confirmLaunch as the preview-vs-launch switch. Some of this (sessionLabel/namePrefix pairing) duplicates the schema wording, so not a full 5.

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?

Opens with a specific verb+resource ("Launch a created campaign") and immediately frames itself as the confirm step for batches ingested with launch:false, which distinguishes it from li_create_campaign, li_ingest_prospects and li_pause_campaign/resume_campaign without needing the schema. It also covers the bulk form 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?

States precisely when to use it ("THE CONFIRM STEP for a batch ingested with launch:false"), when a campaign with only connected prospects works, when to switch to campaignIds/namePrefix/sessionLabel, and that namePrefix requires expectCount matching the preview. Exclusions (what happens without confirmLaunch) are explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All PoliteReach toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources