SKEIN

skein_project_list

Read-onlyIdempotent

List projects visible to the calling user. BY DEFAULT a page is 50 rows (ceiling 100), and each row's description is cut to the first 200 characters. When a description was actually cut the row carries descriptionTruncated: true; a short or empty description carries no such key, so the marker means «there is more», never «this might be all». The full text is not reachable through any MCP tool today — this list is the only MCP surface that renders it — so treat the preview as the orientation aid it is and open the project in the web UI when you need the whole thing.

Useful for orientation when an agent doesn't yet know the project handle. Pair with skein_project_resolve when the user types a fuzzy name. Honours archived to include archived projects in the result. When q is set, items are ordered by relevance score (FTS + optional semantic rerank) instead of recency.

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

Input Schema

Name	Required	Description
`q`	No	Optional free-form search query. Matches against project name, description (Russian + English FTS), idPrefix, and aliases. When set, results are ordered by relevance score; cursor pagination still works across pages.
`limit`	No	Page size, 1..100. Default: 50.
`cursor`	No	Opaque cursor returned by a previous call's `nextCursor` field.
`archived`	No	Include archived projects. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare the safe read profile; the description adds substantial operational detail beyond that: default page of 50 with a 100 ceiling, per-row `description` truncated to 200 characters, the exact semantics of `descriptionTruncated` (present means there is more, absent never means complete), and the fact that full text is unreachable through any MCP tool. It also discloses that ordering flips to relevance when `q` is set.

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-loads purpose, then pagination/truncation, then usage guidance, which is a sensible order. The truncation passage is the longest section and carries a slightly redundant emphatic gloss ("never «this might be all»") plus a web-UI aside, costing a bit of economy but not clarity.

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?

With no output schema, the description carries the burden of explaining returns and does so for the notable parts: row descriptions, the truncation marker, and page sizing with cursor continuity. The remaining row fields are not enumerated, but nothing an agent needs in order to call the tool correctly is missing.

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 meaning on top: it explains that `q` triggers relevance ordering (FTS plus optional semantic rerank) rather than recency, and that `archived` is honoured to include archived projects. `limit` and `cursor` behaviour is largely left to the already-explicit 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?

Opens with a specific verb+resource and scope: "List projects visible to the calling user." It also distinguishes itself from the closest sibling by noting it pairs with skein_project_resolve for fuzzy names, so an agent can separate the two 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?

"Useful for orientation when an agent doesn't yet know the project handle" gives a concrete when-to-use condition, and the pairing with skein_project_resolve covers the fuzzy-name case. There is no explicit when-not-to-use or statement about other list surfaces, but the context is clear enough to route correctly.

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.