SKEIN

skein_project_members

Destructive

Who is on a project and with which role ('owner' | 'member'). Reading the roster is open to any member of the project; adding and removing require a project owner (the space's owner and the instance admin included), except that a member may remove themselves (self-leave). Adding is idempotent — re-adding with the same role writes nothing. A member who has access to the project through its space cannot be removed (member_via_space): switch the project's visibility to members or remove them from the space. Read-only actions: list.

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

Input Schema

Name	Required	Description
`role`	No	Only read by add: role to grant. Required for add. External users cannot be owners.
`action`	Yes	What to do: - "list" → the full member roster with per-row role and added_at / added_by. - "add" → add a user to the project, or change an existing member's role. - "remove" → drop a membership; removing a non-member returns `member_not_found`.
`userId`	No	UUID of the target user. Mutually exclusive with `username`; exactly one of the two is required for add and remove.
`project`	Yes	Project handle: alias, name, or UUID. Required for every action. A project the caller cannot see renders as `project_not_found`.
`username`	No	Username of the target user (case-insensitive). Mutually exclusive with `userId`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes well beyond the annotations: permission model, self-leave carve-out, the `member_via_space` failure and its workaround, `member_not_found` on removing a non-member, and per-action idempotency (re-adding the same role writes nothing). The idempotency note refines rather than contradicts the tool-level `idempotentHint: false`, since only the add action is idempotent. The only gap is what a successful add/remove returns.

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?

Dense, front-loaded, and four sentences with no filler; the permission rule and the escape hatch for the blocked removal are both placed where an agent will read them. Minor redundancy in restating the role enum and in 'Read-only actions: list', which the annotations and the action enum already convey.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation tool with no output schema, the description covers the authorization surface, error paths, and idempotency, which is what an agent most needs before calling it. Return shape (roster rows with role/added_at/added_by) is only documented in the schema's action enum, so the description itself is not fully self-contained.

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 enum descriptions already explain each action, role, and the userId/username mutual exclusion in detail. The description reinforces the role values and ties actions to permissions, but adds little parameter-level meaning the schema does not already carry, 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?

Opens with a specific verb+resource framing: who is on a project and with which role, enumerating the two roles. The three actions (list/add/remove) are unambiguous and no sibling tool in the catalog overlaps with project membership management, so an agent can select it without opening the 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?

Explicitly states who may do what per action: listing is open to any project member, add/remove require project owner (space owner and instance admin included), with the self-leave exception spelled out. It even routes around the blocked case by naming the alternatives — switch the project's visibility to members, or remove the user from the space — rather than leaving the agent stuck on `member_via_space`.

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.