Skip to main content
Glama

campaignstack

by io.campaignstack
OverviewDiscussionsAdmin

campaignstack_like_post

Destructive

Ask CampaignStack to like a lead's most recent post from a connected LinkedIn account, as a light way to be seen before writing. Call this when the user asks to like or engage with a specific lead's post before an outreach step. platform is required (currently "linkedin"). Name the person with leadId, which is the supported form; profileUrl is accepted for someone already in the workspace. The workspace's only connected LinkedIn account is used automatically, or pass accountId (campaignstack_get_accounts). A like is public and puts a notification on that person's account under the owner's name. It does not comment; use campaignstack_comment_on_post for that. This reaches a real person. Before calling it, tell the user exactly who it goes to and read the wording back to them, and wait for an explicit yes. One person per call. There is no bulk form, and calling this in a loop over a list is not the supported way to reach a list: add the leads with campaignstack_edit_lead_list and run a workflow over it with campaignstack_trigger_workflow, which paces the sends and applies the review step the workspace configured. Sending is paced by CampaignStack's own daily and weekly limits and business hours, which are set by a human in the app and are not writable from here; see overrideOwnLimits before asking for an exception.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leadIdNo
platformYes
accountIdNo
profileUrlNo
workspaceIdNoWorkspace ID. Omit it when this connection reaches one workspace: a workspace key (cs_) is bound to its own, and a user key (csu_) or connected app whose person belongs to exactly one workspace defaults to that one. Required only when the person belongs to several; the error then lists them, and campaignstack_whoami reports them too.
overrideOwnLimitsNoTells CampaignStack to skip its OWN protective pacing for this one call: the daily budget, the weekly cap, the business-hours window, the account status check and the risk pause. These are limits CampaignStack sets to keep the account healthy. They are not LinkedIn's controls, and nothing here touches, negotiates with or works around anything LinkedIn enforces. LinkedIn's own measured ceiling is a separate check that is never overridable, and neither is a pause the account's owner set. Default false, and it should stay false. Setting it true voids the safety guarantee: from that call on, CampaignStack can no longer promise the pacing that keeps the account out of trouble, and the risk of a restriction sits with the owner. Every use is recorded in the workspace audit log. Ask the owner in plain words and get an explicit yes first. A refusal from the safety system is that system working, not a fault to route around: report the reason and let the person decide, and never retry the same send with this set.
dangerouslyBypassSafetySystemNoDeprecated name for overrideOwnLimits. Use overrideOwnLimits.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdNo
statusNo
successNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "Workspace ID. Omit it when this connection reaches one workspace: a workspace key (cs_) is bound to its own, and a user key (csu_) or connected app whose person belongs to exactly one workspace defaults to that one. Required only when the person belongs to several; the error then lists them, and campaignstack_whoami reports them too.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "jobId": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "status": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "success": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "boolean"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}
  3. Changed9 schema fields changed
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / accountId
      Added value: +{
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / dangerouslyBypassSafetySystem
      Added value: +{
+  "description": "Deprecated name for overrideOwnLimits. Use overrideOwnLimits.",
+  "type": "boolean"
+}
    • addedInput schema / properties / leadId
      Added value: +{
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / overrideOwnLimits
      Added value: +{
+  "description": "Tells CampaignStack to skip its OWN protective pacing for this one call: the daily budget, the weekly cap, the business-hours window, the account status check and the risk pause. These are limits CampaignStack sets to keep the account healthy. They are not LinkedIn's controls, and nothing here touches, negotiates with or works around anything LinkedIn enforces. LinkedIn's own measured ceiling is a separate check that is never overridable, and neither is a pause the account's owner set. Default false, and it should stay false. Setting it true voids the safety guarantee: from that call on, CampaignStack can no longer promise the pacing that keeps the account out of trouble, and the risk of a restriction sits with the owner. Every use is recorded in the workspace audit log. Ask the owner in plain words and get an explicit yes first. A refusal from the safety system is that system working, not a fault to route around: report the reason and let the person decide, and never retry the same send with this set.",
+  "type": "boolean"
+}
    • addedInput schema / properties / platform
      Added value: +{
+  "enum": [
+    "linkedin"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / profileUrl
      Added value: +{
+  "format": "uri",
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "platform"
+]
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds what the annotations convey. It discloses that the like is public, puts a notification on the person's account under the owner's name, reaches a real person, is paced by human-set daily/weekly limits and business hours, is audited, and requires explicit user confirmation before sending. This is exactly the extra context destructiveHint/openWorldHint alone cannot provide.

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-loads the core action and remains organized, with the risk/limit material grouped at the end. It is longer than typical and carries some repetition about confirmation and limits, but for a destructive, open-world mutation each clause largely earns its place.

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?

Covers purpose, selection rationale, required confirmation flow, pacing/limit behavior, and the bulk-workflow alternative; an output schema exists so return values need not be described. Nothing an agent needs to invoke this safely 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?

With only 43% schema coverage, the description compensates by explaining platform requirement ('currently linkedin'), that leadId is the supported identifier, that profileUrl is accepted for someone already in the workspace, and that accountId comes from campaignstack_get_accounts. It does not clarify workspaceId beyond what the schema already documents, so it is not fully complete.

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 — 'like a lead's most recent post from a connected LinkedIn account' — and immediately distinguishes it from the sibling comment tool ('It does not comment; use campaignstack_comment_on_post for that'). An agent can select this over comment_on_post and follow_profile 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 explicit when-to-use ('when the user asks to like or engage with a specific lead's post before an outreach step'), names alternatives for adjacent needs (comment_on_post, edit_lead_list + trigger_workflow), and explicitly forbids the wrong usage pattern ('One person per call. There is no bulk form, and calling this in a loop over a list is not the supported way').

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

All campaignstack 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