How do I use SkillForge?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SkillForge save a skill: always use f-strings in Python" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SkillForge

by CatVinci-Studio

Overview Schema Related Servers Score Discussions

Python

Local

✨ What is SkillForge?

SkillForge is a Model Context Protocol (MCP) server that gives your AI agent a persistent, evolving skill library. Instead of repeating the same corrections and preferences every session, SkillForge captures them as skills — structured instructions that the agent loads and follows automatically.

💡 Think of it as muscle memory for your AI — it learns your conventions once and applies them forever.

🔄 The Feedback Loop

  👤 User gives feedback
        │
        ▼
  🔍 Agent detects improvement signal
        │
        ▼
  🔀 Triage: reuse / improve / create?
        │
        ▼
  ✏️ Draft skill following guide + plan
        │
        ▼
  🛡️ Validation gate (reject or pass)
        │
        ▼
  💾 Skill saved (auto-backed up)
        │
        ▼
  ✅ Next task uses improved skill

Related MCP server: mcp_coordinator

🚀 Quick Start

📦 Installation

# Install from PyPI (recommended)
pip install skillforge-mcp

# Or with uv
uv pip install skillforge-mcp

⚡ Run the Server

# Run directly
skillforge

# Or run without installing via uvx
uvx skillforge-mcp

🔌 Connect to Claude Code

Add to your MCP config:

{
  "mcpServers": {
    "skillforge": {
      "command": "uvx",
      "args": ["skillforge-mcp"]
    }
  }
}

git clone https://github.com/CatVinci-Studio/skillForge.git
cd skillForge
pip install -e .

🧩 Architecture

src/skillforge/
├── 🏠 server.py              # MCP server definition & prompts
├── 📨 response.py            # Response formatting & feedback monitor
├── 🛡️ validator.py           # Hard validation gates for skill quality
├── 📁 skill_manager.py       # Core CRUD, backup, restore logic
├── 🔧 tools/
│   ├── 🔍 discovery.py       # list_skills, get_skill
│   ├── ✏️  crud.py            # save_skill (with validation), delete_skill
│   ├── 💾 backup.py          # list_backups, restore_skill
│   ├── 🔀 triage.py          # triage_skill_request
│   └── 🧠 optimization.py    # get_skill_guide, request_skill_optimization
└── 📖 guide/
    └── skill_writing_guide.md # Best practices for skill authoring

📂 Runtime Data

SkillForge stores its data in ~/.skillforge/:

Directory	Purpose
`~/.skillforge/skills/`	📚 Active skill library
`~/.skillforge/backups/`	🗄️ Automatic version history

🔒 Override with SKILLFORGE_SKILLS_DIR and SKILLFORGE_BACKUP_DIR environment variables.

🔧 Available Tools

Tool	Description
🔍 `list_skills`	List all skills — mandatory first call before any task
📖 `get_skill`	Load full skill instructions by name
🔀 `triage_skill_request`	Check existing skills before creating/improving — prevents duplication
🧠 `request_skill_optimization`	Get a structured plan for skill improvement
📖 `get_skill_guide`	Load the skill writing best practices guide
✏️ `save_skill`	Create or update a skill — validates and rejects if quality is insufficient
🗑️ `delete_skill`	Remove a skill (two-step confirmation, auto-backup)
📋 `list_backups`	View version history for a skill
⏪ `restore_skill`	Roll back to a previous version
📊 `get_optimization_history`	View the feedback log that drove skill changes

🛡️ Quality Gates (v0.2.0)

Unlike prompt-based quality control that depends on LLM compliance, SkillForge enforces quality through hard validation gates in save_skill:

Check	Type	Rule
📏 Description length	❌ Error	Must be ≥ 50 characters
📏 Body length	❌ Error	Must be 3–500 lines
🔄 Description ≠ name	❌ Error	Description must explain, not repeat the name
🎯 Trigger conditions	⚠️ Warning	Should include "when/whenever/use this skill..."
🗣️ Rigid language	⚠️ Warning	Prefer reasoning over "YOU MUST ALWAYS" imperatives
📐 Description too long	⚠️ Warning	Keep under 1000 chars, move details to body

🔴 Errors block the save — fix them and retry. 🟡 Warnings allow the save but flag areas for improvement.

🔀 Skill Triage

Before creating a new skill, triage_skill_request returns all existing skills so the LLM can decide:

Decision	Condition	Action
REUSE	Existing skill covers the need	Load it with `get_skill`
IMPROVE	Existing skill partially covers it	Optimize with `request_skill_optimization`
CREATE	No relevant skill exists	Create via `request_skill_optimization`

📝 Skill Format

Each skill lives in its own directory as a SKILL.md file with YAML frontmatter:

---
name: my-skill
description: >
  What this skill does and when to trigger it.
  Use this skill whenever the user asks for...
  Also activate when...
---

# Skill Instructions

Your markdown instructions here...

🏷️ Frontmatter Fields

Field	Required	Description
`name`	✅	Identifier (`lowercase-with-hyphens`, max 64 chars)
`description`	✅	Trigger conditions — WHAT it does + WHEN to use it (≥ 50 chars)
`disable-model-invocation`	❌	`true` = only user can invoke
`user-invocable`	❌	`false` = only LLM can invoke
`allowed-tools`	❌	Tools allowed without per-use approval
`context`	❌	`fork` = run in isolated sub-agent

🧠 How Optimization Works

SkillForge continuously monitors conversations for improvement signals:

Signal	Example	Action
🔴 Correction	"No, don't mock the database"	Update relevant skill
🟡 Preference	"Always use snake_case"	Create or update skill
🔵 Pattern	Same structure used 3+ times	Bundle into new skill
🟢 Explicit	"Add this to the review skill"	Direct skill edit

🔒 Safety Guarantees

✅ Auto-backup before every save and delete
✅ One-click restore from any backup timestamp
✅ Path traversal protection on all file operations
✅ Atomic writes with file locking for optimization logs
✅ Hard validation gates — quality enforced at the tool boundary, not by prompt

🌟 Why SkillForge?

Without SkillForge	With SkillForge
😤 Repeat the same corrections every session	🧠 Agent remembers and applies automatically
📋 Conventions scattered across docs	📦 Single source of truth per topic
🎲 Inconsistent agent behavior	✅ Deterministic, skill-guided responses
🔄 No learning from feedback	📈 Skills evolve with every interaction
🤞 Hope the LLM follows quality guidelines	🛡️ Hard validation rejects low-quality skills

🛣️ Roadmap

🛡️ Hard validation gates for skill quality
🔀 Skill triage to prevent duplication
🌐 Skill sharing & import from remote repositories
📊 Analytics dashboard for skill usage & effectiveness
🔗 Cross-skill dependency management
🧪 Skill testing framework with evaluation harness
🏪 Community skill marketplace

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

📄 License

This project is licensed under the MIT License — see the LICENSE file for details.

Available Tools

10 tools

delete_skillA

Delete a skill permanently. Auto-backs up before deletion.

This is a destructive operation — the skill will be removed from the active library. A backup is always created so it can be restored later if needed.

Args: name: Skill identifier to delete. confirm: Must be True to actually delete. This two-step confirmation prevents accidental deletions.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`confirm`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full weight. It discloses destructive behavior, permanent removal, automatic backup, and the need for explicit confirmation. This is comprehensive.

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?

Four sentences including an Args section. Each sentence adds value: action, destructiveness warning, backup detail, and parameter explanation. No fluff.

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?

The description covers the tool's purpose, parameters, and behavior. While an output schema exists, the description could mention what is returned (e.g., success status). Also, the backup restoration process is not detailed, but sibling tools cover that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaning to both parameters: 'name' as identifier and 'confirm' as mandatory True for deletion. This fully compensates for lacking schema descriptions.

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 clearly states 'Delete a skill permanently' and mentions auto-backup. It distinguishes itself from sibling tools like save_skill and restore_skill by indicating it is for removal.

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?

The description implies use for permanent deletion and notes the two-step confirmation to prevent accidents. However, it does not explicitly state when to use this tool versus alternatives like restoring or disabling a skill.

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

get_optimization_historyA

View the optimization history for a skill.

Use this to understand how a skill has evolved over time and what feedback drove each change. Helpful before making further edits to avoid reverting previous improvements.

Args: skill_name: The skill to check.

ParametersJSON Schema

Name	Required	Description	Default
`skill_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'view' (implied read-only) but omits any details about permissions, data freshness, side effects, or output format. This is insufficient for a full transparency assessment.

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 description is concise, with a clear purpose statement and usage guideline in two sentences, followed by an args list. It is well-structured and front-loaded, though the args section is minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and existing output schema, the description covers the main purpose and usage context. However, it lacks behavioral details (e.g., permissions, output summary) and does not leverage the presence of an output schema to reduce the need for description.

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?

There is only one parameter, skill_name, and the description adds meaningful context: 'The skill to check.' This goes beyond the schema's minimal 'Skill Name' label, clarifying its role in the context of optimization history.

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 clearly states the tool's purpose: 'View the optimization history for a skill.' It elaborates on what that entails (how skill has evolved, feedback) and distinguishes it from siblings like request_skill_optimization and get_skill.

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?

The description explicitly advises using this tool before making edits to avoid reverting improvements, providing clear when-to-use guidance. It does not list when not to use or name alternatives, but the context is helpful.

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

get_skillA

Read the full content of a skill.

Call this to load a skill's complete instructions before executing a task in that skill's domain. The returned body contains actionable guidelines — treat them as project-level requirements, not suggestions.

Args: name: The skill identifier (directory name).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, but description indicates a read operation. It adds context that the body contains actionable guidelines treated as requirements, but does not discuss side effects, auth, or rate limits.

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?

The description is concise with three sentences and a simple args list, front-loading the action and avoiding unnecessary detail.

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?

For a simple read tool with an output schema, the description covers essential behavior and parameter meaning. Lacks error conditions, but is adequate overall.

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 0%, but the description's Args section explains that 'name' is the skill identifier (directory name), adding meaning beyond the schema's bare type.

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 clearly states it reads the full content of a skill, distinguishing it from siblings like get_skill_guide by emphasizing 'complete instructions' and 'full content'.

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?

The description explicitly says 'Call this to load a skill's complete instructions before executing a task', providing clear context for usage, but lacks explicit exclusions or alternatives.

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

get_skill_guideA

Get the Skill Writing & Optimization Guide.

Call this BEFORE creating or modifying any skill. It covers: file format, writing principles, description optimization, and iterative improvement.

WHY: Skills that ignore the guide tend to be either too rigid (walls of MUST/NEVER) or too vague (no actionable instructions). The guide teaches how to write skills that actually help.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the tool is a read-only guide retrieval, which is implied. Adding explicit mention of no side effects would improve clarity, but current description is sufficient.

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?

The description is concise, with only a few sentences front-loaded with the main purpose and usage. Every sentence adds value, with no redundant 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?

Given zero parameters and an output schema (indicated as present), the description fully covers the tool's purpose and usage context. No additional information is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and description adds no parameter details, which is appropriate. Schema coverage is 100%, and the description's purpose is clear without needing parameter explanations.

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 clearly states the tool retrieves the Skill Writing & Optimization Guide, listing specific topics covered (file format, writing principles, etc.). This distinguishes it from siblings like save_skill or delete_skill.

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 instructs to call this BEFORE creating or modifying any skill, providing a clear when-to-use context. It also explains why by highlighting common pitfalls, effectively guiding usage relative to sibling tools.

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

list_backupsA

List all backups for a skill, newest first.

Use this to inspect version history before restoring or to verify that a backup was created after a save/delete operation.

Args: name: The skill identifier.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only status, side effects, or performance implications. While listing backups is inherently non-destructive, the description fails to explicitly state this or any limitations.

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 description is short and front-loaded with the core action. The 'Args:' section is slightly redundant but does not significantly hinder conciseness. Every sentence earns its place.

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?

Given the tool's simplicity and the presence of an output schema, the description provides essential context (newest first, usage before restore/save). It covers the key aspects for an agent to decide when to use it.

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?

The description adds meaning to the only parameter 'name' by stating it is 'The skill identifier', which compensates for the 0% schema coverage. This helps the agent understand what value to provide.

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 clearly states the tool lists all backups for a skill, ordered newest first. This is a specific verb-resource combination that distinguishes it from siblings like save_skill or restore_skill.

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?

The description explicitly tells when to use the tool: 'inspect version history before restoring' or 'verify a backup was created after a save/delete operation'. It does not mention alternatives but provides clear use cases.

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

list_skillsA

🔴 MANDATORY FIRST CALL — Call this before starting ANY task.

Returns all available skills with name and description. Review each description — if relevant to your current task, call get_skill to load full instructions.

WHY: Skills encode hard-won conventions and user preferences. Skipping this step means you will miss domain-specific guidance and repeat mistakes that have already been corrected.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It describes a read-only operation returning skill names and descriptions, with no side effects. Lacks details on rate limits or authentication, but for a simple list call, this is adequate.

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?

Six sentences with emoji and emphasis. Front-loaded with mandatory call. Every sentence adds value, though could be slightly more terse. Overall efficient and well-structured.

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?

Zero parameters, output schema exists, and siblings listed. Description fully covers why to call, what it returns, and what action to take next. No gaps given the tool's simplicity.

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?

No parameters exist; schema coverage is 100%. Description adds no param info because none needed. Baseline of 4 for zero parameters is appropriate.

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 clearly states the tool returns all available skills with name and description, and emphasizes it's a mandatory first call. It distinguishes itself from the sibling get_skill by directing users to call that for full instructions.

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 states 'MANDATORY FIRST CALL — Call this before starting ANY task.' Provides clear context for when to use (always first) and directs to get_skill for relevant skills. Explains WHY to skip would cause missing guidance.

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

request_skill_optimizationA

Prepare and return a structured optimization plan for a skill.

Call this when user feedback indicates a skill needs improvement or a new skill should be created. Returns a step-by-step plan that you can follow directly — no sub-agent required.

Recommended workflow:

Call triage_skill_request first to check for existing skills
Call this tool to get the optimization plan
Call get_skill_guide to understand writing best practices
Draft the skill content following the plan and guide
Call save_skill — it will validate and reject if quality is insufficient

Trigger signals to watch for:

User corrects your approach → existing skill may need updating
User states a preference ('always X', 'never Y') → skill candidate
Repeated pattern across conversation → new skill candidate
User explicitly mentions skills → act immediately

Args: skill_name: Which skill to optimize (or create if it doesn't exist). feedback: The user feedback that triggered this optimization. context: Optional additional context about what went wrong or what the user expects.

ParametersJSON Schema

Name	Required	Description	Default
`skill_name`	Yes
`feedback`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It states the tool returns a plan and can be followed directly, but does not explicitly confirm that it makes no modifications or that it is read-only. This leaves slight ambiguity, though the 'prepare and return' phrasing implies a non-destructive operation.

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?

The description is well-structured with a one-sentence purpose, followed by usage guidelines, workflow steps, trigger signals, and parameter descriptions. Every sentence adds value, and the most critical information is front-loaded.

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?

Given the complexity (3 parameters, no annotations, but an output schema exists), the description provides a complete picture: it explains the tool's output (a step-by-step plan), the recommended workflow including pre- and post-steps, and trigger signals. The existence of an output schema reduces the need to detail return values, but the description still conveys the nature of the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% parameter description coverage, but the description adds thorough explanations for all three parameters: skill_name (optimize or create), feedback (triggering input), and context (optional details). This fully compensates for the schema gap.

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 clearly states 'Prepare and return a structured optimization plan for a skill.' It differentiates from siblings by providing a workflow that involves triage_skill_request and save_skill, making the tool's role distinct.

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?

The description explicitly says 'Call this when user feedback indicates a skill needs improvement or a new skill should be created.' It also provides a recommended workflow and lists trigger signals, giving clear guidance on when to use the tool and what to do before/after.

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

restore_skillA

Restore a skill from a specific backup. Current version is backed up first.

Use this when a skill optimization went wrong and you need to roll back. The current version is always saved before overwriting, so no data is lost.

Args: name: The skill identifier. timestamp: Backup timestamp (from list_backups output).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`timestamp`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Discloses that the current version is backed up before overwriting, ensuring no data loss. With no annotations, this is valuable but doesn't cover all edge cases (e.g., invalid timestamp).

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?

Concise, well-structured with separate usage guidance and parameter descriptions. No extraneous text.

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?

Covers purpose, behavior, usage, and parameters adequately. Has output schema, so return values don't need description. Minor gap: no mention of failure scenarios.

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?

Adds meaning beyond schema: timestamp is explicitly noted as coming from list_backups output. Schema coverage is 0%, so description compensates well, but name parameter lacks format details.

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 clearly states 'Restore a skill from a specific backup' and mentions the backup-first behavior, distinguishing it from sibling tools like list_backups and delete_skill.

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?

Provides explicit when-to-use: 'when a skill optimization went wrong and you need to roll back.' Does not state when-not-to or alternatives, but context is clear enough.

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

save_skillA

Create or update a skill. Validates before saving, auto-backs up before overwrite.

This tool enforces quality gates — if the skill fails validation, it will be REJECTED with specific error messages explaining what to fix. Fix the issues and call save_skill again.

Validation checks:

Description must be >= 50 chars and explain WHAT + WHEN
Body must be 3-500 lines of actionable instructions
Description should include trigger conditions
Body should avoid overly rigid language (explain WHY instead)

Args: name: Skill identifier (lowercase, hyphens, max 64 chars). description: What the skill does and when to trigger (>= 50 chars). Front-load the key use case. Include trigger conditions like 'Use this skill when...' or 'Activate whenever...'. body: Markdown body (3-500 lines). Follow the skill writing guide. extra_frontmatter: Optional JSON of additional frontmatter fields.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`description`	Yes
`body`	Yes
`extra_frontmatter`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Discloses validation, auto-backup, rejection with errors. Without annotations, description carries burden; it's fairly transparent but lacks some details on overwrite reversibility.

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?

Well-structured with bullet points and args list. Slightly verbose but efficient overall. Could trim redundant phrasing.

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?

Covers validation, error handling, and parameter details. Output schema exists but description doesn't reference return values; still adequate for tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description fully compensates: explains name format, description length/content, body lines, extra_frontmatter usage. Adds significant meaning.

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?

Clearly states 'Create or update a skill.' and elaborates on validation and backup. Distinguishes from siblings like delete_skill, get_skill, etc.

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?

Explains when to use (create/update), validation checks, and retry on rejection. No explicit 'when not to use' but context is clear.

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

triage_skill_requestA

Analyze intent against existing skills to decide the best action.

Call this BEFORE creating or optimizing a skill. It returns all existing skills with their descriptions so you can determine:

REUSE: An existing skill already covers this need (match >= 80%). → Just call get_skill to load it.
IMPROVE: An existing skill partially covers this (match 50-79%). → Call request_skill_optimization with the existing skill name.
CREATE: No existing skill is relevant (match < 50%). → Call request_skill_optimization with a new skill name.

You (the LLM) make the routing decision — this tool provides the information you need to decide.

Args: intent: What the user wants or the feedback that triggered this. Be specific — include the domain, task type, and context.

ParametersJSON Schema

Name	Required	Description	Default
`intent`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

No annotations are provided, but the description fully discloses that the tool returns all existing skills with descriptions to inform decision-making. It clarifies that the LLM makes the routing decision, and there is no indication of destructive side effects.

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?

The description is well-structured with bullet points, bold text for key actions, and front-loaded with the primary purpose. Every sentence adds value, and the overall length is appropriate for the complexity of the routing logic.

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?

Given the tool's triage role, the description fully explains what it returns (list of existing skills with descriptions) and how to use the result. The presence of an output schema is noted, and the description provides sufficient context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by providing a detailed explanation of the 'intent' parameter, including what to include (domain, task type, context) and why specificity matters. This adds significant meaning beyond the bare 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?

The description clearly states the tool's purpose: analyzing intent against existing skills to decide the best action (reuse, improve, create). It distinguishes itself from sibling tools like get_skill and request_skill_optimization by specifying when each should be used.

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 instructs to call this BEFORE creating or optimizing a skill. Provides clear routing logic with match thresholds (>=80%, 50-79%, <50%) and names the specific sibling tools to invoke for each case.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.2.0May 30, 2026
- First observeddelete_skill
- First observedget_optimization_history
- First observedget_skill
- First observedget_skill_guide
- First observedlist_backups
- First observedlist_skills
- First observedrequest_skill_optimization
- First observedrestore_skill
- First observedsave_skill
- First observedtriage_skill_request

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clear, unique purpose. For example, get_skill retrieves full skill content, get_skill_guide provides the writing guide, triage_skill_request analyzes intent, and request_skill_optimization creates an optimization plan. No two tools overlap in function.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., delete_skill, get_optimization_history, list_skills). The naming style is uniform and predictable across the entire set.

Tool Count5/5

With 10 tools, the server covers the full skill management lifecycle without being excessive. Each tool earns its place, and the count feels balanced for the domain.

Completeness5/5

The tool set covers the complete lifecycle: listing, reading, creating/updating (save), deleting, restoring, triaging, optimizing, and reviewing history/backups. There are no obvious gaps for a skill management system.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2

Related MCP Servers

cell-mem
Knowledge & Memory Autonomous Agents
Aether-liusiqi
A
license
Not graded
quality
D
maintenance
An MCP server that provides AI agents with persistent, multi-layered memory inspired by the human brain, including consolidation, self-reflection, and generative replay.
Updated 3 months ago (2026-06-09 07:48 UTC)
1
MIT
mcp_coordinator
Coding Agents Autonomous Agents Code Execution
angrysky56
A
license
Not graded
quality
D
maintenance
A self-improving coding agent MCP server that enables code execution, semantic memory, and reusable skills via sub-agents, turning your AI client into a meta-operating system.
Updated 4 months ago (2026-05-05 09:13 UTC)
2
AGPL 3.0
MCP Agent Skills Server
Code Execution Autonomous Agents Command Line
sqweeet
A
license
Not graded
quality
D
maintenance
A production-ready MCP server that equips AI agents with dynamic, persistent, and executable skills. It enables secure script execution and progressive disclosure to reduce context window usage.
Updated 9 months ago (2025-12-20 13:17 UTC)
18
MIT
local-agent-context
Knowledge & Memory Developer Tools
TomiwaPhilip
A
license
Not graded
quality
D
maintenance
A local MCP server that gives AI coding agents persistent memory and context across sessions.
Updated 5 months ago (2026-03-27 06:15 UTC)
13
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CatVinci-Studio/skillForge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server