Skill Jack MCP dynamically integrates Agent Skills into LLMs, providing on-demand access to specialized instructions and resources through MCP tools and resources.
Activate Skills - Use the skill tool to load complete SKILL.md content by name, providing your LLM with step-by-step instructions and guidance for specific tasks
Access Skill Resources - Use the skill-resource tool to read specific files (scripts, snippets, templates, references, assets), list available files, or load entire directories within a skill
Dynamic Discovery - Automatically detects and updates available skills from configured directories when SKILL.md files change, sending tools/listChanged notifications to clients
Resource URIs - Access skills via skill:// URIs for manual selection in MCP clients, supporting single files, directories, or the main SKILL.md content
Real-time Updates - Subscribe to resources for notifications when skill files change, enabling live updates via notifications/resources/updated
Progressive Disclosure - Follows Agent Skills pattern—lightweight metadata (name, description, location) loads first, then full instructions and files as needed
Multiple Directories - Configure one or multiple skills directories with automatic scanning, deduplication, and searching across all sources
Security Features - Includes path traversal prevention, configurable file size limits, and directory depth limits, while treating skill content as trusted
Click on "Install 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., "@Skill Jack MCP load the 'mcp-server-ts' skill"
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 server that jacks Agent Skills directly into your LLM's brain.
Tool search / deferred tools. By default, skilljack delivers its skill catalog via MCP server instructions, which arrive in the
initializehandshake and are visible to the model even when tool search / deferred tool loading is enabled (the default on modern Claude Code) — so automatic skill activation works out of the box. The legacy--catalog=tool-descriptionmode (not recommended — see Catalog channel below) delivers the catalog through theload-skilltool description instead, but tool-search clients defer tool descriptions out of context, so that mode needsENABLE_TOOL_SEARCH=falseto auto-activate.
npm install @skilljack/mcpOr run directly with npx:
npx @skilljack/mcp /path/to/skillsgit clone https://github.com/olaservo/skilljack-mcp.git
cd skilljack-mcp
npm install
npm run buildRelated MCP server: Skillz
# Single directory
skilljack-mcp /path/to/skills
# Multiple directories
skilljack-mcp /path/to/skills /path/to/more/skills
# GitHub repository (allowlisted via GITHUB_ALLOWED_ORGS / _USERS)
GITHUB_ALLOWED_ORGS=acme skilljack-mcp github.com/acme/skills
# Well-known publisher (allowlisted via WELL_KNOWN_ALLOWED_ORIGINS).
# Each entry's SHA-256 digest is verified against the published index.
# Every fetched URL — the index, each artifact, and any redirect target — must
# match an allowlisted origin, so if a publisher serves artifacts from a
# separate CDN origin, add that origin to the list too (comma-separated).
WELL_KNOWN_ALLOWED_ORIGINS=https://example.com \
skilljack-mcp https://example.com/.well-known/agent-skills/
# Using environment variable
SKILLS_DIR=/path/to/skills skilljack-mcp
# Static mode (no file watching)
skilljack-mcp --static /path/to/skills
# Serve over HTTP instead of stdio (stateless Streamable HTTP on POST /mcp)
skilljack-mcp --http=3000 /path/to/skills
# or: SKILLJACK_HTTP_PORT=3000 skilljack-mcp /path/to/skillsTransports: stdio (default) or stateless HTTP (--http[=port], default 3000, or SKILLJACK_HTTP_PORT). HTTP serves the core skill surface (load-skill, skill-resource, skill:// resources, /skill prompts) at POST /mcp. Discovery-on-change works the same as stdio — file watchers and remote-source polling keep the skill state fresh, and every request (including each new client's initialize) reads it. Because the transport is stateless it does not push listChanged/resources/updated notifications: already-connected clients see changes on their next request or reconnect. The MCP-Apps configuration UI is stdio-only.
Catalog channel: --catalog=<instructions|tool-description> (or SKILLJACK_CATALOG) picks which single channel delivers the <available_skills> catalog — never both. instructions (default): server instructions, sent in the initialize handshake so it survives tool-search deferral; on stdio it is frozen at startup — skill changes need a restart (over HTTP, newly connecting clients always get a current catalog). tool-description is not recommended and is retained only as a legacy escape hatch (and as the control condition in the evals): the load-skill tool description is invisible to clients that defer MCP tool descriptions (e.g. Claude Code tool search, the modern default), so auto-activation silently breaks unless the client sets ENABLE_TOOL_SEARCH=false; and its one advantage — live catalog refresh via tools/listChanged — is a prompt-cache trap, because tool definitions sit at the top of the cached prompt prefix, so every refresh invalidates the entire cache (tools + system prompt + conversation history) and re-writes it at cache-write prices. Measured 2026-07-06 (#78): it has no cost advantage over instructions in steady state either.
This server comes along with a MCP Apps-based UI for clients that support it. Instead of fiddling with config files or environment variables, you can just configure your skills locations and skill visiblity directly in your chat window.
(Screenshots below are from Claude Desktop in dark mode.)
For complete documentation, just ask your assistant:
"how do I use skilljack?" or "how does skilljack work behind the scenes?"
This loads the full reference including tools, prompts, resources, configuration options, and architecture details.
Load a skill's full instructions. Returns the complete SKILL.md content with step-by-step guidance, examples, and file references to follow.
When a user's task matches a skill description below: 1) activate it, 2) follow its instructions completely.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name from <available_skills> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations. Annotations indicate read-only, non-destructive, and idempotent operations, but the description clarifies that it 'Returns the complete SKILL.md content with step-by-step guidance, examples, and file references to follow,' detailing the output format and purpose. This enhances understanding without contradicting annotations, which already cover safety aspects like read-only and non-destructive hints.
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 well-structured and appropriately sized, with key information front-loaded: the first sentence explains the core action and return value. The additional section '# Skills' provides necessary usage context without redundancy. Every sentence serves a purpose, making it efficient, though it could be slightly more concise by integrating the usage guidelines more seamlessly.
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's complexity (simple read operation with one parameter), rich annotations (readOnlyHint, idempotentHint, etc.), and no output schema, the description is reasonably complete. It explains what the tool does, when to use it, and what it returns, covering essential aspects. However, it could benefit from more detail on error handling or output structure to fully compensate for the lack of output schema.
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 input schema has 100% description coverage, with the 'name' parameter documented as 'Skill name from <available_skills>'. The description doesn't add further parameter details beyond what the schema provides, such as examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the comprehensive schema.
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: 'Load a skill's full instructions' and 'Returns the complete SKILL.md content'. It specifies the verb ('Load') and resource ('skill's full instructions'), making the action clear. However, it doesn't explicitly differentiate from the sibling tool 'skill-resource', which could help distinguish their specific roles.
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 provides clear context for when to use the tool: 'When a user's task matches a skill description below: 1) activate it, 2) follow its instructions completely.' This gives explicit guidance on the trigger condition and expected workflow. However, it doesn't mention when not to use it or alternatives, such as how it differs from 'skill-resource'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read files referenced by skill instructions (scripts, snippets, templates). Use when skill instructions mention specific files to read or copy. Pass a directory path (e.g., 'templates') to read all files in that directory at once.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Skill name | |
| path | Yes | Relative path to file or directory. Examples: 'snippets/tool.ts' (single file), 'templates' (all files in directory), '' (list available files). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations: it explains that you can read single files or entire directories at once, and provides specific examples of path usage. While annotations already indicate this is a safe, read-only operation (readOnlyHint=true, destructiveHint=false), the description enhances understanding of the tool's behavior with practical file/directory reading capabilities.
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 perfectly concise with three focused sentences that each serve a distinct purpose: stating the tool's purpose, providing usage guidance, and explaining parameter behavior. There is zero wasted text and the information is front-loaded effectively.
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 read-only tool with comprehensive annotations and full schema coverage, the description provides excellent context about when and how to use it. The only minor gap is the lack of output schema, but the description compensates well by explaining what the tool reads (files, directories) and providing concrete examples.
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?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds some practical context about path usage ('Pass a directory path... to read all files in that directory at once') but doesn't provide significant additional parameter semantics beyond what the schema already specifies.
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 specific action ('Read files'), target resource ('files referenced by skill instructions'), and scope ('scripts, snippets, templates'). It distinguishes from the sibling 'skill' tool by specifying this is for reading files referenced by skills rather than general skill operations.
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 provides explicit guidance on when to use this tool ('Use when skill instructions mention specific files to read or copy') and includes practical examples of different path scenarios. It clearly defines the context for tool invocation with concrete examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: 'skill' loads the full instructions for a skill, while 'skill-resource' reads the files referenced by those instructions. There is no overlap in functionality, and an agent can easily tell them apart based on their descriptions.
The tool names follow a consistent pattern with a hyphen separating words (e.g., 'skill-resource'), and both start with 'skill' to indicate the domain. However, the first tool is simply 'skill' while the second is 'skill-resource', which is a minor deviation from a strict verb_noun pattern, but overall the naming is readable and predictable.
With only 2 tools, the server feels thin for a 'Skill Jack MCP' that implies managing or executing skills. This minimal set may not cover essential operations like listing available skills, creating new skills, or updating existing ones, which are likely needed for a complete skill management system.
Inferring the domain as skill management, there are significant gaps: no tools to list, create, update, delete, or search skills, and no way to execute or run skills directly. The provided tools only handle loading instructions and reading referenced files, leaving core lifecycle operations uncovered and likely causing agent failures in broader tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed AI agent skills — one library, distributed to devs and exposed to remote agents over MCP.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
AI agent skills marketplace — token-efficient skill search & execution
Search, fetch (with provenance), scan, and convert AI instruction files for agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/olaservo/skilljack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
