Thread Keeper

Overview Schema Source Related Servers Discussions Admin

skill_manage

Destructive

Create, edit, patch, or delete reusable skills with frontmatter validation. Mirror changes across all configured roots; manage support files and restore trashed skills.

Instructions

Create, edit, patch, or delete skills under the primary skills root.

Atomic primary write with frontmatter validation before disk hits, then best-effort mirror into every configured skill root.

Actions: create — write a brand-new skill. Requires name + description + content (the body markdown WITHOUT frontmatter; the tool prepends a valid frontmatter block). Pass full content starting with '---' to skip the auto-frontmatter and supply your own. edit — overwrite SKILL.md wholesale. Requires name + content (full file including frontmatter). patch — find/replace within SKILL.md. Requires name, old_string, new_string. Result revalidated. write_file — add a support file. Requires name, sub_path (must start with references/, templates/, scripts/, or assets/), content. remove_file — remove a support file under one of the allowed subdirs. Requires name, sub_path. delete — remove a skill entirely. Pinned skills (in skill_usage) are refused. Foreground/unknown-origin skills require force from a foreground writer. Pass replacement_name during consolidation to repoint inbound [[wikilinks]]; otherwise the result lists dangling references. restore — restore the latest trashed copy for name.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`force`	No
`action`	Yes
`source`	No
`content`	No
`sub_path`	No
`new_string`	No
`old_string`	No
`description`	No
`replacement_name`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.19.0Oct 2, 2026
- addedInput schema / properties / source
```
Added value: +{
+  "default": "",
+  "title": "Source",
+  "type": "string"
+}
```

Changed2 schema fields changedv0.17.0Aug 28, 2026

addedInput schema / properties / force

Added value: +{
+  "default": false,
+  "title": "Force",
+  "type": "boolean"
+}

addedInput schema / properties / replacement_name

Added value: +{
+  "default": "",
+  "title": "Replacement Name",
+  "type": "string"
+}

First observedv0.13.2Jun 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds meaningful context on top: frontmatter validation before disk hit, best-effort mirroring into every configured skill root, refusal of pinned skills, and revalidation of patch results. The only gap is that it doesn't clarify whether the mirror step can fail partially without failing the whole call.

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?

The opening lines front-load the core behavior, and the per-action list is scannable with minimal waste. It is somewhat long, but each action line earns its place by stating required parameters; the only minor redundancy is restating content rules across create and edit.

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 10 parameters at 0% schema coverage, a 1-required-param schema, and destructive annotations, this description still covers every operation an agent needs to invoke correctly. An output schema exists, so the absence of return-value detail is appropriate.

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 description coverage is 0%, so the description must carry the load, and it largely does — it maps name, description, content, sub_path, old_string, new_string, force, and replacement_name to the actions that require them, even specifying the allowed subdir prefixes. Only 'source' is left unexplained, which keeps this short of a 5.

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?

The description names specific verbs (create, edit, patch, write_file, remove_file, delete, restore) against a concrete resource (skills under the primary skills root). It is immediately distinguishable from siblings like skill_list, skill_record, and skill_validate, which are not write operations.

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?

Each action carries explicit when-to-use and requirement guidance, e.g. delete states pinned skills are refused, foreground/unknown-origin skills need force, and replacement_name is passed during consolidation to repoint wikilinks. This goes well beyond what the schema or annotations convey.

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

Deploy Server