Used to clone and update the upstream Superpowers skills repository that provides expert-crafted workflows and processes for AI assistants.
Format used for SKILL.md files that define the content and structure of both Superpowers library skills and personal custom skills.
Runtime environment for the MCP server that exposes Superpowers skills library tools for finding and loading AI workflow skills.
Format used in skill file frontmatter to define metadata for custom skills including name and description fields.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Superpowers MCP Server list available skills for refactoring legacy code"
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.
An MCP (Model Context Protocol) server that brings the powerful Superpowers skills library to Augment CLI. Access proven workflows, expert techniques, and best practices directly in your AI coding assistant.
This MCP server exposes the Superpowers skills library as tools that Augment can use. Skills are expert-crafted workflows and processes that guide AI assistants to produce better results.
Available Tools:
find_skills - List all available skills from both the superpowers library and your personal skills
use_skill - Load a specific skill to guide your work
Related MCP server: skill-ninja-mcp-server
git clone https://github.com/jmcdice/superpower-mcp.git
cd superpower-mcp
./install.shThe installer will:
Clone the upstream Superpowers repository to ~/.augment/superpowers
Create a personal skills directory at ~/.augment/skills
Install MCP server dependencies
Provide configuration instructions
Add the MCP server to your Augment configuration file (~/.augment/settings.json):
{
"mcpServers": {
"superpowers": {
"command": "node",
"args": [
"/path/to/superpower-mcp/superpowers-mcp.js"
]
}
}
}Note: Replace /path/to/superpower-mcp/ with the actual path where you cloned this repository. The installer will show you the exact path to use.
Restart Augment to load the new MCP server.
Ask Augment:
"What skills are available?"You should see a list of skills from the Superpowers library.
Ask Augment to list available skills:
"Show me available skills"
"What skills can you use?"Or use the tool directly:
find_skills()Load a skill by name:
"Use the brainstorming skill"
"Load the test-driven-development skill"Or use the tool directly:
use_skill("superpowers:brainstorming")
use_skill("superpowers:test-driven-development")Superpowers skills: superpowers:skill-name (from the upstream repository)
Personal skills: my-skill-name (from ~/.augment/skills/)
Personal skills with the same name as superpowers skills will override them.
Create a directory in ~/.augment/skills/ with your skill name:
mkdir -p ~/.augment/skills/my-custom-skillAdd a SKILL.md file with YAML frontmatter:
---
name: my-custom-skill
description: Use when you need to do something specific
---
# My Custom Skill
## Purpose
[Describe what this skill does]
## When to Use
[Describe when to use this skill]
## Process
1. [Step 1]
2. [Step 2]
3. [Step 3]The skill will automatically be available through find_skills and use_skill
This is an overlay approach that works with the upstream Superpowers repository:
Upstream repository: ~/.augment/superpowers (read-only, updated via git pull)
MCP server: This repository (custom Augment integration)
Personal skills: ~/.augment/skills (your custom skills)
The MCP server reads skills from both the upstream repository and your personal skills directory.
To get the latest skills from the upstream repository:
./install.sh updateThen restart Augment.
./install.sh removeThis will:
Remove the Superpowers repository (~/.augment/superpowers)
Optionally remove your personal skills (~/.augment/skills)
Keep the MCP server files (you can delete them manually if desired)
Don't forget to remove the MCP server configuration from ~/.augment/settings.json and restart Augment.
Check that the path in ~/.augment/settings.json is correct
Verify Node.js is installed: node --version (should be v18+)
Check that dependencies are installed: ls node_modules in the repo directory
Restart Augment completely
Verify the Superpowers repository exists: ls ~/.augment/superpowers/skills
Run ./install.sh update to refresh the repository
Check skill file format (must have YAML frontmatter and be named SKILL.md)
Make sure the install script is executable:
chmod +x install.shSuperpowers Repository: https://github.com/obra/superpowers
Blog Post: Superpowers for Claude Code
Model Context Protocol: https://modelcontextprotocol.io/
Augment: https://www.augmentcode.com/
Issues and pull requests are welcome! This is a community project to make Superpowers accessible to Augment users.
MIT License - See LICENSE file for details
The upstream Superpowers repository has its own license. Please refer to https://github.com/obra/superpowers for details.
Superpowers by Jesse Vincent
MCP Server integration for Augment
List all available skills in the personal and superpowers skill libraries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't mention whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the core functionality without any wasted words. It's appropriately sized for a simple list tool with no parameters, and every element of the sentence contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description adequately covers the basic purpose. However, without annotations or an output schema, it doesn't address important behavioral aspects like authentication requirements, rate limits, or return format. The description is minimally complete but could provide more context about the operation's characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't add parameter information beyond what's in the schema, maintaining focus on the tool's purpose rather than unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and target resources ('all available skills in the personal and superpowers skill libraries'), making the purpose immediately understandable. It doesn't explicitly differentiate from the sibling tool 'use_skill', but the distinction is implied through the different verbs (list vs use).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying what skills are listed (personal and superpowers libraries), suggesting this is for discovery rather than application. However, it doesn't provide explicit guidance on when to choose this over 'use_skill' or any prerequisites for accessing these libraries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load and read a specific skill to guide your work. Skills contain proven workflows, mandatory processes, and expert techniques.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | Name of the skill to load (e.g., "superpowers:brainstorming", "my-custom-skill") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that skills 'guide your work' and contain 'proven workflows, mandatory processes, and expert techniques,' which gives some behavioral context about the content. However, it doesn't disclose critical traits like whether this is a read-only operation, if it requires authentication, what happens on invocation (e.g., if it modifies state), or any rate limits—leaving significant gaps for a tool that loads resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded: the first states the core action, and the second elaborates on what skills contain. There's no wasted text, though it could be slightly more structured (e.g., by explicitly mentioning the parameter).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with full schema coverage and no output schema, the description provides basic purpose and content context. However, for a tool that loads resources to 'guide your work,' it lacks details on what the output entails (e.g., structured data, instructions), behavioral traits, or differentiation from siblings, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'skill_name' fully documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain skill naming conventions or provide examples beyond the schema's 'e.g.'). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Load and read') and resource ('a specific skill'), explaining it provides workflows, processes, and techniques. However, it doesn't explicitly distinguish this from the sibling 'find_skills' tool, which likely searches for skills rather than loading one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating skills 'guide your work' and contain workflows, suggesting this tool is for accessing predefined guidance. However, it doesn't explicitly state when to use this versus 'find_skills' or provide any exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_skillsuse_skillScored across 2 tools
The two tools have clearly distinct purposes: 'find_skills' is for listing available skills, while 'use_skill' is for loading and reading a specific skill. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern with snake_case naming: 'find_skills' and 'use_skill'. The naming is uniform and predictable throughout the set.
With only 2 tools, the server feels thin for a 'Superpowers MCP Server' that implies managing skills and workflows. This minimal set may not adequately cover the domain's potential scope, such as creating, updating, or deleting skills.
The tool set is severely incomplete for skill management. It only supports listing and reading skills, lacking essential CRUD operations like creating, updating, or deleting skills, which are likely needed for a comprehensive skill library system.
Search your team's shared AI-skill library, get install commands, and save skills from your agent.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Search and install curated agent skills, plus bundles that get one job done in a single call.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
