Skip to main content
Glama
SetLuca

SetLuca

Official

Resume an enrollment a safety approval kept paused

luca_campaigns_enrollments_resume
Destructive

Resume a campaign enrollment paused for a safety review after coach approval, sending the campaign's next message to the lead.

Instructions

Resume a campaign enrollment that stayed paused after the coach approved a safety review on the lead's reply. Use it once the coach has approved the review and decided the lead is ready for the campaign again. It sends the campaign's next message to the lead. Luca answers 404 when the enrollment does not exist. It answers 409 when the enrollment is not waiting on a safety approval, or when it has already moved on from its wait.

Luca operation: POST /api/campaigns/{id}/enrollments/{enrollmentId}/resume 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: 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>",
      "enrollmentId": "<enrollmentId>"
    },
    "name": "luca_campaigns_enrollments_resume"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
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.
enrollmentIdYes
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. Addedv0.4.2

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructiveHint and openWorldHint, and the description still adds substantial context beyond them: 404 and 409 error semantics with their exact meanings, the required confirm: true gate, the Idempotency-Key requirement with fallback behavior, required scopes, and data sensitivity. This is the kind of detail an agent needs to avoid a rejected or duplicated call.

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 behavioral core is front-loaded in the first three sentences, followed by structured operation/scope/destructive/workspace blocks that are easy to scan. There is minor redundancy: the destructive side-effect warning in prose largely restates the confirm parameter's schema description and the destructiveHint annotation.

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?

An output schema exists, so return values need not be described. Given the mutation's real-world consequences, the definition covers the preconditions, the confirmation gate, idempotency, failure modes, and scope/workspace overrides — everything needed to invoke 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 67%, and the description compensates for the gaps by explaining confirm (mutation gate), idempotencyKey (safe retries, server-generated if omitted), and workspaceId/workspaceSlug (override the environment default). The id and enrollmentId path parameters are only implied via the endpoint path, so it is not fully additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (resume a campaign enrollment) and pins down the exact precondition: the enrollment stayed paused after a coach approved a safety review. It also states the concrete effect (sends the campaign's next message), which separates it from generic enrollment tools. It does not explicitly name a sibling alternative, so it stops short of a 5.

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?

"Use it once the coach has approved the review and decided the lead is ready" gives a clear triggering condition, and the 409 clause implicitly defines when not to call it (enrollment not waiting on a safety approval, or already past the wait). There is no explicit pointer to a different tool for the not-ready case, which keeps it at 4 rather than 5.

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