Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Dismiss a learning proposal

luca_learning_proposals_dismiss
DestructiveIdempotent

Dismiss one learning proposal so it drops out of the default list. Use it when the coach has decided against the change, not when you have simply read it.

Instructions

Dismiss one learning proposal so it drops out of the default list. Use it when the coach has decided against the change, not when you have simply read it.

Luca operation: POST /api/learning-proposals/{id}/dismiss Required scopes: learning:write Required OAuth scope: luca:draft; 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_learning_proposals_dismiss"
  }
}

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. First observedv0.4.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds real operational context beyond them: required scope learning:write, OAuth scope luca:draft, data sensitivity redacted, an Idempotency-Key requirement with server-side generation fallback, and the workspace override mechanism. It also clarifies the effect is removal from the default list rather than record deletion, which meaningfully nuances the destructive annotation.

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 decisive information is front-loaded in the first two sentences (what it does and when to use it), with endpoint/scope/idempotency boilerplate following. The operational lines are terse and each carries information, though the block reads as generated scaffolding rather than tightly edited prose.

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 need no explanation, and the description covers auth scopes, idempotency, and workspace targeting. The one gap that matters for a destructiveHint=true operation is whether a dismissal can be undone or the proposal re-surfaced, which is not stated.

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?

Schema description coverage is 75%, so the schema already documents workspaceId, workspaceSlug, and idempotencyKey; the description largely restates those same points (idempotency fallback, workspace override) rather than adding syntax or constraints. The required `id` parameter gets no added explanation beyond its UUID format in the schema.

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 ('Dismiss one learning proposal') plus the concrete effect ('drops out of the default list'), which lets an agent distinguish it from the read-only sibling luca_learning_proposals_list. It stops short of naming that sibling explicitly, so the differentiation is implied by the effect rather than by tool name.

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 an explicit when-to-use ('the coach has decided against the change') and an explicit when-not ('not when you have simply read it'), which is more than most definitions offer. It does not name a concrete alternative action/tool for the opposite decision path, which keeps it from 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

Other Tools