SKEIN

skein_move

Read-onlyIdempotent

There is no in-place project move in Skein. This tool is a documented signpost: it does NOT mutate any state, it returns a pre-filled kit for the canonical copy+supersedes+close workflow. Inputs: issueId (source) + targetProject (handle). The output has one shape, and it is this by default and by design: the source card WITHOUT the fields the prepared call already carries (title / description / type / priority and, when set, assignee / acceptanceCriteria / design / notes / labels — each of the source's texts appears in the response exactly once, in nextSteps[0].args; read the whole card with skein_show), the target project's components with naive name-match hints against the source title/description, and two ready-to-call nextSteps — skein_create in target (with a supersedes dependency edge on source) and skein_close on source. An unassigned source is copied with unassigned: true, so the copy stays unassigned whatever your «assign to me» setting says; an assigned source carries its assignee as an explicit one. The agent picks a componentId from targetComponents (or leaves the array empty for a project-wide task), fills in the close reason and closeTarget placeholders with the id returned by skein_create, then makes the two calls (the close answers closeLink:"existed" — step 1 made the edge). The new issue gets a fresh hierarchical id; the source closes and the supersedes edge is the audit trail. Why no in-place move: the hierarchical id is embedded in git commits, chats, messages between agents, and other external refs — renumbering would break them, and swapping project_id while keeping the id creates visual incongruity in the target's listing. Copy+supersedes is the honest mechanism that preserves provenance without breaking external pointers.

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>",
      "targetProject": "<targetProject>"
    },
    "name": "skein_move"
  }
}

Input Schema

Name	Required	Description	Default
`issueId`	Yes	Full hierarchical id of the source issue (e.g. "demo-42").
`targetProject`	Yes	Target project handle: alias, name, idPrefix, or UUID.

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?

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description is consistent with them ('does NOT mutate any state'). Beyond that it discloses non-obvious behavior: unassigned sources copy with `unassigned: true` regardless of the user's assign-to-me setting, assigned sources carry an explicit assignee, the close answers `closeLink:"existed"`, and the new issue receives a fresh hierarchical id.

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 critical constraint is front-loaded, which is good, but the remainder is a single dense block with deeply nested parentheticals and long em-dash asides that are hard to scan. The closing rationale paragraph is informative but could be compressed, and phrases like 'by default and by design' add no decision-relevant 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?

There is no output schema, so the description must carry the return-value burden, and it does: it specifies the exact response shape (source card minus fields already in nextSteps[0].args, targetComponents with name-match hints, two ready-to-call nextSteps). Nothing an agent needs to execute the follow-up workflow is missing.

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 100% and both parameters are already documented with examples in the schema. The description restates them as 'issueId (source) + targetProject (handle)' without adding format, resolution order, or error semantics beyond the schema, so the baseline 3 applies.

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 first two sentences state a specific and unusual purpose: there is no in-place move, and this tool is a non-mutating signpost returning a pre-filled copy+supersedes+close kit. It explicitly names the sibling calls the kit feeds (skein_create, skein_close) and points to skein_show for the full card, so an agent can place it precisely in the toolset.

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?

The description gives an explicit ordered procedure: pick a componentId from targetComponents (or leave empty for a project-wide task), fill the close reason/closeTarget placeholders with the id skein_create returns, then make the two calls. It also states what is unavailable (no in-place move) and why, which is exactly the when-not guidance an agent needs before searching for an alternative tool.

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.