Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Pause or resume a campaign

luca_campaigns_set_status
Destructive

Pause or resume a campaign by changing its status. Resume only when sends should restart, and pass confirm: true to allow the real-world side effect.

Instructions

Pause or resume a campaign. Archiving is only available in the SetLuca app, so a connected assistant gets 403 for it. A transition that does not make sense for the campaign's current state is rejected rather than forced through.

Luca operation: POST /api/campaigns/{id}/status Required scopes: campaigns:write Required OAuth scope: luca:queue_ops; data sensitivity: redacted Requires Idempotency-Key. Provide idempotencyKey for safe retries, or the server will generate one. Destructive when status is published (resuming sends): has a real-world side effect. You must pass confirm: true; the call is rejected without it. Use workspaceId or workspaceSlug to override the default workspace configured by environment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "body": "<body>"
    },
    "name": "luca_campaigns_set_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
bodyYes
confirmNoThis tool has a real-world side effect: it messages real leads, books, moves, or cancels a call, changes a lead's consent, imports leads, writes to a connected calendar or CRM, sends workspace events to an outside URL, or re-triggers downstream automations. Pass confirm: true to proceed; the call is rejected without it.
workspaceIdNoOptional Luca workspace id override.
workspaceSlugNoOptional Luca workspace slug override.
idempotencyKeyNoStable key for safe retries. If omitted, the MCP server generates a unique key for this call.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.1
    • addedOutput schema / properties / result / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "object"
+  },
+  {
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv0.4.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations it discloses the 403-on-archive limitation, that nonsensical transitions are rejected, the required scopes, the Idempotency-Key requirement with server-side generation fallback, and the real-world side effect of resuming. The idempotentHint=false annotation is consistent with the note that a server-generated key makes unkeyed retries unsafe.

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?

The core behavior and the destructive-transition warning are front-loaded before the operational metadata (endpoint, scopes). The scope/sensitivity boilerplate lines are somewhat dense but each carries actionable constraint information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating status-change tool with a nested body and an output schema, the description covers safety gating, validation behavior, workspace targeting, and retry semantics. Only the per-enum-status effects (paused vs archived) are left implicit.

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?

The description explains what the schema only lists: confirm gates the destructive published transition, workspaceId/workspaceSlug override the environment default, and idempotencyKey exists for safe retries. It does not differentiate paused vs archived semantics within the status enum, which is the one remaining gap at 67% coverage.

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?

The opening sentence names a specific verb pair and resource ('Pause or resume a campaign'), and the second sentence scopes out archiving with a concrete consequence (403 in a connected assistant). An agent can immediately tell this is the state-transition tool rather than the create/publish/duplicate siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states clear conditions for use: pass confirm: true when status is published because resuming sends messages, and invalid state transitions are rejected rather than forced. It stops short of naming sibling alternatives (e.g. luca_campaigns_publish for publishing a draft), so routing between status changes and publication is left to inference.

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

Deploy Server

Other Tools