Skip to main content
Glama
Sign In

ChatCut

by io.chatcut
OverviewDiscussionsAdmin

manage_skill

Manage reusable ChatCut workflow skills.

This account tool needs no project. It manages saved Workflow Skills, including catalog skills and user skills shared by ID. ChatCut's built-in capability playbooks (talking-head-guide, motion-graphic-gen, video-gen, ...) are a separate system and will never show up here; their absence from this list does not mean they don't exist.

A workflow skill is a user-visible reusable Claude-style skill package for the agent: goals, context, workflow steps, preferences, rules, quality checks, optional references, examples, and lightweight scripts. It is NOT a brittle tool-parameter template. Do not write low-level tool arguments into a user skill unless the user explicitly owns that stable product concept.

One durable path:

  • DB is the canonical shared store.

  • Sandbox files are temporary drafts or per-turn mounted packages. manage_skill does not install saved Skills into a CLI's user-level Skill directory.

  • To create or update a skill from the ChatCut sandbox, write a Claude-style package there and pass sourceDirectory.

  • From the ChatCut plugin (Codex / Claude Code — no ChatCut sandbox), pass the contents inline as packageFiles instead, and get returns the full package inline for the current turn.

Package shape:

  • Minimum: SKILL.md at the draft root.

  • Optional lightweight files: references/, examples/, scripts/*.

  • Do not include project media asset ids, heavyweight assets, private chat dumps, credentials, or generated media.

  • Total package size must stay under 1 MB.

Actions:

  • list: search skills with source: "mine", "preset", or "all" (default "mine"). Use query for a named Skill. Returns up to limit entries (default 25, max 100), totalMatches, and nextOffset; continue with the same source/query until nextOffset is null.

  • fork: copy a skill by agentSkillId into your account, including its full package and display media. Returns a new independent ID; optional name overrides its name.

  • get: load a skill for use. Your own and catalog skills are returned as they are; another user's shared skill is saved to your account as an independent copy, or your existing copy is reused. Returns the package, materialized to .claude/skills// or inlined on connectors. Use the returned ID for later edits.

  • create_from_directory: create a user skill from a sandbox package directory (sourceDirectory) or from inline contents (packageFiles).

  • update_from_directory: update an owned user skill; pass sourceDirectory (defaults to the location written by get) or inline packageFiles.

  • rename: update user-facing name and optional description/summary only.

  • delete: delete an owned user skill.

Typical create flow:

  1. With a ChatCut workspace, use Write/Edit to prepare a package such as .chatcut/skill-drafts//SKILL.md. Without a ChatCut sandbox (hosted Codex / Claude plugin), prepare packageFiles as a relative-path-to-text object, e.g. { "SKILL.md": "", "references/checklist.md": "" }. Add references/, examples/, or scripts/ only when useful.

  2. Call manage_skill with action: "create_from_directory" and either sourceDirectory or packageFiles, never both. Include name if SKILL.md does not have a clear H1.

  3. After a successful save, recap what was saved and how to reuse it.

Typical update flow:

  1. Call get for the existing skill. Use the returned skill ID for later edits; it may identify your independent copy of another user's shared skill.

  2. With a workspace, edit the materialized package in place. Without a ChatCut sandbox, edit the full returned packageFiles object, retaining unchanged references, examples, and scripts: an update replaces the package.

  3. Call update_from_directory with the returned skill ID and either sourceDirectory (inferred when editing the location written by get) or the complete packageFiles object, never both.

Using skills:

  • When the user provides a shared skill ID, call get directly; unlisted shared skills do not appear in list.

  • Catalog skills are read-only and stay current with catalog updates. When the user wants to change one, fork it and edit the copy. Otherwise use fork only when they explicitly want an additional copy.

  • If the user attached a workflow skill in the composer UI, the backend mounts it as a normal Claude skill package for this turn and tells the agent to load it with the Skill tool before editing.

  • If the user asks in natural language to use a saved or preset skill, call list with the right source and query, then get the matching skill and follow its SKILL.md for the current turn. Do not persist it to the project.

Sharing: user skills are unlisted, but anyone with their full UUID can read and copy them. Share the full UUID returned by this tool; legacy 8-character IDs only resolve within your own skills and the catalog. Only the owner may update, rename, or delete the original. Do not include private transcripts or credentials in reusable packages.

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": "manage_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoUser-facing skill name.
limitNoMaximum list entries returned (default 25, max 100).
queryNoFilter list by words in the Skill name, description, summary, or ID (case-insensitive).
actionNoOne of list, get, fork, create_from_directory, update_from_directory, rename, delete.
offsetNoZero-based list offset. Continue with the returned nextOffset and the same source/query.
sourceNoSkill list source. Default mine.
statusNoSkill status; default active.
summaryNoShort user-facing summary of the workflow.
coverUrlNoCover art for the marketplace card. Must be a ChatCut-hosted URL — upload or generate the image first, then pass the URL it returned.
descriptionNoShort trigger description / when-to-use summary.
previewUrlsNoClips or stills for the detail page, in display order; the first is what the page opens on. Replaces the existing list. ChatCut-hosted URLs only.
agentSkillIdNoFull workflow skill UUID for get/fork/update/rename/delete. Legacy 8-character IDs resolve only within your own skills and the catalog.
packageFilesNoInline package contents for create/update, as { "SKILL.md": "...", "references/x.md": "..." }. Use this instead of sourceDirectory when your files are not in the ChatCut sandbox (e.g. calling from the ChatCut plugin in Codex or Claude Code).
sourceDirectoryNoSandbox directory containing a Claude-style skill package to create/update from.
sourceProjectIdNoProject this skill was distilled from; defaults current.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Goes well beyond the annotations: DB is the canonical shared store, sandbox files are temporary, the 1 MB size cap, the prohibition on credentials and media asset IDs, the fact that update replaces the whole package, and that another user's shared skill becomes an independent copy on get. One tension: annotations declare destructiveHint=false while the description advertises a delete action that removes an owned skill — minor but worth noting for the agent's risk model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Structure is strong (action list, package shape, numbered flows, sharing section), but the text is roughly 700 words and repeats itself: the create and update flows restate the same sourceDirectory/packageFiles rule twice, and the Actions block duplicates the action enum already in the schema. The purpose is front-loaded, but several sentences could be cut without losing information.

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 15-parameter, seven-action tool with no output schema, the description covers what an agent needs: per-action semantics, return essentials (list returns limit/totalMatches/nextOffset; fork returns a new ID; get materializes to .claude/skills/ or inlines on connectors), and sharing/ownership rules. The remaining gaps are error handling and per-action parameter matrices, which are secondary for correct invocation.

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%, so the baseline applies and the description does add real value on the mutual-exclusivity rule ("sourceDirectory or packageFiles, never both"), the packageFiles shape, and pagination continuation via nextOffset. However, several parameters — status, previewUrls, coverUrl, sourceProjectId — are left entirely to the schema, and the description never explains which parameters each action accepts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states a specific verb and resource ("Manage reusable ChatCut workflow skills") and the description defines what a workflow skill is versus a "brittle tool-parameter template." It also draws a clear boundary against the built-in capability playbooks system ("will never show up here"), which is a genuine disambiguation. It does not, however, differentiate itself from nearby account-level siblings such as manage_template, manage_memory, or manage_design_style.

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?

Guidance is explicit at nearly every branch point: when to use list with which source, when to call get directly from a shared ID (unlisted skills don't appear in list), when to fork versus use a catalog skill in place, and when packageFiles replaces sourceDirectory. It also gives two numbered end-to-end flows (create and update) plus a natural-language trigger case, so an agent rarely has to infer.

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

All ChatCut toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources