SKEIN

skein_search

Read-onlyIdempotent

Hybrid search across visible projects (FTS + vector when available, FTS-only when not). BY DEFAULT a page is 25 hits (ceiling 100), and a hit carries a PLAIN snippet — no highlight markup of any kind, so nothing has to be stripped before the text is read or matched. Returns issues, comments, projects, and components by default; narrow with kinds. To read a hit in full, follow its id: skein_show for an issue, skein_comment_get for a comment. Use this for free-form questions / fuzzy matches; use skein_list when you have a specific project + filter combination. Response includes degraded:true for FTS-only ranking.

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

Input Schema

Name	Required	Description
`kinds`	No	Restrict to entity kinds: any of issue\|comment\|project\|component. Default: all four.
`limit`	No	Page size, 1..100. Default: 25.
`query`	Yes	Search query, 1..500 characters.
`space`	No	Optional space short id (from skein_whoami spaces) to scope to one space's projects. Default: every space you see.
`types`	No	Issue type filter.
`cursor`	No	Opaque nextCursor from the same query. Missing pools rebuild at the saved offset and ranking mode. Legacy cursors need a warm pool; unavailable hybrid ranking is refused. On a cursor validation_error, restart without cursor. Data changes may alter later pages.
`labels`	No	Issue label filter (any-of).
`source`	No	Issue origin filter: human\|agent_directed\|agent_autonomous.
`project`	No	Optional project handle (alias\|name\|UUID) to scope to one project. Default: all visible projects.
`statuses`	No	Issue status filter (only honoured when kinds = issue). `standing` selects perpetual obligations. `blocked` is no longer a writable status.
`priorities`	No	Issue priority filter (0..4).
`commentAuthorKinds`	No	Comment author-kind filter (only restricts COMMENT results; any-of). Restricts comments by comments.author_kind — independent of `source`, which filters issues. Does not affect issue/project/component results.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description goes further by disclosing that snippets come back as plain text with no highlight markup, that ranking silently degrades to FTS-only and is reported via `degraded:true`, and that cursors are pool-dependent and may be refused. It stops short of describing result ordering or what a hit payload contains, which keeps it off 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Opens with what the tool is, then defaults, then result shape, then routing to siblings and alternatives. Every sentence carries a fact an agent needs; nothing is padding despite the density.

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?

With no output schema, the description still covers what comes back (issues, comments, projects, components), the degraded-ranking signal, snippet formatting, and pagination failure modes — enough for an agent to call it and interpret results correctly across 12 parameters.

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 carries parameter meaning; the description's page-size default/ceiling and `kinds` narrowing largely restate it. The genuinely additive note is the cursor recovery instruction (restart without cursor on validation_error) and that data changes can shift later pages, but cursor mechanics are also 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 mechanism (hybrid FTS + vector, falling back to FTS-only), the resource (visible projects), and the default result entity set. It also names the sibling it is not (skein_list), so an agent can distinguish the two without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly partitions work: free-form/fuzzy questions go here, specific project + filter combinations go to skein_list. It also gives follow-up routing (skein_show for an issue hit, skein_comment_get for a comment hit), which is the exact next step after a search.

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.