Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Preview a CRM sync

luca_integrations_crm_sync_runs_create

Record a dry-run preview of the changes a CRM sync would make, as a new sync run. Nothing is written to the CRM: the API refuses a live sync.

Instructions

Record a dry-run preview of the changes a CRM sync would make, as a new sync run. Nothing is written to the CRM: the API refuses a live sync.

Luca operation: POST /api/integrations/crm/connections/{id}/sync-runs Required scopes: integrations:write Required OAuth scope: luca:full; data sensitivity: full_content 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>"
    },
    "name": "luca_integrations_crm_sync_runs_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
bodyNo
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
provenanceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.1
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "This 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.",
-  "type": "boolean"
-}
    • changedInput schema / required
      Previous value: -[
-  "id",
-  "body"
-]New value: +[
+  "id"
+]
    • addedOutput schema / properties / result / properties / conflictReport / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "object"
+  },
+  {
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv0.4.0

TDQS

A4/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: required scope integrations:write, luca:full OAuth scope, full_content data sensitivity, server-side idempotency key generation, and the hard refusal of live mode. One mild tension with annotations: idempotentHint=false sits awkwardly beside 'Provide idempotencyKey for safe retries', since a stable key is what makes retries idempotent – worth flagging but not a genuine contradiction, as the tool does create a durable run record (consistent with readOnlyHint=false).

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 fact – nothing is written to the CRM – is front-loaded in sentence one, and the operational metadata is packed into short labeled lines rather than prose. The scopes/sensitivity block is slightly verbose for an agent that may not act on it, but every line carries usable 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?

With an output schema present, the return shape needn't be described, and annotations plus the description together cover safety, auth scopes, idempotency, and workspace targeting. The only real gap is the body.direction enum (luca_to_crm / crm_to_luca / bidirectional), which is neither explained here nor in the schema, so the agent must guess its effect on the preview.

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 60%, and the description compensates for the most consequential gap: the body.mode enum offers 'live', but the description states the API refuses a live sync, so the agent knows only dry_run will succeed. It also explains idempotencyKey behavior (server generates one if omitted) and the workspaceId/workspaceSlug override purpose, matching the schema's own parameter descriptions.

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 first sentence states a specific verb and resource – record a dry-run preview as a new sync run – and immediately resolves the tension with the tool name 'create' by asserting nothing is written to the CRM. That clearly separates it from the read-side sibling luca_integrations_crm_sync_runs_list, though no sibling is named explicitly.

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 gives a clear condition for use – previewing the changes a sync would make before committing – and an explicit constraint that live mode is refused by the API. It does not name alternatives (e.g. the list or health siblings) for inspecting existing runs, so usage is clear but not fully disambiguated.

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