Skip to main content
Glama

skein_drop_delegated

Idempotent

Drop this issue from your Delegated tab: you stop seeing it there AND stop receiving bell notifications. Use it when you have handed off the work and don't need to track it anymore. ANSWERS WITH AN ACKNOWLEDGEMENT by default — the id, the applied state and the new version, no issue card and no prose — so the expectedVersion cycle continues without a re-read; pass verbose for the full IssueDetail.

Effect: appends your user id to the issue's dismissed_by array (sticky — persists across re-assignments unless you become the current assignee again, in which case it's cleared automatically). Also unsubscribes you from the issue exactly like skein_watchers(action="unwatch"): IF you are subscribed to it, the subscription is deleted and an opt-out stops the automatic paths (assignment, reopen) from re-subscribing you; if you are NOT subscribed (for example, auto-unsubscribed when the issue closed), no opt-out is recorded, so a later reopen or assignment can subscribe you again. Either way the issue's card leaves your Watching column.

Idempotent: a second call on an issue you've already dropped is a silent no-op — no duplicate event, no version bump. The acknowledgement carries dismissed — YOUR membership in dismissed_by after the call (true here) — because neither status nor version moves, so it is the only proof the write applied.

To resume, call skein_resume_delegated. To resume bell notifications only, call skein_watchers(action="watch") (the two intents are decoupled — undismissing the delegation does NOT re-arm notifications).

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": "skein_drop_delegated"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesHierarchical issue id, e.g. demo-42 or sk-14.
verboseNoReturn the full IssueDetail, prose included. Default false = acknowledgement: `id`, `ok`, `version` plus the post-state stamps that apply (`status`, `assignee`, lock / claim / close stamps) — no issue card and no free text. The version is always there, so the expectedVersion cycle needs no extra read. Details: skein_get_instructions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false): it discloses the concrete mutation (appending user id to dismissed_by), the stickiness rules across re-assignment, the conditional unsubscribe vs. opt-out semantics, and that a repeat call is a silent no-op with no version bump. It also explains why the acknowledgement carries `dismissed` — the only proof of a write when neither status nor version moves.

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?

Front-loaded with purpose, then effect, then idempotency, then recovery routes — a logical order with no wasted opening. It is dense and fairly long; a couple of restatements ('Either way the issue's card leaves your Watching column' partly repeats the opening) could be trimmed, but nearly every sentence carries decision-relevant information.

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?

For a 2-parameter mutation with no output schema and no annotations covering side effects, the description covers mutation target, side effects, idempotency, return shape, and both escape hatches. An agent has everything needed to call it correctly and to predict the result.

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 100%, so the baseline is 3, but the description adds outcome-level meaning to `verbose`: the default acknowledgement continues the expectedVersion cycle without a re-read, and verbose yields a full IssueDetail card. It also documents what the acknowledgement contains (`dismissed`), which the schema does not.

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?

Opens with a specific verb+resource+location: 'Drop this issue from your Delegated tab', and immediately states the dual effect (hidden from tab AND no bell notifications). It is unmistakably distinct from the sibling skein_resume_delegated, which it names explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when: 'when you have handed off the work and don't need to track it anymore.' It also names both re-entry paths and their distinct conditions: skein_resume_delegated for the delegation, skein_watchers(action="watch") for notifications only, with a warning that they are decoupled.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.