Skip to main content
Glama

skein_update_many

Patch many issues in one round-trip. Each items[i] carries its own id + expectedVersion + the same partialPatch shape that skein_update accepts (title / description / type / priority / assignee / componentIds / labelsAdd / labelsRemove / status / reason / dueAt / deferUntil / design / acceptanceCriteria / notes / externalRef / sourceContext / estimatedMinutes). The N patches are independent — passing the same value in every item gives mass-edit semantics. Text patches (description, design, acceptanceCriteria, notes, externalRef, sourceContext): omitted leaves unchanged; null or an empty string clears. Other non-string values are refused before any write with validation_error, code text_field_not_string and field naming the argument. Refusal applies only to the offending row. Each row runs the full skein_update chain in its own SERIALIZABLE sub-transactions per step; mid-chain failure on one row leaves THAT row in partial state (earlier sub-ops are NOT rolled back — this matches single-tool behaviour) but does not affect the rest of the batch. Inspect results[i].ok / results[i].error.code per row. A row stopped by batch_deadline_exceeded / request_cancelled while in progress may have committed earlier steps: re-read it and resend only what is missing, with the live version. A row may return serialization_retry after a sub-operation rolls back; earlier changes in that row may have committed. Re-read and resend only missing changes.

closeOutcome is required when transitioning to closed; repeating a close without it preserves the previous outcome. No per-row closeTarget: close an OPEN issue as duplicate / superseded with skein_close / skein_update. Caps at 100 items per call. force=true requires admin and applies uniformly to every row. reviewRequired is NOT accepted here: the review flag travels its own path (it moves neither version nor updated_at, so a batch row could not report it). A row carrying it is rejected with validation_error and writes nothing — use skein_update, one call per issue.

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": {
      "items": "<items>"
    },
    "name": "skein_update_many"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoBypass lock + version + pinned predicates across the entire batch. Needs force_unlock on each row's project (project owner, space owner, instance admin); a row without it fails with `force_unlock_forbidden`. Default: false.
itemsYesPer-row partial patches. Min 1, max 100. Order is preserved in results[].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description goes far beyond by disclosing per-row SERIALIZABLE sub-transactions, that mid-chain failures leave that row partially applied while other rows are unaffected, and the specific error codes (batch_deadline_exceeded, request_cancelled, serialization_retry, text_field_not_string) with recovery instructions.

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?

Purpose and payload shape are front-loaded and every paragraph carries operational weight, but the re-read-and-resend guidance is restated three times (deadline/cancel, serialization_retry, and near the closeOutcome paragraph), which is slightly redundant in an otherwise dense, well-ordered description.

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, yet the description tells the agent exactly how to inspect outcomes (results[i].ok / results[i].error.code per row, order preserved) and how to recover from partial commits. For a non-atomic batch mutation with per-row failure modes, nothing an agent needs to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although top-level schema coverage is 100%, the items object is additionalProperties:true, so the patch fields themselves are undocumented in the schema — the description enumerates all of them and adds null-vs-omitted semantics for text fields (omitted leaves unchanged, null or empty string clears) plus the rule that non-string values are refused per-row. This is substantive meaning beyond 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?

"Patch many issues in one round-trip" gives a specific verb (patch), resource (issues) and scope (many), and explicitly ties the per-row payload to the partialPatch shape that skein_update accepts, so the agent can tell it apart from the single-issue 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?

It names concrete alternatives and the conditions that select them: use skein_close / skein_update to close an OPEN issue as duplicate/superseded because there is no per-row closeTarget, and use skein_update one call per issue when reviewRequired is needed (which this tool rejects outright). It also states the 100-item cap and the admin requirement for force=true.

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.