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., "@SkillFlow MCP Server search for skills that help with Docker configuration"
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.
Connect AI coding agents to the SkillFlow AI skills marketplace. Live data. Zero config. One command.
A Model Context Protocol (MCP) server that connects AI coding agents to the SkillFlow marketplace — a curated AI skills marketplace with trust metrics and performance data.
AI agents are the new users. Instead of browsing a website, agents can now programmatically search, discover, and evaluate skills from SkillFlow using the MCP protocol.
"It's 2026. Build. For. Agents." — Andrej Karpathy
Key benefits:
Live API — real-time data from the SkillFlow backend, not hardcoded
Curated skills across 6 business categories with performance metrics
Trust metrics — success rates, run counts, ratings, and speed benchmarks
Zero config — no API keys, no environment variables, just npx
Works everywhere — Claude Desktop, Cursor, Windsurf, Copilot, Gemini CLI, and any MCP-compatible agent
Related MCP server: skillet
This server supports two transports:
Transport | Use Case | Command |
stdio | Local use with Claude Desktop, Cursor, etc. |
|
Streamable HTTP | Remote access via Smithery.ai, cloud agents |
|
npx skillflow-mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"skillflow": {
"command": "npx",
"args": ["-y", "skillflow-mcp-server"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"skillflow": {
"command": "npx",
"args": ["-y", "skillflow-mcp-server"]
}
}
}{
"mcpServers": {
"skillflow": {
"command": "npx",
"args": ["-y", "skillflow-mcp-server"]
}
}
}npm install -g skillflow-mcp-server
skillflow-mcpTool | Description |
| Search for skills by keyword, category, or tag |
| Get detailed info about a specific skill including pricing and performance |
| List all skill categories |
| Get currently trending skills |
| Get overall platform statistics (skills, runs, creators, revenue) |
Once connected, ask your AI agent:
"Search for skills that help with SEO content"
"What are the trending skills on SkillFlow?"
"Get details about the blog-seo-writer skill"
"List all skill categories"
"Show me the platform stats"
"Find skills for lead generation"
npm install -g skillflow-mcp-server
PORT=3000 skillflow-mcp-httpdocker build -t skillflow-mcp .
docker run -p 3000:3000 skillflow-mcpAvailable at: smithery.ai/server/skillflow-mcp-server
Method | Path | Description |
|
| Send JSON-RPC requests (initialize, tools/list, tools/call) |
|
| Open SSE stream for server notifications |
|
| Terminate a session |
|
| Health check (includes live skill count) |
┌─────────────┐ MCP Protocol ┌──────────────────┐ tRPC API ┌──────────────┐
│ AI Agent │ ◄──────────────────► │ SkillFlow MCP │ ◄──────────────► │ SkillFlow │
│ (Claude, │ stdio / HTTP+SSE │ Server │ (live data) │ Backend │
│ Cursor...) │ └──────────────────┘ └──────────────┘
└─────────────┘The MCP server acts as a bridge between AI coding agents and the SkillFlow marketplace. It fetches real-time data from the SkillFlow backend API with 5-minute caching for optimal performance.
git clone https://github.com/rafsilva85/skillflow-mcp-server.git
cd skillflow-mcp-server
npm install
npm run build
npm startContributions welcome! Please open an issue or submit a PR.
MIT — Rafael Silva
Get information about a skill publisher including their published skills and verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| publisher_id | Yes | Publisher username (e.g., 'rafsilva85') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what data is retrieved (published skills and verification status), adding useful context, but omits safety indicators (read-only nature), error behaviors, or rate limits that agents need for mutation-risk assessment.
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 with no wasted words. It is front-loaded with the action ('Get information...') and immediately specifies the scope of returned data.
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 low complexity (1 simple parameter, no nested objects, 100% schema coverage) and absence of an output schema, the description adequately covers the tool's purpose by specifying the exact data returned (verification status), though it could note error cases for invalid publisher IDs.
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% (publisher_id is fully documented with type, description, and example), establishing a baseline of 3. The description does not mention the parameter at all, but given the high schema coverage, no additional compensation is required.
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 uses a specific verb ('Get') and resource ('skill publisher') and clarifies what data is returned ('published skills and verification status'). However, it does not explicitly differentiate from sibling tools like get_skill_details that might also expose publisher metadata.
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 no explicit guidance on when to use this tool versus alternatives (e.g., when you need publisher verification status rather than skill details), nor does it mention prerequisites like needing the exact publisher_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific skill including description, install instructions, trust score, and compatible platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | The skill ID (e.g., 'credit-optimizer-v5') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden. It successfully discloses what data fields are returned, acting as proxy for missing output schema. However, it omits safety assertions (read-only status), error behaviors (404 if invalid skill_id), or auth requirements.
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?
Single information-dense sentence with zero waste. Front-loaded action ('Get detailed information') followed by parenthetical enumeration of return values. Every word earns its place.
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?
Excellent for a low-complexity tool (1 simple parameter). Compensates for missing output schema by explicitly listing four return data categories. Would be 5 if it included behavioral notes (read-only assurance, error states) due to missing annotations.
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% (skill_id fully documented with description and example), meeting baseline expectations. The description adds no additional parameter guidance, but requires none given the complete schema self-documents the single required field.
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?
States specific verb 'Get' with resource 'skill' and enumerates exact data returned (description, install instructions, trust score, platforms). The word 'specific' clearly distinguishes this from sibling search_skills (discovery) and get_trending_skills (list).
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?
Provides clear context that this tool retrieves details for a single identified skill (implying prerequisite ID), distinguishing it from search/list siblings. However, it does not explicitly name alternatives (e.g., 'use search_skills to find skill IDs first') or state when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently trending skills on SkillFlow marketplace, sorted by popularity and trust score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, description carries full burden. It discloses sorting behavior (popularity and trust score) and implies time-sensitivity ('currently'), but lacks safety information (read-only status), rate limits, or cache behavior that would be essential for agent decision-making.
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?
Single sentence, front-loaded with action and resource. Zero waste. Every clause earns its place by conveying domain ('SkillFlow marketplace') and behavioral attributes (sorting logic).
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?
Adequate for low complexity (1 optional param, no output schema). Covers essential 'what' and 'how sorted', but gaps remain in usage context (when to browse vs search) given the presence of sibling search_skills.
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% with 'limit' fully described in properties. Per guidelines, baseline is 3 when schema does the heavy lifting. Description does not mention the limit parameter, but no additional semantic context is needed 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?
Clear specific verb 'Get' and resource 'trending skills'. Mentions 'SkillFlow marketplace' domain and distinguishes from siblings by specifying 'sorted by popularity and trust score' (curated list vs search/query-based retrieval). Could be 5 if it explicitly contrasted with 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?
Zero guidance on when to use versus sibling tool search_skills or prerequisites. Does not clarify that this is for discovery/browse without a query, while search_skills requires search terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available skill categories on SkillFlow with descriptions and skill counts.
| 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 the full burden of disclosure. It partially compensates by describing the return payload ('descriptions and skill counts'), but lacks information on caching, rate limits, authorization requirements, or pagination behavior for the 'all' scope.
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 front-loads the action verb. Every clause earns its place by specifying scope ('all'), domain ('on SkillFlow'), and return structure ('with descriptions and skill counts').
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 low complexity (no parameters, simple list operation) and lack of output schema, the description adequately covers the functional scope by clarifying the return data includes descriptions and counts. It appropriately conveys what the agent will receive without an explicit 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 tool has zero parameters, which per the rubric establishes a baseline score of 4. The description does not need to compensate for missing schema documentation.
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 provides a clear verb ('List') and specific resource ('skill categories on SkillFlow'), and clarifies what data is returned ('descriptions and skill counts'). However, it does not explicitly differentiate from siblings like search_skills or get_skill_details via comparison, only implicitly through the resource name.
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 contains no guidance on when to use this tool versus alternatives such as search_skills, nor does it mention prerequisites or exclusions. It states what the tool does but not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for AI agent skills on SkillFlow marketplace by keyword, category, or tag. Returns matching skills with trust scores and install instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (keyword, category name, or tag) | |
| category | No | Filter by category (e.g., 'Development', 'Productivity', 'DevOps') | |
| min_trust_score | No | Minimum trust score (0-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden. It discloses return values ('trust scores and install instructions') but omits other behavioral traits like pagination, rate limits, or result ordering.
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?
Two well-structured sentences. First establishes the search operation and filters, second describes return payload. Zero waste, front-loaded with action verb.
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?
Adequate for a 3-parameter search tool without output schema. Covers search domain, filter options, and return data. Minor gap: no mention of pagination or result limits.
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 has 100% coverage with clear descriptions. The description reinforces parameter semantics by mentioning 'keyword, category, or tag' and 'trust scores', but adds minimal new information 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?
Clear verb ('Search') and resource ('AI agent skills on SkillFlow marketplace') with specific search criteria (keyword, category, tag). Lacks explicit differentiation from siblings like get_skill_details or get_trending_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?
Provides clear context on how to search (by keyword, category, or tag) and what filters are available. Does not explicitly name alternatives or exclusion criteria (e.g., when to use get_skill_details instead).
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. Dates show when Glama detected each change.
v1.0.0get_publisher_infoget_skill_detailsget_trending_skillslist_categoriessearch_skillsEach tool has a clearly distinct purpose with no overlap: get_publisher_info focuses on publishers, get_skill_details on individual skills, get_trending_skills on trending lists, list_categories on categories, and search_skills on keyword-based discovery. The descriptions reinforce these boundaries, making misselection unlikely.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_publisher_info, search_skills). The verbs are descriptive and uniform across the set, with no deviations in style or convention.
With 5 tools, this server is well-scoped for a marketplace discovery service. Each tool earns its place by covering distinct aspects of browsing and querying skills, publishers, and categories, without being overly sparse or bloated.
The tool set provides comprehensive read-only coverage for exploring a skill marketplace, including publishers, skills, categories, and search. A minor gap exists in the lack of tools for installing or managing skills, but agents can still perform discovery tasks effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Search and discover Agent Skills from the skills.sh registry. Powered by HAPI MCP server.
Marketplace of MCP servers and agent skills, free and paid, where developers publish and monetise.
A registry of 5,900+ peer-authored skills any MCP agent can search and load on demand.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rafsilva85/skillflow-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
