PoliteReach

List Campaigns

li_list_campaigns

Read-only

Every campaign you can see, newest first — its id, name, status, sending account, strategy, ICP, contact count, priority (true = its invites go before the account's other campaigns) and state (whether it is really sending, and why not). START HERE: li_campaign_status and li_campaign_contacts both need a campaignId, and this is what hands you one.

FILTERS run over every campaign before the page is cut: status ("active", "paused", "completed"), namePrefix (case-insensitive), sessionLabel/sessionId (sending account), minContacts/maxContacts (people in it). PAGED: the reply carries totalMatching, truncated and nextOffset (pass it as offset); a filtered empty page says how many campaigns exist without the filters. fields keeps only the named columns (campaignId always). format: "csv" returns the rows as one CSV string (csv + columns) instead of campaigns. DB-backed and instant.

Input Schema

Name	Required	Description
`limit`	No	Default 50
`fields`	No	Only these columns per row (campaignId is always kept). Omit for every column.
`format`	No	"csv" = one header + rows string instead of the `campaigns` array
`offset`	No	Skip this many matching campaigns — pass the last reply's `nextOffset`
`status`	No	Only campaigns in this status, e.g. "active"
`sessionId`	No	Limit to one account by id (li_list_accounts). Omit to cover every account you can see.
`namePrefix`	No	Only campaigns whose name starts with this (case-insensitive)
`maxContacts`	No	Only campaigns holding at most this many people (0 = empty ones)
`minContacts`	No	Only campaigns holding at least this many people
`sessionLabel`	No	Limit to one account by label, LinkedIn name, profile slug or member id. Omit to cover every account you can see.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 14, 2026

addedInput schema / properties / fields

Added value: +{
+  "description": "Only these columns per row (campaignId is always kept). Omit for every column.",
+  "items": {
+    "enum": [
+      "name",
+      "status",
+      "accountId",
+      "accountLabel",
+      "strategyName",
+      "icpName",
+      "contactCount",
+      "launchedAt",
+      "priority",
+      "createdAt",
+      "state"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / format

Added value: +{
+  "description": "\"csv\" = one header + rows string instead of the `campaigns` array",
+  "enum": [
+    "json",
+    "csv"
+  ],
+  "type": "string"
+}

addedInput schema / properties / maxContacts

Added value: +{
+  "description": "Only campaigns holding at most this many people (0 = empty ones)",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / minContacts

Added value: +{
+  "description": "Only campaigns holding at least this many people",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / namePrefix

Added value: +{
+  "description": "Only campaigns whose name starts with this (case-insensitive)",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Skip this many matching campaigns — pass the last reply's `nextOffset`",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / sessionId

Added value: +{
+  "description": "Limit to one account by id (li_list_accounts). Omit to cover every account you can see.",
+  "type": "string"
+}

addedInput schema / properties / sessionLabel

Added value: +{
+  "description": "Limit to one account by label, LinkedIn name, profile slug or member id. Omit to cover every account you can see.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, non-destructive, closed-world), but the description adds real behavioral context: filters apply over the whole set before the page is cut, the reply carries totalMatching/truncated/nextOffset, an empty filtered page reports the unfiltered count, and the operation is 'DB-backed and instant'. This is well beyond annotation coverage.

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?

Dense but well organized into purpose, filters/paging, fields/format, and a closing performance note, with the most important routing advice ('START HERE') front-loaded. Every sentence carries information an agent needs; nothing is filler.

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 itself documents the return shape (campaigns rows with named columns, or csv+columns), pagination metadata, and the empty-page edge case. Combined with annotations and a fully described 10-param schema, an agent has everything needed to call and interpret this tool.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: filters run before pagination, nextOffset should be passed back as offset, fields always retains campaignId, and format=csv swaps the campaigns array for a csv+columns pair. Some items (case-insensitive namePrefix) merely restate the schema, keeping this just short of a 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 ('Every campaign you can see, newest first') and enumerates the returned columns, so an agent knows exactly what this tool yields. It explicitly distinguishes itself from siblings by naming li_campaign_status and li_campaign_contacts as downstream consumers that need the campaignId this tool produces.

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 'START HERE' directive states when to use this tool relative to named alternatives, and explains that both sibling tools depend on a campaignId obtained here. It also describes the filter/pagination strategy so the agent knows how to narrow results rather than paginate blindly.

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?