SetLuca

Official

by setluca

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Report how a call went

luca_call_events_feedback

Destructive

File the coach's report on how a call went. A completed or no_show outcome also records booking attendance, and a completed call queues its summary.

Instructions

File the coach's report on how a call went. A completed or no_show outcome also records booking attendance, and a completed call queues its summary. A no_show can start recovery messages to the lead, so it needs the queue_ops grant and confirm: true.

Luca operation: POST /api/call-events/{id}/feedback Required scopes: call_events:write Required OAuth scope: luca:queue_ops; data sensitivity: full_content Requires Idempotency-Key. Provide idempotencyKey for safe retries, or the server will generate one. Destructive when outcome is no_show (can start recovery messaging): has a real-world side effect. You must pass confirm: true; the call is rejected without it. 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_call_events_feedback"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`body`	Yes
`confirm`	No	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.
`workspaceId`	No	Optional Luca workspace id override.
`workspaceSlug`	No	Optional Luca workspace slug override.
`idempotencyKey`	No	Stable key for safe retries. If omitted, the MCP server generates a unique key for this call.

Output Schema

Name	Required	Description	Default
`result`	Yes
`provenance`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.1Oct 28, 2026

addedInput schema / properties / body / properties / expectedOutcomeUpdatedAt

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^(?:\\d{4}-(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|\\d{4}-(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|\\d{4}-02-(?:0[1-9]|1\\d|2[0-8])|(?:\\d{2}(?:0[48]|[2468][048]|[13579][26])|(?:[02468][048]|[13579][26])00)-02-29)T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|[+-](?:[01]\\d|2[0-3]):[0-5]\\d)$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "format": "date-time"
+}

First observedv0.4.0Oct 21, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the required OAuth scope (luca:queue_ops), the call_events:write scope, full_content data sensitivity, idempotency-key behavior with server-side generation fallback, and the exact consequence of no_show (outbound recovery messaging to a real lead). This directly confirms and enriches destructiveHint=true rather than repeating it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and well organized, but the no_show/confirm requirement is stated twice (opening paragraph and again in the 'Destructive when outcome is no_show' block), and the confirm sentence largely duplicates the schema description of the confirm property. Tighter consolidation would remove a genuine redundancy.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers everything an agent needs for a destructive, open-world write with nested body params and an output schema: prerequisite scopes, the single outcome value that triggers side effects, the required confirmation flag, retry semantics, and workspace scoping. Return values are covered by the output schema.

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 67% schema coverage, the description adds real meaning: confirm is tied to a specific outcome (no_show) rather than being a generic gate, idempotencyKey is explained as retry-safety with server fallback, and workspaceId/workspaceSlug are framed as overrides of an environment-configured default. It does not explain rescheduledTo or expectedOutcomeUpdatedAt, which are the least self-evident body fields.

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+resource ('File the coach's report on how a call went') and names the concrete record fields (outcome, rating, notes, fields). It implicitly distinguishes from siblings by describing its downstream effects (booking attendance, summary queuing, recovery messaging), but never names an alternative like luca_bookings_outcome_record for an agent to compare against.

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?

Gives clear conditional guidance per outcome value: completed/no_show also writes attendance, completed queues a summary, no_show requires the queue_ops grant plus confirm:true. It lacks an explicit 'use this instead of X' routing statement against the many sibling call-event tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server