Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Restore a rejected draft

luca_review_queue_restore
Destructive

Restore a rejected review-queue item to pending so it can be re-triaged. Booking messages cannot be restored; use an idempotency key for safe retries.

Instructions

Restore a rejected review-queue item back to pending. A booking message cannot be restored.

Luca operation: POST /api/review-queue/{id}/restore Required scopes: review_queue: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>"
    },
    "name": "luca_review_queue_restore"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
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.2
    • addedOutput schema / properties / result / properties / firstApproval
      Added value: +{
+  "type": "boolean"
+}
  2. First observedv0.4.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the auth profile (review_queue:write, luca:queue_ops), data sensitivity, and the Idempotency-Key retry contract. There is mild tension with idempotentHint=false, but the key mechanism is an external dedup layer rather than a claim that unkeyed repeats are harmless, so it reads as added context rather than contradiction.

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?

Behavior is front-loaded in the first sentence, with operational metadata (endpoint, scopes, idempotency, workspace) stacked in short labeled lines. The 'Luca operation' and 'data sensitivity: redacted' lines are metadata padding of limited decision value, but the text stays compact.

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?

An output schema exists, so return values needn't be explained, and the definition covers auth scope, idempotency, workspace override, and the booking-message exclusion. It stops short of stating failure modes (e.g., restoring an item not in rejected state) or whether other item state is reset.

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 75% and the description adds real meaning beyond it: workspaceId/workspaceSlug override the environment-configured default, and idempotencyKey enables safe retries or is auto-generated server-side. The bare `id` path parameter is only implied via the POST URL template, which is a minor gap.

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?

States a specific verb and resource ('Restore a rejected review-queue item back to pending') plus a concrete scope limitation: booking messages cannot be restored. That is enough for an agent to distinguish it from approve, reject, regenerate, and bulk variants without opening schemas.

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?

Usage is implied by the state constraint ('rejected' items only) and the booking-message exclusion, which is genuinely useful. However, no sibling alternative is named and there is no explicit guidance such as when to approve vs. restore or what to do for a booking message that cannot be restored.

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