Skip to main content
Glama

skein_component

Components of a project — sub-units such as a microservice, a module or an area of code, which issues are attached to so search and reports can group work. Call action="list" before skein_create to pick the right componentIds. Writing (create / update / archive) is for the project owner, space owner or instance admin; archiving is soft and reversible with archived=false. 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_component"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoComponent UUID, as returned by list or create. Required for update and archive.
nameNoComponent name, unique within the project (case-sensitive). Required for create; on update, omit to leave the name unchanged.
actionYesWhat to do: - "list" → the project's components, filtered by `archivedFilter`, plus `archivedCount` — how many of the project's components are archived, so an empty `items` tells "no components at all" (0) apart from "all of them are archived" (>0) without a second call. - "create" → add a component; name must be unique within the project. - "update" → rename a component or replace its description. - "archive" → soft-archive a component, or unarchive it with archived=false.
projectYesProject handle: alias, name, or UUID. Required for every action.
archivedNoOnly read by archive: true → archive (default), false → unarchive. Re-archiving an already-archived component is a no-op that returns the current state.
descriptionNoFree-form component description (markdown). Optional on create; on update, omit to leave it unchanged or pass an empty string to clear it.
archivedFilterNoOnly read by list: which rows to return — "false" (default: active only), "true" (archived only), or "all".false

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only flag non-read-only, non-destructive, non-idempotent; the description adds material behavior the annotations cannot express: which roles may write (project owner, space owner, instance admin), that archiving is a soft and reversible state change, and that 'list' is the one read-only action. It does not discuss failure modes such as duplicate-name errors or permission-denied responses, so it falls short of a 5.

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 resource definition, then the prerequisite ordering, then the write/permission and reversibility facts — a sensible priority order with no filler. Slightly dense in the final sentence, but every clause carries distinct information.

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 seven-parameter, four-action tool with no output schema, the definition covers the essentials an agent needs: what a component is, how to obtain IDs before mutation, who may write, and that archiving is reversible. Return-value shape is left to the schema's action descriptions, which is acceptable, though nothing is said about error behavior on duplicate names.

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 the schema already documents `archived` vs `archivedFilter` scoping per action, so baseline is 3. The description adds only a light cross-action hint (fetch `componentIds` via list before create); it does not extend the semantics of `archivedFilter`, `archived`, or `description` beyond what the schema states.

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?

The first sentence defines the resource concretely (sub-units like a microservice, module, or code area) and states its role in the system (a grouping target for issues, search, reports). The four supported actions are named in the third sentence. It stops short of distinguishing this tool's scope from adjacent project-level tools, but an agent can tell what it manipulates.

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 an explicit ordering rule — call action="list" before skein_create to obtain valid `componentIds` — and states the permission condition under which writes are allowed. It does not state when a caller should not use this tool (e.g. project-level operations belong elsewhere), but usage context is clear for a mixed read/write tool.

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.