Skip to main content
Glama

skein_list

Read-onlyIdempotent

Paginated list of issues. BY DEFAULT a page is 25 rows (ceiling 100), and each row is the named lean set — id, title, status, type, priority, assignee, labels, isBlocked, parentIdCurrent, version, updatedAt, childrenCount, unclosedChildrenCount — NOT the issue card: no description, design, acceptance or notes. projectId joins that set in cross-project mode only. Named means named: keys outside the set are ABSENT, componentIds, createdBy, createdAt, acceptedAt, pinned and epicProgress among them — ask for those explicitly with fields (an unknown name is REFUSED and the error names it, so a typo cannot silently widen or empty the row); read one issue whole with skein_show.

Two modes:

  • Project-scoped (default): pass project — paginated list of issues in that one project, with status / priority / assignee / labels / parent / source / text / pinned filters.

  • Cross-project: pass crossProject: true (omit project) — paginated list of every issue visible to the caller across every project they can see. Supports an FTS q over title + description + acceptance + design + notes (with optional semantic rerank when the embedder is available), plus the status / type / origin / assignee / createdBy / acceptedAt filters from the project-scoped path. Returns total (exact count) on every page so the caller knows the visible horizon. The cursor field from the response is opaque; echo it back unchanged on the next call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "skein_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoFull-text search query (cross-project mode only). Matches against title + description + acceptance_criteria + design + notes via tsvector (ru + en). Exact issue id matches (e.g. "demo-2.5") are boosted to the top.
textNoTitle ILIKE filter (substring match). For semantic / FTS search use skein_search.
typeNoSingle type filter (cross-project mode only). One of bug | feature | task | epic | chore | decision | idea | note.
limitNoPage size, 1..100. Default: 25.
spaceNoSpace short id (cross-project mode only): only issues of that space's projects (the space of the issue's project, not of its id prefix). An unknown or unseen space yields nothing. The row's space is the selectable field `spaceId`.
cursorNoOpaque cursor returned by a previous call's `nextCursor` field.
fieldsNoExplicit row field selection for narrow queries. Omit it to get the default named set (identifier, title, status, type, priority, assignee, labels, blocked flag, parent id, version, updated stamp, child counters — plus the project id in cross-project mode). Naming fields returns ONLY those plus the identifier, which always comes back; an empty array therefore yields the identifier alone. An unknown name is rejected and named — it is not ignored, because a silently missing field is indistinguishable from an empty one.
labelsNoFilter by labels (any-of semantics — issues with at least one of these labels).
originNoOrigin group filter (broader than `source`). "human-driven" matches source IN (human, agent_directed); "agent-autonomous" matches source = agent_autonomous; "all" or omitted = no filter. Use this to hide the agent firehose in default board mode.
pinnedNoFilter on the pinned flag.
sortByNoSort axis: "updated" (default) or "created".
sourceNoFilter by origin: human|agent_directed|agent_autonomous. "agent_directed" = agent created on user instruction; "agent_autonomous" = agent self-spawned mid-task.
projectNoProject handle: alias, name, or UUID. Required unless `crossProject` is true.
assigneeNoAssignee filter. Use the literal "me" to match issues assigned to the calling user (resolved via users.id, case-insensitive username join — same path as the Inbox view). Any other string is treated as a free-form username equality match. Whitespace is trimmed. Omitted, null or blank means no filter; non-string values return validation_error with code assignee_not_string.
parentIdNoExact parent id (full hierarchical form, e.g. "demo-42").
priorityNoExact priority match (0..4).
statusesNoFilter by status; any of open|in_progress|deferred|closed|standing. `standing` selects perpetual obligations (excluded from the default active-work counts/lenses). `blocked` is no longer a writable status — use the `isBlocked` filter to narrow to issues derived as blocked from the dep graph. Project-scoped mode accepts multiple values (OR). Cross-project mode accepts at most one entry — e.g. statuses:["open"] only; pass a single status or omit for all.
createdByNoCreated-by filter. "me" selects issues the caller created (Outbox / "tasks I created" view). "not-me" selects issues the caller did NOT create — pairs with assignee=me to surface tasks delegated TO the caller by someone else (the "On me" lens).
isBlockedNoFilter by derived blocked-ness. "true" = only issues with at least one open outgoing blocks/waits-for edge; "false" = only issues with no open blockers. Omit for no filter.
acceptedAtNoAcceptance filter. "null" restricts to issues whose assignee has not yet acknowledged the task (Inbox prefix). "not-null" restricts to issues that have been accepted (the "On me" / accepted-and-working prefix).
crossProjectNoWhen true, list issues across every project the caller can see (visibility-filtered to their project_members horizon; admins see all but other users' personal spaces). `project` MUST be omitted in this mode. Powers the "All projects" view in the web UI.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses page size defaults (25, ceiling 100), the exact default field set, that unknown field names are REFUSED with the name in the error, that non-named keys are absent rather than null, and that the cursor is opaque and must be echoed unchanged. It also notes `total` is returned on every cross-project page.

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 highest-value fact (default lean row set, not the full issue card) before the mode breakdown, with clean two-bullet structure. The capitalized emphasis and dense parentheticals make it longer than strictly necessary, but essentially every sentence carries operational 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 21-parameter tool with no output schema, the description does the heavy lifting on return shape (field set, cursor, cross-project `total`) and mode selection. Minor gap: it does not say whether project-scoped mode also returns a total or what the response envelope looks like beyond cursor.

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 baseline is 3, but the description adds real meaning: the `fields` allowlist/refusal behavior, `projectId` appearing only in cross-project mode, and the cursor echo contract. It doesn't restate per-parameter enum semantics already fully documented in the schema.

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+resource ('Paginated list of issues') and immediately qualifies the two modes and the exact row shape returned, so an agent knows both what it lists and what comes back. It explicitly diverges from skein_show ('read one issue whole with skein_show'), making it distinguishable from the obvious sibling.

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?

The 'Two modes' block gives explicit conditions: project-scoped requires `project`, cross-project requires `crossProject: true` and omitting `project`. It also routes single-issue reads to skein_show. No explicit when-not-to-use for other list-adjacent siblings (skein_ready, skein_search) beyond the schema-level mention.

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.