Skip to main content
Glama

skein_project_update

Destructive

Wide-scope patch for an existing project (its owner, the owner of its space or the instance admin only). Optional fields: name, description, gitlabGroup (empty string clears), archived (true|false), aliasesAdd, aliasesRemove, gitReposAdd, gitReposRemove (by repo UUID). At least one must be present. Every change lands in one SERIALIZABLE tx — a single bad alias collision or repo removal that hits an in-use repo rolls back the entire patch. visibility (space|members) switches who sees the project: members → space gives it to every member of the space, space → members takes it from everyone without a project membership. A project never changes its space: a space value is refused with space_change_forbidden and nothing changes. Returns the updated ProjectDTO.

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": {
      "project": "<project>"
    },
    "name": "skein_project_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoReplace project name. 1..200 chars after trim.
spaceNoNot supported: a project cannot move to another space. Any value but null is refused with space_change_forbidden.
projectYesProject handle: alias, name, idPrefix, or UUID.
archivedNotrue = archive the project (no-op if already archived); false = unarchive (no-op if active).
aliasesAddNoAliases to add. Each is unique across projects — a collision rolls back the whole patch.
visibilityNoSwitch visibility: "space" — every member of the space sees the project; "members" — only its members and the space owner.
descriptionNoReplace description. Pass an empty string to clear.
gitReposAddNoRepositories to append to gitRepos[]. Each entry: {name, url, defaultBranch}. Server generates the id.
gitlabGroupNoReplace the optional GitLab group binding. Pass an empty string to clear.
aliasesRemoveNoAliases to remove. An alias not present on the project rolls back the patch.
gitReposRemoveNoRepository UUIDs to remove from gitRepos[]. A repo still referenced by a non-archived component rolls back the patch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the annotations (destructiveHint=true, idempotentHint=false) by disclosing transactional behavior: all changes land in one SERIALIZABLE tx and any alias collision or in-use repo removal rolls back the entire patch. It also defines the visibility switch semantics, the space_change_forbidden refusal, and the return value (updated ProjectDTO).

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

Conciseness5/5

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

Front-loads the operation and actor, then the field list, then the risky semantics (transaction, visibility, forbidden space change). Sentences are dense but every clause carries decision-relevant information; no filler or repetition of the schema.

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 an 11-parameter destructive mutation with no output schema, the description covers actor requirements, the at-least-one-field rule, per-field edge cases, failure/rollback behavior, and the return type. An agent has enough to call this correctly without opening anything else.

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 baseline is 3; the description earns above that by explaining behaviors the schema only hints at — empty string clears gitlabGroup, archived true/false are no-ops when already in that state, and gitReposRemove takes repo UUIDs with rollback on in-use repos. It does not restate the `project` handle resolution rules, which remain schema-only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete verb+resource+scope: 'Wide-scope patch for an existing project', then enumerates the patchable fields. The word 'wide-scope' implicitly separates it from the narrower sibling skein_update and from skein_project_create, but no sibling is named explicitly, so differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit preconditions: caller must be the owner, space owner, or instance admin, and 'At least one must be present'. It also carves out an exclusion (no space change, refused with space_change_forbidden). What is missing is a positive routing statement about when to choose this over skein_update or skein_update_many.

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.