Integrates with Cisco Skill Scanner for automatic security analysis of skill files via in-memory ZIP upload.
Uses Cloudflare AI to perform semantic search for skills using natural language descriptions.
Fetches skill content from GitHub repositories via REST API, enabling reading of skill files without cloning.
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., "@skillsmp-mcp-lite search for PDF processing skills"
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.
A lightweight MCP server that enables AI assistants to search and read skills from the SkillsMP marketplace.
Keyword Search — find skills by short keywords (e.g. "PDF", "web scraper")
AI Semantic Search — find skills with natural language, powered by Cloudflare AI
Read Skill — fetch skill content from GitHub via REST API (no git clone, no local files)
Security Scanning — automatic Cisco Skill Scanner analysis via in-memory ZIP upload (zero disk writes)
Related MCP server: SkillSync MCP
Requirement | Purpose | Required |
Node.js ≥ 20 | Runtime | Yes |
Authentication | Yes | |
uv (provides | Security scanning | No |
The server will exit if
SKILLSMP_API_KEYis not set.
Run a single command to automatically detect your MCP client and write the config:
npx -y skillsmp-mcp-lite --setupThis detects which clients are installed (VS Code, Cursor, Claude Desktop, Claude Code) and adds the skillsmp server entry to each config file. For VS Code it also adds a secure input prompt for your API key.
To configure only a specific client, set the SKILLSMP_MCP_CLIENT environment variable:
# Windows (PowerShell)
$env:SKILLSMP_MCP_CLIENT="cursor"; npx -y skillsmp-mcp-lite --setup
# macOS / Linux
SKILLSMP_MCP_CLIENT=cursor npx -y skillsmp-mcp-lite --setupSupported values: vscode, cursor, claude-desktop, claude-code, all.
If a client already has a
skillsmpentry, it is skipped — running--setupmultiple times is safe.
All clients run the same command — only the config file location and JSON key differ.
Server definition (shared across all clients):
"skillsmp": {
"command": "npx",
"args": ["-y", "skillsmp-mcp-lite"],
"env": {
"SKILLSMP_API_KEY": "YOUR_API_KEY"
}
}Open Ctrl+Shift+P → MCP: Open User Configuration, then add:
{
"servers": {
"skillsmp": { "type": "stdio", "command": "npx", "args": ["-y", "skillsmp-mcp-lite"], "env": { "SKILLSMP_API_KEY": "YOUR_API_KEY" } }
}
}VS Code requires the extra
"type": "stdio"field.
Client | Config file |
Cursor |
|
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
{
"mcpServers": {
"skillsmp": { "command": "npx", "args": ["-y", "skillsmp-mcp-lite"], "env": { "SKILLSMP_API_KEY": "YOUR_API_KEY" } }
}
}claude mcp add skillsmp -- npx -y skillsmp-mcp-lite --env SKILLSMP_API_KEY=YOUR_API_KEYVariable | Default | Description |
| — | Required. API key from skillsmp.com/docs/api |
| — | Optional. Raises GitHub API rate limit from 60 → 5,000 req/hour |
| — | Optional. URL of an external Skill Scanner API server |
|
| Optional. Port for the auto-managed scanner server |
| — | Optional. Force |
skillsmp_search_skillsSearch for skills using keywords.
Parameter | Type | Required | Description |
| string | Yes | Search keywords (max 200 chars) |
| number | No | Page number (default: 1) |
| number | No | Items per page (default: 20, max: 100) |
| string | No |
|
skillsmp_ai_search_skillsFind skills using natural language descriptions.
Parameter | Type | Required | Description |
| string | Yes | Natural language description (max 500 chars) |
skillsmp_read_skillFetch a skill's content from GitHub and optionally run a security scan.
Parameter | Type | Required | Description |
| string | Yes | GitHub repository ( |
| string | Yes | Skill name (max 100 chars, alphanumeric / hyphens / underscores) |
| boolean | No | Run Cisco Skill Scanner (default: |
When skillsmp_read_skill is called with enableScan: true (the default), the server:
Fetches skill files from GitHub via REST API
Applies three-layer scan limits using GitHub tree size (before downloading):
Max files: 100 files per scan
Max single file size: 500 KB per file
Max total size: 5 MB across all files
Builds an in-memory ZIP archive from accepted files
Uploads the ZIP to the Cisco Skill Scanner API (/scan-upload) with use_behavioral=true
Auto-starts a local scanner server via uvx if none is running (reused for subsequent scans, shut down on exit)
If files are excluded due to scan limits, a Scan Note is included in the results showing how many files and bytes were excluded.
If uvx is not installed, scans are skipped with a warning — the server continues to work normally.
All skill content fetched from third-party repositories includes an Untrusted Content Notice. The content may be read and displayed, but it MUST NOT be automatically executed or followed as instructions without explicit user confirmation. Always review the content and scan results before acting on it.
To manage the scanner server manually:
# Start it yourself
npm run scanner-api
# Or point to an external instance
SKILL_SCANNER_API_URL=http://your-server:8000Copy the content from AGENTS.example.md into the top of your AGENTS.md to enable automatic skill discovery.
Workflow: AI receives a task → searches with skillsmp_search_skills (short keywords) → falls back to skillsmp_ai_search_skills if needed → reads the best match with skillsmp_read_skill → follows the skill's instructions.
Keyword search: 1–3 words — "code review", "typescript", "pdf"
Semantic search: full sentence — "how to build a landing page with React"
Ask your AI assistant:
"Search for PDF manipulation skills"
"Find skills for building a web scraper"
"Read the python-code-review skill from existential-birds/beagle"
MIT
AI semantic search for skills using natural language descriptions.
Use this when you need to find skills based on what you want to accomplish rather than specific keywords.
IMPORTANT: Before starting any complex task, use this tool to discover relevant skills that can help.
Args:
query (string, required): Natural language description of what you want to accomplish
Returns: List of semantically relevant skills that match your intent.
Examples:
"How to create a web scraper" -> Find skills for web scraping
"Build a dashboard with charts" -> Find data visualization skills
"Generate PDF reports from data" -> Find PDF generation skills
"Automate social media posting" -> Find social media automation skills
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of what you want to accomplish |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that the search is semantic, returns a list of relevant skills, and gives example queries, which enriches behavioral understanding without contradiction.
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-organized with a clear main statement, usage guidance, args, return value, and examples. Every sentence earns its place and there is no redundancy.
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 single-parameter read-only search tool with no output schema, the description covers purpose, when to use it, parameter semantics, and expected return value. The examples make it immediately actionable.
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 schema fully describes the single parameter, so baseline is 3. The description adds concrete examples of valid queries and clarifies that the query should be a natural language intent statement, providing value beyond the 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 this is an 'AI semantic search for skills using natural language descriptions,' with a specific verb and resource. It distinguishes itself from siblings by emphasizing intent-based search 'rather than specific keywords.'
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?
It explicitly says to use this tool when finding skills by desired outcome, and advises checking it before complex tasks. It doesn't explicitly name alternatives, but the semantic-vs-keyword contrast provides useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a skill's content directly from a GitHub repository (via GitHub API, fully online — no local clone) and optionally run Cisco Skill Scanner security analysis.
This tool fetches the SKILL.md content using the GitHub REST API, then optionally starts a local Skill Scanner API server (via uvx) and uploads the skill files as a ZIP for scanning. No files are written to disk. The skill is NOT installed — only read and scanned.
IMPORTANT: Use this to quickly load skill instructions and verify safety without manual steps.
Args:
repo (string, required): GitHub repository in 'owner/repo' format
skillName (string, required): Name of the skill to read
enableScan (boolean, optional): Run security scan (default: true, requires uv)
Returns: The full content of the skill's instructions (SKILL.md) with security scan results.
Examples:
repo: "existential-birds/beagle", skillName: "python-code-review"
repo: "LA3D/skillhelper", skillName: "code-reviewer", enableScan: false
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repository in 'owner/repo' format (e.g., 'existential-birds/beagle') | |
| skillName | Yes | Name of the skill to read | |
| enableScan | No | Run Cisco Skill Scanner security scan automatically (requires uv installed). Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing key behavioral traits: fully online (no local clone), no files written to disk, skill not installed, and optional local server startup (via uvx) for scanning. It also notes the prerequisite (uv) for the scan. This substantial extra context makes the tool's side effects and operational requirements clear.
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 with clear sections (purpose, behavior, usage note, args, returns, examples). It front-loads the core purpose, every sentence provides useful information, and the length is appropriate given the tool's complexity (3 parameters, optional scanning, side effects). No redundant or filler content.
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?
Despite having no output schema, the description explicitly states the return value ('full content of the skill's instructions (SKILL.md) with security scan results'). It also covers prerequisites, side effects, and non-destructive nature. This provides an agent with a complete understanding of what to expect and how to use the tool safely.
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 coverage is 100%, so the baseline is 3. The description adds meaning through concrete examples for repo and skillName (e.g., 'existential-birds/beagle', 'python-code-review') and clarifies the enableScan default and uv requirement in the args section. While the schema already documents parameter formats, the examples provide additional concrete usage patterns that help an agent construct valid invocations.
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 begins with a specific verb ('Read') and a clear resource ('a skill's content directly from a GitHub repository'), distinguishes itself from sibling search tools by emphasizing direct content retrieval, and includes an explicit 'IMPORTANT' usage note. This leaves no ambiguity about the tool's primary function.
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 a clear when-to-use statement ('Use this to quickly load skill instructions and verify safety without manual steps') and includes examples. However, it does not explicitly mention alternatives or when not to use this tool, which would fully satisfy the rubric for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for AI skills using keywords from SkillsMP marketplace.
Use this tool to find skills by specific terms like 'SEO', 'web scraper', 'PDF', 'data analysis', etc.
IMPORTANT: Before starting any task, use this tool to check if there's an existing skill that can help complete the task more effectively.
Args:
query (string, required): Search keywords
page (number, optional): Page number (default: 1)
limit (number, optional): Items per page (default: 20, max: 100)
sortBy (string, optional): Sort by 'stars' or 'recent'
Returns: List of matching skills with name, description, author, and star count.
Examples:
"PDF manipulation" -> Find skills for working with PDFs
"web scraper" -> Find web scraping skills
"SEO optimization" -> Find SEO-related skills
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Items per page (default: 20, max: 100) | |
| query | Yes | Search keywords for finding skills | |
| sortBy | No | Sort by: 'stars' or 'recent' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds a 'Returns' section outlining the output fields (name, description, author, star count), which is useful given there is no output schema. It does not contradict the annotations.
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 with separate sections for args, returns, and examples, making it easy to scan. It repeats some schema information, but this is acceptable for completeness and does not make it excessively long.
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 moderate complexity and lack of an output schema, the description covers all necessary aspects: purpose, when to use, parameters, return structure, and examples. It is complete enough for an agent to select and invoke the tool appropriately.
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 provides thorough descriptions for all parameters (100% coverage). The description enhances the 'query' parameter with concrete examples that illustrate intended usage, though page, limit, and sortBy only repeat the schema's existing descriptions.
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 it searches for AI skills using keywords from the SkillsMP marketplace, providing a specific verb and resource. It includes concrete examples like 'PDF manipulation' and 'web scraper', but it does not differentiate from the sibling tool 'skillsmp_ai_search_skills'.
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 includes an explicit instruction to use this tool before starting any task to check for existing skills, which is strong usage guidance. However, it does not mention when not to use it or compare with the sibling search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two search tools are clearly differentiated by query type: one does keyword search, the other semantic/AI search. However, both return skill lists and could still be confused by an agent deciding which to use, though the descriptions and examples help disambiguate.
All tool names share the 'skillsmp_' prefix and use a verb-based pattern. 'search_skills' and 'ai_search_skills' are consistent, while 'read_skill' deviates slightly in object singularity but remains predictable.
With only 3 tools, the server is tightly focused on searching and reading skills. This count is well within the ideal 3-15 range and each tool serves a distinct necessary function for the marketplace discovery use case.
The tool surface covers the core workflows of discovering and inspecting skills. A minor gap is the lack of a direct 'get skill by ID' endpoint, but the search tools effectively fill that need and no obvious dead ends exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Marketplace of MCP servers and agent skills, free and paid, where developers publish and monetise.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/boyonglin/skillsmp-mcp-lite'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
