SkillPort: a package manager and MCP server for Agent Skills
Bring Agent Skills to Any AI Agent and Coding Agent — via CLI or MCP. Manage once, serve anywhere.
At a glance
- What is it?
- SkillPort wraps the Agent Skills specification in an install, validate and serve pipeline, with a search-first MCP mode for clients that have no native skill support. Its value depends on whether you actually have more skills than an agent can hold in context.
- Who is it for?
- Adopt SkillPort if you keep a shared skill library across several agents and need one install path plus a CI validation gate. Skip it if you have a handful of skills in one repository, since the CLI mode alone does not earn a new dependency.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 84 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap SkillPort fills between a skill file and an agent that can read it
An Agent Skills package is a directory with a SKILL.md file carrying YAML frontmatter. That format is portable. The delivery mechanism is not. Cursor, Copilot, Windsurf, Cline and Codex each load context differently, and some of them have no native notion of a skill directory at all. The README frames the problem in a table: when you use a coding agent without native skill support, SkillPort serves via MCP or CLI; when you build your own agent, it provides an MCP server, a CLI and a Python library. The audience is therefore teams that maintain a skill set as a shared asset rather than as per-editor prompt files. A second audience appears in the same table: anyone with 50 or more skills who needs to find the right one quickly. That number is the project's own framing of when search-first loading starts to matter.
Search-first MCP: metadata in context, instructions on demand
The MCP server exposes two tools. search_skills(query) does a full-text search over skill descriptions. load_skill(skill_id) returns the full instructions plus a path. The README states the reason: with 50 or more skills, loading everything upfront consumes context and hurts accuracy, so SkillPort loads metadata only, at roughly 100 tokens per skill, and pulls full instructions when a skill is selected. The README attributes the pattern to Anthropic's Tool Search Tool write-up. This is the one design decision in the project with a measurable cost model, and it is the reason to prefer MCP mode over simply dumping every SKILL.md into a system prompt. Note the trade-off: search quality now depends on how well each skill's description is written, because a skill with a vague description will not be surfaced by search_skills even though it exists on disk. The project ships a validate command that checks spec compliance, but a description that passes validation can still be too generic to match a real query.
CLI mode: AGENTS.md as the index, skillport show as the loader
For agents with shell access, the README describes a three-step flow. skillport doc generates a skill table inside AGENTS.md. The agent reads that file to discover what is available. When a skill is needed, the agent runs skillport show <id> to load the full instructions. No MCP configuration is involved, and setup is per project. This is a lighter mechanism than the MCP server, and it inherits the agent's existing file-reading behaviour instead of adding a protocol. The cost is that the agent must be willing to run a shell command mid-task, and the skill table in AGENTS.md is a generated artifact that has to be regenerated when the skill set changes. Nothing in the README indicates that skillport doc runs automatically, so treat it as a step you re-run after skillport add, skillport update or skillport remove.
Install, add, validate: the commands you actually type
Installation is a single tool install, either uv tool install skillport or pip install skillport. The MCP server is a separate package, uv tool install skillport-mcp, and the README's client config runs it through uvx with SKILLPORT_SKILLS_DIR set to ~/.skillport/skills. Skills come in through skillport add, which accepts a GitHub shorthand such as anthropics/skills skills, a full tree URL, a local path, or a zip file. A global flag changes the target directory: skillport --skills-dir .claude/skills add anthropics/skills skills. Validation is skillport validate, with an optional path argument and a --json flag described as CI-friendly. The README shows the success output as a line reading that all five skills pass validation. Lifecycle commands are skillport update, skillport list and skillport remove <skill-id>. Metadata can be edited without touching files through skillport meta get, meta set and meta unset. The README does not document exit codes for validate, so if you wire it into CI, confirm the failure behaviour yourself rather than assuming a non-zero status on a spec violation.
Configuration variables and per-client skill filtering
Five environment variables are documented. SKILLPORT_SKILLS_DIR sets the skills directory and defaults to ~/.skillport/skills. SKILLPORT_ENABLED_CATEGORIES, SKILLPORT_ENABLED_SKILLS and SKILLPORT_ENABLED_NAMESPACES filter what the server exposes, each defaulting to all. SKILLPORT_CORE_SKILLS_MODE controls Core Skills behaviour and accepts auto, explicit or none, defaulting to auto. The README's example registers two MCP servers in the same client, one with SKILLPORT_ENABLED_CATEGORIES set to development,testing and another with writing,research. That is the practical use of the filtering: a single skill library, sliced differently per agent. Categories and tags come from frontmatter under a metadata.skillport block, with keys category, tags and alwaysApply. The README does not explain how auto resolves which skills count as core, and that is the configuration detail most likely to surprise you in a multi-agent setup, since an alwaysApply skill exposed to every client is exactly the kind of context bloat the search-first design tries to avoid.
Where SkillPort is the wrong tool
If your skills live in one repository and one agent reads them, the CLI mode adds a Python dependency and an AGENTS.md generation step to solve a problem you do not have. Copying a SKILL.md into the directory your agent already scans is fewer moving parts. The MCP mode has a sharper constraint: it only helps clients that speak MCP, and the README lists Cursor, Copilot, Windsurf, Cline, Codex and any MCP-compatible client. An agent that cannot launch a subprocess and cannot speak MCP is out of scope entirely. There is also a search-quality dependency described above: SkillPort does not summarise or rewrite your skill descriptions, so a poorly written library stays poorly discoverable no matter how many skills you install. And because skillport add records original sources for skillport update, a skill installed from a local path or a zip has no upstream to update from, which the README does not address.
How this differs from vendoring skills into each agent's own directory
The direct alternative is per-client skill directories: place the files where Cursor or Copilot expects them and let each tool load everything it finds. That approach has no install step, no daemon, no protocol, and no version skew between a skill and its copy. What it cannot do is filter. You cannot expose development skills to one agent and writing skills to another without maintaining two directory trees, and you cannot switch a skill off for one client without deleting it. SkillPort's answer is a single store plus environment-variable filters and a search tool, at the price of an extra process in the loop. The difference is not capability but topology: vendoring duplicates, SkillPort centralises. Centralising only pays off once duplication becomes the thing that hurts, which in practice means multiple agents, multiple projects, or a skill set large enough that context cost is visible.
Maintenance, licence and what to check before you commit
SkillPort is MIT licensed, which permits commercial use and modification; this is a statement about the licence text, not legal advice, and you should read the LICENSE file yourself. The release history supplied here shows v1.1.0 in December 2025, v1.1.1 in January 2026 and v1.1.2 in June 2026, with the last push matching v1.1.2. That is a low-cadence release pattern, so budget for reading the changelog rather than expecting frequent patches. Upgrade cost is concentrated in two places: the MCP server package, which is installed separately from the CLI and can therefore drift out of step, and the generated AGENTS.md, which must be regenerated after any change to the skill set. The project depends on the Agent Skills specification at agentskills.io and on the MCP ecosystem for its server mode, so a change in either upstream is a change you inherit. Python 3.10 or later is required per the README badge. The two things worth verifying against your own setup are whether skillport validate exits non-zero on failure for CI use, and how SKILLPORT_CORE_SKILLS_MODE=auto selects core skills when several SKILL.md files set alwaysApply.
Editorial conclusion
Adopt SkillPort if you keep a shared skill library across several agents and need one install path plus a CI validation gate. Skip it if you have a handful of skills in one repository, since the CLI mode alone does not earn a new dependency. Before committing, run skillport validate --json against your existing SKILL.md files to see how many fail the spec, and check whether SKILLPORT_CORE_SKILLS_MODE=auto matches how your agent discovers always-on skills.
Community notes