Skip to main content
Glama

Rename A Campaign, Change Its ICP, Or Make It Priority

li_edit_campaign
Idempotent

Change a running campaign's NAME, its ICP label, or its invite PRIORITY — the same edit as on the dashboard, in our database only.

PRIORITY (priority: true) sends this campaign's invites before every non-priority campaign on the same LinkedIn account: the others wait while it has anyone it may invite now, and resume within about an hour once it runs out. Several priority campaigns on one account take turns. It only reorders that account's invites — caps, sending hours and pacing are unchanged, and messages/follow-ups are unaffected. Set it only when the user asks for a campaign to go first; priority: false puts it back in turn.

⚠️ A RENAME CHANGES WHAT A BY-NAME IMPORT FINDS. li_ingest_prospects matches a managed campaign on its EXACT name, so once this is renamed an import still saying the old name will CREATE A SECOND CAMPAIGN rather than adding to this one. The reply says so, and names the new name. Pass campaignId to li_ingest_prospects instead and the name stops mattering.

TWO THINGS IT REFUSES, in words rather than silently: • THE STRATEGY, once the campaign holds anybody. Every prospect carries their OWN copy of the message text and delays, taken when they were imported — so repointing the strategy would change nothing for the people already in it and silently change every future import. That is two behaviours under one word, and a success here would read as "everyone's cadence is fixed". To change copy that is already queued, that is li_bulk_edit_steps (one sentence across the whole campaign) or li_edit_step (per person). On an EMPTY campaign nothing is snapshotted yet, so the strategy IS changeable and the reply says what it applies to. EXCEPTION: while every member is still untouched (no invite sent, no step sent or scheduled), resnapshot=true changes it AND re-copies everyone's step kinds and delays from the new strategy, keeping their own text; a person with no text for a new step kind is named unless stepTexts supplies it. dryRun previews. • THE SENDING ACCOUNT, always. A campaign is bound to the LinkedIn identity that is mid-conversation with its prospects; moving it would have a stranger send the next message. Create a campaign on the other account instead, or move people with li_move_contact.

Pass icpId: null to clear the ICP. Omitted fields are left exactly as they are — a call that renames does not clear the ICP as a side effect. Get the id from li_list_campaigns.

Input Schema

NameRequiredDescriptionDefault
nameNoA new name, up to 200 characters. Trimmed, because a by-name import trims what it is given — storing "Foo " would make an ingest for it quietly create a second campaign.
icpIdNoA new ICP from li_list_icps, or null to clear it. OMITTED leaves it alone — null and omitted are not the same thing here.
dryRunNoWith resnapshot: preview who would be re-copied, write nothing.
priorityNotrue = send this campaign's invites before every non-priority campaign on its LinkedIn account (they wait while it has anyone to invite); false = take turns again. Only when the user asks. It reorders invites only: it NEVER raises a daily or weekly cap and never changes sending hours or messages. Omitted leaves it alone.
sessionIdNoAccepted only so moving a campaign between accounts is refused in words.
stepTextsNoPer-person text for step kinds a person has no text for under the new strategy (or to replace theirs). Implies resnapshot. Text is never invented: a person missing text for a new step is named and nothing is written.
campaignIdYesFrom li_list_campaigns
resnapshotNoRe-copy every member's step kinds and delays from strategyId (or, without one, from the campaign's own strategy), keeping each person's own text. Only while EVERY member is untouched: invite not sent, no step sent or scheduled, nothing launched for them. Otherwise refused, naming who. Writes nothing on refusal.
strategyIdNoA new strategy. On an EMPTY campaign it simply applies. On one holding people it is refused unless resnapshot=true.
sessionLabelNoAccepted only so moving a campaign between accounts is refused in words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / dryRun
      Added value: +{
      +  "description": "With resnapshot: preview who would be re-copied, write nothing.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / resnapshot
      Added value: +{
      +  "description": "Re-copy every member's step kinds and delays from strategyId (or, without one, from the campaign's own strategy), keeping each person's own text. Only while EVERY member is untouched: invite not sent, no step sent or scheduled, nothing launched for them. Otherwise refused, naming who. Writes nothing on refusal.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / stepTexts
      Added value: +{
      +  "description": "Per-person text for step kinds a person has no text for under the new strategy (or to replace theirs). Implies resnapshot. Text is never invented: a person missing text for a new step is named and nothing is written.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "closer": {
      +        "description": "Text for the \"closer\" step",
      +        "maxLength": 8000,
      +        "type": "string"
      +      },
      +      "firstMessage": {
      +        "description": "Text for the \"first\" step",
      +        "maxLength": 8000,
      +        "type": "string"
      +      },
      +      "followUp1": {
      +        "description": "Text for the \"followup_1\" step",
      +        "maxLength": 8000,
      +        "type": "string"
      +      },
      +      "followUp2": {
      +        "description": "Text for the \"followup_2\" step",
      +        "maxLength": 8000,
      +        "type": "string"
      +      },
      +      "followUp3": {
      +        "description": "Text for the \"followup_3\" step",
      +        "maxLength": 8000,
      +        "type": "string"
      +      },
      +      "profileUrl": {
      +        "description": "The person, as stored or as any spelling of them",
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "profileUrl"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 500,
      +  "type": "array"
      +}
    • changedInput schema / properties / strategyId / description
      Previous value: -"Accepted so it can be REFUSED with the reason, rather than dropped as an unknown key. Allowed only while the campaign still holds nobody."New value: +"A new strategy. On an EMPTY campaign it simply applies. On one holding people it is refused unless resnapshot=true."
  2. Changed1 schema field changed
    • addedInput schema / properties / priority
      Added value: +{
      +  "description": "true = send this campaign's invites before every non-priority campaign on its LinkedIn account (they wait while it has anyone to invite); false = take turns again. Only when the user asks. It reorders invites only: it NEVER raises a daily or weekly cap and never changes sending hours or messages. Omitted leaves it alone.",
      +  "type": "boolean"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give the safety profile (readOnly=false, destructive=false, idempotent=true); the description adds far more: two hard refusals with reasoning, the rename→by-name-import side effect that creates duplicate campaigns, priority's in-place invite reordering without touching caps, and dryRun/resnapshot semantics. This is exactly the behavioral context annotations cannot carry.

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?

Primary purpose and priority semantics are front-loaded, and the warnings/refusals are grouped with bullet-like structure. It is long and dense, but nearly every sentence carries non-obvious operational detail; only slight trimming seems possible.

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 multi-field mutation tool with no output schema and 10 parameters, the description covers refusals, side effects, preview behavior, resnapshot preconditions, and where to get the id. Nothing an agent needs to call it safely appears 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 baseline is 3, but the description adds real meaning: icpId null-vs-omitted distinction, priority's precise effect, and that sessionId/sessionLabel are accepted only so account-move attempts can be refused in words. It goes beyond restating the schema descriptions.

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 ("change a running campaign's NAME, its ICP label, or its invite PRIORITY") and immediately distinguishes itself from near-siblings li_bulk_edit_steps, li_edit_step, li_create_campaign and li_move_contact. An agent can identify the scope without opening the 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?

Explicitly states when to set priority ("only when the user asks for a campaign to go first"), when not, and names the alternative tools for cases it refuses (li_bulk_edit_steps, li_edit_step, li_move_contact, and li_ingest_prospects with campaignId). The empty-vs-populated campaign branching is spelled out.

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