Skip to main content
Glama

skein_commits_detach

DestructiveIdempotent

Remove git commit refs from an issue without touching status, closed_reason, closed_at, version or locked_by. The counterpart of skein_commits_attach, and the only way back from a hash that should not have been linked — a hash is accepted on its FORM alone (lowercase hex, 7..64), so a fabricated one passes validation and, before this tool, stayed linked forever. 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.

Matches on HASH, not on (repo, hash): every row of this issue carrying the hash is removed, whichever repo it was filed under, so a ref attached to the WRONG repo is removable too. Issue may be in any status. Caller must hold the lock OR pass force=true (force_unlock: project owner, space owner, instance admin) — unlocked issues are open to any agent.

The response carries detached (the rows actually removed, each with the repoId you never named) and notFound (the hashes that had no row on this issue) at the TOP LEVEL in both lean and verbose mode. Read them: a typo in the hash produces the same success as a real removal, and only notFound tells the two apart.

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": {
      "issueId": "<issueId>",
      "hashes": "<hashes>"
    },
    "name": "skein_commits_detach"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoBypass lock predicate. Needs force_unlock on the issue's project (project owner, space owner, instance admin); others get `force_unlock_forbidden`. Default: false.
hashesYesCommit hashes to unlink from this issue. Max 10. Lowercase hex, 7..64 chars — the same shape skein_close and skein_commits_attach accept, validated here too so a malformed hash is refused instead of silently reported as `notFound`. Must match the stored hash exactly: this is a string match, not a git lookup, so an abbreviation does not remove the full hash it prefixes.
issueIdYesFull hierarchical issue id (e.g. "demo-42").
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?

Annotations declare destructive=true and idempotent=true, and the description adds substantive behavior beyond that: removal matches on hash alone across every repo row, a hash is validated on form only so a fabricated hash passes validation, and removal works in any issue status. It also discloses the default acknowledgement response shape and that the version is still returned so the expectedVersion cycle needs no re-read.

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, the exclusion list and the counterpart are front-loaded, and nearly every sentence carries operational information. It is longer than most definitions and includes some emphatic prose, but no sentence is purely decorative.

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?

There is no output schema, so the description carries the return contract itself: `detached` and `notFound` appear at the top level in both lean and verbose mode, plus a warning that a mistyped hash yields the same success as a real removal. For a destructive, 4-parameter tool this covers what an agent needs before calling.

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 schema already documents all four parameters; the description still adds meaning the schema lacks, notably that matching is on hash not (repo, hash) so a ref filed under the wrong repo is removable. It also frames force as the lock-bypass and verbose as the lean-vs-IssueDetail switch, though some of this overlaps wording already present in the schema.

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?

The opening sentence gives a specific verb (remove) and resource (git commit refs on an issue) and explicitly scopes what is NOT touched (status, closed_reason, closed_at, version, locked_by). It also names its counterpart skein_commits_attach, so an agent can distinguish it from the attach sibling without opening either schema.

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?

States the exact scenario that selects this tool ('the only way back from a hash that should not have been linked') and names the inverse tool. It also gives the precondition: the caller must hold the lock or pass force=true, with a parenthetical listing who can force.

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.