PoliteReach

Pause a Campaign

li_pause_campaign

Idempotent

Stop a campaign sending, reversibly. No further invites go out from it, and an invite job already queued for it stops rather than passing the baton to the next person — so a drip that is running is genuinely held, not merely slowed. Reach for this the moment prospects are in a campaign you did not mean, instead of stopping people one at a time. The reply says HOW MANY it held, because a pause that reports only success reads the same whether it caught a hundred people or nobody. Two things it does NOT do: a message step already scheduled still sends (hold those with li_cancel_steps, which leaves the sequence alive — NOT li_mark_stopped, which hands the contact off permanently), and acceptance polling stops for this campaign, so somebody who accepts while it is paused is not noticed until it resumes. Reverse it with li_resume_campaign.

MANY AT ONCE: campaignIds (up to 100) or namePrefix (+ sessionLabel for one account) instead of campaignId. Without confirm:true it only lists what matched, with counts; confirmed, each campaign is paused with its own ownership check and result line.

Input Schema

Name	Required	Description
`confirm`	No	Bulk forms only: true to act. Without it the call lists what matched.
`sessionId`	No	With namePrefix only: match on this account only
`campaignId`	No	One campaign id from li_list_campaigns. Or campaignIds / namePrefix.
`namePrefix`	No	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 paused
`campaignIds`	No	Bulk: up to 100 campaign ids, each paused as the single form would be
`sessionLabel`	No	With namePrefix only: match on this account only

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 14, 2026

changedInput schema / properties / campaignId / description

Previous value: -"Campaign id from 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 paused as the single form would be",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / confirm

Added value: +{
+  "description": "Bulk forms only: true to act. Without it the call lists what matched.",
+  "type": "boolean"
+}

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 paused",
+  "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"
+}

removedInput schema / required
```
Removed value: -[
-  "campaignId"
-]
```

Changed1 schema field changedOct 4, 2026
- addedInput schema / properties / campaignId / description
```
Added value: +"Campaign id from li_list_campaigns"
```
First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description still adds non-obvious behavior: a queued invite job is halted mid-sequence, an already-scheduled message step still sends, and acceptance polling stops for the campaign until resume. It doesn't cover auth/permission requirements or rate limits, which keeps it short of a 5.

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?

Long but front-loaded and well partitioned, with the MANY AT ONCE block separating the bulk form. Some phrasing is stylistic overhead ('passing the baton to the next person'), which is the only thing keeping it from a 5.

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?

No output schema, but the description covers the return shape ('the reply says HOW MANY it held') and the bulk listing/acting distinction. Combined with the behavior caveats and the reversal path, an agent has everything needed to call it correctly.

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; the description earns above that by explaining the mutually exclusive addressing modes (single campaignId vs campaignIds up to 100 vs namePrefix + sessionLabel scoped to one account) and that confirm:true is what turns a listing into an action. That is meaning the schema alone does not convey.

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?

States a specific verb and resource ('Stop a campaign sending, reversibly') and immediately scopes it against siblings: li_cancel_steps for scheduled message steps, li_mark_stopped as the permanent alternative, li_resume_campaign as the inverse. An agent can pick this apart from li_pause_account and li_hold_sending without opening a schema.

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?

Gives an explicit trigger ('the moment prospects are in a campaign you did not mean, instead of stopping people one at a time') plus two explicit exclusions with named alternatives. The bulk section adds a second usage mode (campaignIds/namePrefix) with the confirm:true gating rule spelled out.

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

All PoliteReach tools Inspect

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

Need Help?