Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create a CRM connection

luca_integrations_crm_connections_create
DestructiveIdempotent

Create or update a workspace-scoped CRM connection.

Instructions

Create or update a workspace-scoped CRM connection.

Luca operation: POST /api/integrations/crm/connections Required scopes: integrations:write Required OAuth scope: luca:full; 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": {
      "body": "<body>"
    },
    "name": "luca_integrations_crm_connections_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
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. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / body / properties / settings / additionalProperties
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "number"
+    },
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "object"
+    },
+    {
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
  2. First observedv0.4.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare non-read-only, idempotent and destructive, so the safety profile is covered; the description adds auth scopes, data-sensitivity level (redacted), and the idempotency-key fallback behavior. It does not disclose what an 'update' does to existing settings or credentials on a re-call, which is the main remaining behavioral unknown for a destructive upsert.

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 purpose sentence is front-loaded and the following lines are terse labeled facts (operation, scopes, idempotency, workspace), with no filler. Slight boilerplate feel from the scope/operation lines, but each carries decision-relevant 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?

For a 4-parameter mutation with an output schema and full annotations, the description covers auth, idempotency, and workspace targeting adequately. The notable omission is acquisition of credentialsRef and update-vs-replace semantics for the nested body.

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?

At 75% schema description coverage the schema already documents workspaceId/workspaceSlug/idempotencyKey; the description only adds the fact that overriding targets the environment-default workspace. The credential material — the credentialsRef pattern and the provider enum — is never explained, and it is unclear where a valid credentialsRef comes from.

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?

'Create or update a workspace-scoped CRM connection' gives a specific verb pair and resource with scope qualifier, so the operation is unambiguous. It doesn't name or differentiate itself from nearby siblings such as luca_integrations_crm_connections_list, _health, _disconnect, or _schema, so an agent must infer the boundary.

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?

The description supplies real preconditions: required scope integrations:write, OAuth scope luca:full, and that an Idempotency-Key is mandatory (with a server-generated fallback). It never states when to pick this tool over luca_integrations_crm_oauth_url or the connection-list/health siblings, so routing guidance is incomplete.

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