Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Edit a campaign draft

luca_campaigns_draft_update
Destructive

Save a campaign draft with optimistic concurrency. Send the draft's current updatedAt to prevent overwriting newer edits; conflicts return 409.

Instructions

Save a campaign draft. Read the campaign with luca_campaigns_get first and send its draft.updatedAt as body.expectedDraftUpdatedAt, so this cannot overwrite an edit made since. Without that field Luca refuses the call with a 428. If the draft has changed since you read it, Luca answers 409: read the campaign again and reapply your change.

Luca operation: PATCH /api/campaigns/{id}/draft 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. 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_draft_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
bodyYes
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. Changed2 schema fields changedv0.4.1
    • addedInput schema / properties / body / properties / graph / properties / edges / items / properties / condition / additionalProperties
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "number"
+    },
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "object"
+    },
+    {
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • addedInput schema / properties / body / properties / graph / properties / nodes / items / properties / config / additionalProperties
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "number"
+    },
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "object"
+    },
+    {
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
  2. First observedv0.4.0

TDQS

A4.3/5.0
Behavior3/5

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

The description goes well beyond the annotations by disclosing optimistic concurrency semantics, the 428/409 status codes, required scopes, redaction level, and the Idempotency-Key requirement. What it does not cover is what "destructive" actually means here (does saving replace the entire draft or merge?) — annotations flag destructiveHint=true but the description never says what gets replaced or lost. Strong on protocol behavior, thin on the destructive payload consequence.

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 critical constraint and the recovery procedure are front-loaded in the first two sentences, which is the right ordering for a tool that fails without them. The trailing block of operation/scopes/sensitivity metadata is boilerplate that could be trimmed, though it is at least segregated from the actionable guidance.

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 5-parameter nested-payload mutation with an output schema (so return values need no explanation), the definition covers the sequencing and conflict behavior an agent must get right. The remaining gap is payload-level: nothing explains what the graph or knowledge fields must contain, though the deeply typed schema and its enums largely carry that burden.

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 60% schema coverage, the description compensates for the most opaque field: expectedDraftUpdatedAt's origin and purpose are fully explained, as are idempotencyKey and the workspace overrides. The large nested body.graph/knowledge/qualification structures are left entirely to the schema, so meaning is added for the protocol fields but not the payload fields.

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?

"Save a campaign draft" gives a specific verb (save/update) and resource (campaign draft), reinforced by the concrete endpoint PATCH /api/campaigns/{id}/draft. It is immediately distinguishable from the read path it names, luca_campaigns_get, without opening either 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?

It prescribes the exact prerequisite workflow (read with luca_campaigns_get first, pass draft.updatedAt as expectedDraftUpdatedAt) and the recovery path on conflict (409 -> re-read and reapply). It also states the failure mode when the field is omitted (428), leaving nothing 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