SKEIN

skein_claim

Take locks for the caller's MCP session using exactly one of id or ids. A batch contains 1..100 unique issue ids and is atomic: every issue is claimed or the whole transaction rolls back; the successful response preserves caller order. Claim transitions status to in_progress atomically. open/deferred → in_progress in the same transaction; started_at is stamped on first entry. Re-claiming the same in_progress issue from the same session is idempotent (no version bump, no event). Locked by another session → already_claimed. Closed issues cannot be claimed — they return cannot_claim_closed; reopen via skein_update first. Standing tasks return cannot_claim_standing — spawn a child (skein_create parentId=) and claim that. already_claimed always reflects a real other holder; a claim that loses a database serialization race returns serialization_retry instead — nothing was written, so retry the call verbatim. A successful claim emits issue.claimed plus issue.status_changed (reason="claim") when status transitioned, and acknowledges with the post-state: id, status=in_progress, lockedBy, the claim stamp and the version (see verbose for the full issue). A BATCH acknowledges with {results:[…one row per input id, in caller order…], summary:{requested, succeeded, failed}} — the same form skein_close_many uses. That envelope is NOT an invitation to partial success: a batch claim is still all-or-nothing, so failed is 0 on every response you will ever see and a failing batch is a tool error with nothing written. Admins may pass assignee to claim on behalf of another user; non-admins setting assignee to anyone other than themselves get forbidden. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "skein_claim"
  }
}

Input Schema

Name	Required	Description
`id`	No	One full hierarchical issue id. Exactly one of id or ids is required.
`ids`	No	Atomic claim batch: 1..100 unique full hierarchical issue ids. Exactly one of id or ids is required; response order matches this array.
`verbose`	No	Return 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. On a batch it applies to every row; the `{results, summary}` envelope is the same in both modes.
`assignee`	No	Optional assignee handle. Defaults to caller's username (null or blank counts as omitted). Admin-only when set to a different user — non-admins get `forbidden`. A user UUID that does not name a person who may work in the project is refused with assignee_not_allowed. A non-string value (number, array, object, boolean) is refused with validation_error, code assignee_not_string, and nothing is claimed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds far more than the annotations convey: transactional atomicity and rollback, event emission (`issue.claimed`, `issue.status_changed`), the serialization_retry concurrency path, and the admin-only `assignee` authorization rule with `forbidden`. The narrow same-session idempotency statement softly qualifies the blanket idempotentHint=false, but since it is scoped to one repeat case and the tool otherwise mutates state and emits events, this is a refinement rather than a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and input constraint are correctly front-loaded, but the batch all-or-nothing rule is stated three separate times ("is atomic", "still all-or-nothing", "nothing written"), and the closing acknowledgement paragraph duplicates the `verbose` schema description. The density of unique information is high, but the repetition costs it.

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 mutation tool with no output schema, the description covers the response shape in both ack and batch forms, all relevant error codes, idempotency, authorization, and concurrency retry behavior. An agent has everything needed to call it correctly and interpret the result without a follow-up read.

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 coverage is 100% and the schema already documents `id`, `ids`, `verbose`, and `assignee` in comparable detail, including order preservation and the forbidden/validation error codes. The description largely restates that parameter behavior; its only marginal addition is explaining that the `{results, summary}` envelope mirrors skein_close_many. Baseline 3 is appropriate when the schema does the heavy lifting.

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 concrete verb and resource — "Take locks for the caller's MCP session" — and immediately constrains the input to exactly one of `id` or `ids`. It also names the specific state it produces (`in_progress`) and differentiates itself from skein_update (reopen) and skein_create (spawn a child for standing tasks).

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?

Explicitly states when to use and when not: closed issues must be reopened via skein_update first, standing tasks must be spawned via skein_create parentId=<this>, and already-claimed issues should be treated as held by another session. It names concrete alternatives and the conditions that select them, leaving little to inference.

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

All SKEIN tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.