Skip to main content
Glama

skein_project_create

Create a new project. The calling user becomes the initial owner. idPrefix is the per-project token used to namespace issue ids (e.g. "demo" gives ids like "demo-42"); when omitted it's auto-derived from the name. defaultIdMode selects the id-generation strategy for issues (counter|hash|custom; default counter). Optional aliases and gitRepos are inserted atomically with the project — a collision (alias already taken, name/id_prefix already taken) rolls back the whole create. The project goes into a space: space names it (a short id from skein_whoami); when omitted, the one space you can create projects in is used; if there are several, the call is refused with space_required listing them. A space you can see only as the instance admin is refused with not_space_member: add yourself as a member first.

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

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name (1..200 chars after trim).
spaceNoShort id of the space (skein_whoami lists your spaces). Omit when you can create projects in exactly one space.
aliasesNoProject aliases (each 1..64 unicode word/hyphen/underscore). Each is unique across projects — a collision rolls back the create.
gitReposNoGit repositories the project owns. Each entry has {name, url, defaultBranch}. Their ids are server-generated.
idPrefixNoPer-project id prefix (lowercase, [a-z0-9][a-z0-9_-]{0,49}). Auto-derived from name when omitted.
visibilityNoWho sees the project: "space" — every member of the space; "members" — only its members and the space owner. Omitted: the installation default; always members in a personal space.
descriptionNoFree-form project description (markdown).
defaultIdModeNoId-generation mode for issues. Default: counter.counter

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only say it is a non-destructive write; the description goes well beyond that with atomicity semantics (a colliding alias or duplicate name/id_prefix rolls back the entire create), the side effect of the caller becoming owner, server-generated repo ids, and two named failure modes with recovery steps. This is exactly the behavioral context annotations cannot supply.

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?

Front-loaded with the core action and ownership effect, then walks parameters in a logical order and ends on the failure/recovery case an agent most needs. It is dense but nearly every clause carries information; a slight trim would help, but nothing reads as filler.

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 an 8-parameter, no-output-schema creation tool it covers ownership, id generation, atomicity, and space resolution failures. The remaining gap is that with no output schema, the description never indicates what the call returns (the created project's id/short id), which the agent would need for follow-up calls.

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 the schema already carries definitions; the description still adds real meaning: a concrete `idPrefix` example ("demo" yields "demo-42") and auto-derivation fallback, the counter|hash|custom strategy framing for defaultIdMode, and the atomic-insert semantics shared by aliases and gitRepos. Minor gap: visibility (space vs members) is only described in the schema, not the description.

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?

A specific verb+resource ("Create a new project") plus immediate scope facts: the caller becomes initial owner and the record lands inside a space. It is clearly distinguishable from skein_project_list/update by the verb, but it never names or contrasts a sibling explicitly, so it falls short of the top mark.

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?

Strong conditional guidance for the space parameter: omit when exactly one creatable space exists, refusal with `space_required` when several, and `not_space_member` with an explicit remedy (add yourself as member first). It also routes the agent to skein_whoami for space ids. What is missing is any statement of when not to use this tool (e.g. use skein_project_update for changes).

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.