Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Enroll silent leads into the rescue cadence

luca_rescue_silent_leads
Destructive

Enroll silent leads into a multi-day rescue cadence to restart outbound touches, with each draft queued for review before sending.

Instructions

Enroll one or more silent leads into the multi-day rescue cadence. THIS STARTS OUTBOUND TOUCHES to real leads over the coming days. Luca drafts each one, and with auto-send off each waits in the review queue first. Pass confirm: true to proceed. cadenceTemplate is light | standard | aggressive (default standard). Example: { leadIds: ["..."], cadenceTemplate: "standard", confirm: true }.

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": {
      "leadIds": "<leadIds>"
    },
    "name": "luca_rescue_silent_leads"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.
leadIdsYesLead ids to enroll (max 100). Non-tenant ids are skipped.
workspaceIdNoOptional Luca workspace id override.
workspaceSlugNoOptional Luca workspace slug override.
idempotencyKeyNoReuse the same key when retrying this exact enrollment.
cadenceTemplateNoCadence intensity (default standard).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, and the description adds real value on top: touches are outbound to real leads, they unfold over multiple days, Luca drafts each message, and with auto-send off nothing ships until reviewed. It omits how to undo the enrollment (e.g. via luca_pause_cadence) and does not reconcile the non-idempotent hint with the idempotencyKey parameter.

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 side-effect warning is front-loaded in capitals where it matters, followed by the review-queue behavior, the confirm requirement and a compact example payload. The only redundancy is repeating the confirm: true instruction already spelled out in the confirm parameter description.

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

Completeness3/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 no explanation, and the description covers the delayed, review-gated nature of the enrollment well. For a destructive, multi-day, real-world messaging action it still lacks guidance on reversibility, per-lead failure handling (skipped non-tenant ids), and rate/volume expectations beyond the 100-id cap in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including confirm, leadIds, cadenceTemplate and idempotencyKey is already documented; the correct baseline is 3. The description restates the cadenceTemplate enum and its default plus a sample call, which adds only marginal meaning beyond the schema.

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?

"Enroll one or more silent leads into the multi-day rescue cadence" gives a specific verb (enroll) and resource (silent leads into a rescue cadence), so the agent knows exactly what happens. It does not, however, distinguish itself from the near-identical sibling luca_cadences_rescue_start or from luca_campaigns_enroll, leaving overlap ambiguous.

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

Usage Guidelines3/5

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

Usage is implied by the audience (silent leads) and by the confirm gate, and the description explains that auto-send off routes drafts to a review queue first. But it never states when to pick this over luca_cadences_rescue_start or luca_campaigns_enroll, nor any prerequisites such as consent or workspace scoping.

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