Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Attach a channel identity to a lead

luca_leads_identities_attach
Destructive

Attach a verified or claimed identity to a lead.

Instructions

Attach a verified or claimed identity to a lead.

Luca operation: POST /api/leads/{id}/identities Required scopes: leads:write Required OAuth scope: luca:draft; 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>",
      "body": "<body>"
    },
    "name": "luca_leads_identities_attach"
  }
}

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
provenanceNo

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

B3.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds real operational context beyond them: required scopes (leads:write, luca:draft), full_content data sensitivity, and the Idempotency-Key requirement with server-side generation fallback. It does not say what is destroyed or how duplicate identities are handled, which is the remaining gap given the destructive hint.

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?

Purpose is front-loaded in the first line, followed by a compact metadata block (endpoint, scopes, idempotency, workspace override). No filler sentences, though the scopes/sensitivity line is dense shorthand rather than explanatory prose.

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 not be described, and the auth/idempotency/workspace dimensions are covered. For a destructive mutation with a nested body object, however, it omits what happens to a pre-existing identity on the same channel, duplicate/conflict behavior, and the meaning of the body fields.

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

Parameters2/5

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

Schema description coverage is only 60%, and the undocumented parts are the important ones: the top-level `id` (lead UUID) and the nested `body` with its channel enum, externalUserId, verificationStatus and sourceRef. The description mentions workspace override and idempotency key (already documented in the schema) but adds nothing about the required body shape or the semantics of verificationStatus values.

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?

States a specific verb and resource: attach a channel identity to a lead, which is clearly distinct from luca_leads_create and luca_leads_update in the sibling list. The word "identity" is not expanded to mean channel handle/ID (telegram, instagram, etc.), so the agent must infer the resource's shape, but the operation itself is unambiguous.

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?

The description never says when to use this versus luca_leads_update or luca_leads_create, nor what precondition must hold (e.g. lead must exist, identity must not already be attached). Usage is only implied by the verb and the scope requirement; the agent has to infer the situation.

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