SKEIN

skein_remind

Destructive

Personal reminders on issues — your own alarm clock, invisible to everyone else. When remindAt passes, the scheduler pings you with a bell notification and the issue shows up in your ringing-reminders lens; state is derived from remindAt, armed (future) vs ringing (due), and a past remindAt rings on the next scheduler tick.

Multiple reminders per issue are allowed, so snooze and dismiss need a target: pass reminderId (from set or list), or issueId when you have exactly one active reminder on that issue — with more than one the error lists the candidates and you retry with reminderId. 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>"
    },
    "name": "skein_remind"
  }
}

Input Schema

Name	Required	Description
`by`	No	Only read by snooze: relative offset from now — 1h \| 1d \| 3d \| 5d \| 1w (or the general <n><unit>, unit h\|d\|w). Exactly one of by / until.
`note`	No	Optional free-form text attached to this action: on set it is the new reminder's own note (recorded as last_reason), on dismiss it is recorded on the dismiss event.
`state`	No	Only read by list: filter — ringing \| armed \| all (default all).
`until`	No	Only read by snooze: absolute RFC3339 instant to snooze to. Exactly one of by / until.
`action`	Yes	What to do: - "set" → arm a new reminder on an issue at `remindAt`; each call creates a distinct one. - "list" → your reminders across projects, most urgent first, plus the ringing-task badge count. - "snooze" → push a reminder's ring time forward (`by` or `until`) so it rings again. - "dismiss" → delete a reminder for good; it will never ring again.
`reason`	No	Only read by snooze: optional free-form note, recorded as the reminder's last_reason.
`issueId`	No	Full hierarchical issue id, e.g. "sk-62" or "demo-42". Required for set — the issue the reminder is set on. On snooze and dismiss it is the alternative to `reminderId`: it targets your single active reminder on that issue, and errors with the candidate list when there is more than one.
`project`	No	Only read by list: project handle (alias, name, or UUID) narrowing the returned list; `ringingTaskCount` stays the full cross-project badge.
`remindAt`	No	RFC3339 timestamp at which the reminder should ring, e.g. 2026-06-01T09:00:00Z (stored UTC). Required for set.
`reminderId`	No	Reminder UUID, as returned by set or list. The precise target for snooze and dismiss; supply it instead of issueId.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: reminders are private to the caller, state is derived from remindAt (armed vs ringing), a past remindAt rings on the next scheduler tick, and each set creates a distinct reminder. It also discloses that dismiss is permanent ('will never ring again'), matching the destructiveHint annotation rather than contradicting it.

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?

Two tightly written paragraphs: identity and visibility first, then lifecycle and targeting rules. Dense but every clause carries operational meaning; minor redundancy with the action descriptions in the schema.

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 10-parameter, multi-action tool with no output schema, the description covers the lifecycle, state semantics, targeting/ambiguity resolution, privacy scope, and even what list returns (urgency order, ringing badge count). An agent can invoke any action correctly without further context.

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 coverage is 100% and each parameter already carries a 'Only read by <action>' description, so the description's parameter talk largely restates the schema. The one genuine addition is the cross-parameter rule governing reminderId vs issueId when multiple reminders exist, which the per-parameter schema cannot express on its own.

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 ('Personal reminders on issues') plus a scope differentiator ('your own alarm clock, invisible to everyone else') that separates it from shared notification surfaces like skein_notifications. The action set (set/list/snooze/dismiss) is enumerated so an agent knows the tool's full surface immediately.

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 clear conditions for each action, including retry guidance when multiple reminders make issueId ambiguous ('the error lists the candidates and you retry with reminderId') and the note that list is read-only. It stops short of naming when to prefer this over a sibling notification tool, but the internal when-to-use guidance is explicit.

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.