Skip to main content
Glama
Sign In

SKEIN

by net.skein
OverviewDiscussionsAdmin

skein_ready

Read-onlyIdempotent

List unblocked open issues for a project, ordered by priority (P0 first) then most-recently-updated. "Ready" means status=open AND no open blocks/waits-for dependencies. By default — and in every mode, there is no other one — a row is the lean summary: no description, no comments, and two keys missing outright (below). Pair with skein_show on the top hit to start work.

Rows carry NO labels and NO componentIds keys: this query does not load them (the aggregate joins would make it N+1), and returning an empty array would assert that the issue has none. The keys are absent rather than empty so you can tell «not supplied here» from «none». Read both with skein_show on the issue — its card carries them. skein_list carries labels in its default row, but NOT componentIds: there you have to name it, skein_list(fields:["componentIds"]). There is no isBlocked key here either, and that one needs no lookup: every row on this list is unblocked — that is the predicate the list selects on.

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_ready"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoExact issue-type match (bug|feature|task|epic|chore|decision|idea|note).
limitNoPage size, 1..100. Default: 25.
projectYesProject handle: alias, name, or UUID.
assigneeNoExact assignee match; whitespace is trimmed. Omitted, null or blank means no filter; non-string values return validation_error with code assignee_not_string.
priorityMaxNoUpper bound on priority — issues with priority <= N are returned.

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 (which only declare readOnly/idempotent/no-destructive) by disclosing that rows are lean: no description, no comments, and labels/componentIds keys absent rather than empty — with the reason given (aggregate joins would make it N+1). The absent-vs-empty distinction and the note that isBlocked is unnecessary because it is the selection predicate are exactly the kind of behavioral context structured fields cannot convey.

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, predicate and ordering are front-loaded in one sentence, which is correct. The second paragraph is disproportionately long and partly concerns other tools' field behavior (skein_list's fields option), which is useful but drifts away from describing this tool; the parenthetical "By default — and in every mode, there is no other one —" is also clumsier than needed.

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 a read-only list tool with full schema coverage and no output schema, nothing material is missing: the selection predicate, sort order, row shape, which keys are absent and how to retrieve them are all covered, and the annotation-supplied safety profile needs no restating.

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%, so the schema already documents project, type, assignee, limit and priorityMax. The description adds no per-parameter semantics — it mentions priority only as an ordering rule, not as the priorityMax upper-bound filter — so this sits at the baseline.

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?

States a specific verb and resource ("List unblocked open issues for a project") and defines the qualifier precisely: status=open AND no open blocks/waits-for dependencies. It also gives the sort order (priority P0 first, then most-recently-updated), so an agent can distinguish this from the generic skein_list 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 Guidelines4/5

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

Explicitly routes the agent onward — "Pair with skein_show on the top hit to start work" — and names skein_show and skein_list as the places to obtain labels/componentIds. It never states the converse selector ("use skein_list instead when you need all issues, blocked or not"), so the boundary with the sibling list tool is left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SKEIN toolsInspect
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.

Resources