Skip to main content
Glama

skein_commits_attach

Idempotent

Attach git commit refs to an existing issue without touching status, closed_reason, closed_at, version or locked_by. Use this — NOT a second skein_close — when the original close forgot commits[] or a closing commit landed afterwards: re-closing silently overwrites the original closed_reason, this tool is the additive path. 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.

Issue may be in any status. Re-attaching the same hash is a silent no-op; the issue.commits_attached event is still emitted for the audit trail. Caller must hold the lock OR pass force=true (force_unlock: project owner, space owner, instance admin) — unlocked issues are open to any agent. No expectedVersion: the attach does not bump version.

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>",
      "commits": "<commits>"
    },
    "name": "skein_commits_attach"
  }
}

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.
commitsYesCommit-refs to link to this issue. Max 10. Each needs `hash`; identify the repo with `repoId` or `repoUrl` from the project's gitRepos[], or omit both when the project has exactly one repo. Re-sends dedup silently per (issue, repo, hash). See skein_get_instructions ("Commit refs"). Must be non-empty.
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?

Goes well past the annotations, which only declare idempotent/non-destructive write. It discloses that status and lifecycle fields are untouched, that re-attaching a hash is a silent no-op while the audit event is still emitted, that a lock or force=true with force_unlock entitlement is required (with the forbidden error surfaced in the schema), and that no expectedVersion is consumed because version does not bump. That is the full behavioral picture an agent needs before mutating.

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-loads the verb, the untouched fields, and the sibling exclusion in the first sentence, which is the right ordering. It is long and the acknowledgement/verbose explanation partially restates the verbose parameter's own schema description, so it loses a point for some redundancy, but almost every sentence carries operational content.

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?

With no output schema, the description still defines the return shape (id, ok, version plus post-state stamps, no card or prose) and explains why version is present. Combined with auth, idempotency, and version-cycle notes, nothing needed to call this correctly is missing.

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 meaning the schema does not enforce: the dedup rule per (issue, repo, hash), the fact that force still requires force_unlock, and that verbose swaps the acknowledgement for the full IssueDetail. It does not add syntax detail for individual commit fields, which is acceptable given the rich 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?

States a specific verb and resource — 'Attach git commit refs to an existing issue' — and immediately scopes it with the fields it does not touch (status, closed_reason, closed_at, version, locked_by). It explicitly names the sibling it is not ('NOT a second skein_close'), so an agent can separate it from skein_close and skein_commits_detach without opening a 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?

Gives a concrete when-to-use condition ('the original close forgot commits[] or a closing commit landed afterwards') and an explicit when-not with the reason ('re-closing silently overwrites the original closed_reason'). Both the scenario and the failure mode that selects the alternative are spelled out.

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.