How do I use cc-recommender?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cc-recommender What should I install for this project?" 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.

cc-recommender

by yuji0809

Overview Schema Related Servers Score Discussions

TypeScript

Remote

cc-recommender

npm version npm downloads codecov License: MIT Node.js Version

🎯 Skills, Plugins, and MCP Server Recommendation MCP Server for Claude Code

English | 日本語

Just ask "What should I install?" in Claude Code, and it will analyze your project and recommend the best skills, plugins, and MCP servers.

Features

📦 Plugin Recommendations - Suggests optimal plugins from the official marketplace
🔌 MCP Server Recommendations - Search MCP servers from awesome-mcp-servers
🎯 Skill/Workflow Recommendations - Suggests skills, hooks, and commands from awesome-claude-code
🔍 Project Analysis - Automatically detects languages, frameworks, and dependencies
🏷️ Keyword Search - Search by name or tags
🔄 Auto-Update - Always fetches the latest data from GitHub (no manual updates needed)
⭐ Quality Scoring - Evaluates skills based on official status, stars, freshness, and source
🤖 Official Skills Discovery - Automatically discovers official skills from known organizations

Related MCP server: Mother MCP Skills

Installation

Via npm (Recommended)

npm install -g cc-recommender

Local Build

git clone https://github.com/yuji0809/cc-recommender.git
cd cc-recommender
pnpm install
pnpm run build

Requirements:

Node.js >= 22.0.0
pnpm >= 10.0.0 (for local build)

Usage with Claude Code

For Cursor users: Use ~/.cursor/mcp.json instead of ~/.claude/settings.json

Option 1: Using npx (Recommended)

No installation required. Always uses the latest version.

Add to ~/.claude/settings.json (or ~/.cursor/mcp.json for Cursor):

{
  "mcpServers": {
    "cc-recommender": {
      "command": "npx",
      "args": ["-y", "cc-recommender"]
    }
  }
}

Option 2: Global Installation

Faster startup, works offline. Requires manual updates.

npm install -g cc-recommender

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "cc-recommender": {
      "command": "cc-recommender"
    }
  }
}

Option 3: Local Build (For Development)

git clone https://github.com/yuji0809/cc-recommender.git
cd cc-recommender
pnpm install
pnpm run build

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "cc-recommender": {
      "command": "node",
      "args": ["/path/to/cc-recommender/dist/index.js"]
    }
  }
}

How to Use

Project Analysis and Recommendations

You: What should I install for this project?

Claude: [Uses recommend_skills tool]

📦 Plugins
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. typescript-lsp (Official)
   ├─ Purpose: TypeScript definition jump, type checking
   ├─ Score: 95 ✅ High Match
   └─ Install: /plugin install typescript-lsp

🔌 MCP Servers
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. supabase-mcp
   ├─ Purpose: Supabase DB operations
   ├─ Reason: Depends on @supabase/supabase-js
   └─ Install: claude mcp add supabase-mcp

Keyword Search

You: Find MCP servers related to databases

Claude: [Uses search_skills tool]

Available Tools

Tool	Description
`recommend_skills`	Analyzes project and recommends appropriate skills/plugins/MCPs
`search_skills`	Search by keywords
`get_skill_details`	Get details of a specific item
`list_categories`	Get list of categories
`get_stats`	Get database statistics

Data Sources

This MCP server aggregates data from the following sources:

Source	Content	Update Frequency
anthropics/claude-plugins-official	Official plugin marketplace	Daily
punkpeye/awesome-mcp-servers	Curated list of MCP servers	Daily
hesreallyhim/awesome-claude-code	List of skills/workflows/hooks	Daily

Auto-Update Feature

How it works:

The server automatically fetches the latest data from GitHub when it starts
Falls back to bundled data if the remote fetch fails
No manual updates or reinstallation required

Offline Mode (optional):

{
  "mcpServers": {
    "cc-recommender": {
      "command": "npx",
      "args": ["-y", "cc-recommender"],
      "env": {
        "CC_RECOMMENDER_OFFLINE_MODE": "true"
      }
    }
  }
}

When CC_RECOMMENDER_OFFLINE_MODE is enabled, only bundled data is used (no remote fetching).

Environment Variables

Variable	Description	Default
`CC_RECOMMENDER_OFFLINE_MODE`	Disable auto-updates and use only bundled data	`false`
`GITHUB_TOKEN`	GitHub personal access token (increases API rate limit from 60 to 5000 req/hour)	Not set
`SKIP_SECURITY_SCAN`	Skip security scanning during data fetch (for developers)	`false`

Notes:

To fetch skills from GitHub repositories, a GitHub token is recommended to avoid rate limits. Create a token at https://github.com/settings/tokens with public_repo scope.

Development

For development setup and contribution guidelines, see:

CONTRIBUTING.md - Contribution guide
ARCHITECTURE.md - Architecture documentation

Quick Start for Developers

# Install dependencies
pnpm install

# Run tests
pnpm run test

# Type check + Lint + Security audit
pnpm run check

# Build
pnpm run build

Security

Security is a top priority for this project. We employ multiple layers of automated security measures:

Automated Scanning: Dependabot, CodeQL, and custom security audits
Pre-commit Protection: Security checks run before every commit
CI/CD Gates: All PRs must pass security scans before merging
License Compliance: All dependencies are validated for approved licenses

For more details, see SECURITY.md.

To report a security vulnerability, please use GitHub Security Advisories.

Contributing

We welcome contributions! See CONTRIBUTING.md for details.

License

MIT

Author

Yuji

Available Tools

5 tools

get_skill_details詳細取得A

特定のツール（プラグイン、MCPサーバー、スキル、ワークフロー、フック、コマンド、エージェント）の詳細情報を取得します

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	スキル/プラグイン/MCPの名前

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read operation via '取得します', but it does not mention error conditions, return structure, or side effects. For a simple get operation this is minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and enumerates supported types without unnecessary filler. Every phrase earns its place, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter lookup, the description provides sufficient context about what the tool targets and what it does. The lack of an output schema makes some ambiguity about return format acceptable, though specifying expected result structure would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully covers the single 'name' parameter, and the tool description enriches it by listing the full range of accepted tool types (workflows, hooks, commands, agents) beyond the schema's basic 'skill/plugin/MCP name'. This adds meaning by clarifying the valid domain of the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('取得します' / retrieves) and a specific resource: detailed information about a particular tool. It enumerates the supported tool types (plugin, MCP server, skill, workflow, hook, command, agent), distinguishing it from siblings like search_skills or list_categories that have broader or different scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for retrieving details of a known named tool, but it does not explicitly state when to use it instead of alternatives such as search_skills or recommend_skills. No exclusions or alternative guidance are provided, so usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_stats統計情報C

データベースの統計情報を取得します

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only says 'retrieve,' which implies a read-only operation, but it does not confirm safety, describe the nature of the statistics, or disclose any potential side effects or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence with no fluff, but it is also under-specified—'statistics information' is vague and leaves the agent guessing about what exactly is retrieved. This is under-specification, not effective conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description needs to explain the return format and scope of the statistics. It does not, and it also lacks any mention of when the tool is relevant relative to the sibling skill-related tools. The minimal context is insufficient for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description correctly implies there are no inputs needed, and the schema confirms 100% coverage with no properties to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (取得/retrieve) and resource (データベースの統計情報/database statistics), and the tool name 'get_stats' aligns. It does not explicitly distinguish from siblings, but the siblings are about skills and categories, so the distinction is apparent enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description does not mention suitable contexts, exclusions, or relationships to sibling tools like search_skills or list_categories.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_categoriesカテゴリ一覧B

利用可能なカテゴリ一覧を取得します

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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 only says 'get available category list' and does not add context about return format, ordering, pagination, or non-destructive read behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly communicates the tool's purpose with no wasted words. It is appropriately sized for a simple parameterless list operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema, no nested objects), the description sufficiently indicates what the list contains ('available categories'). However, it could mention the output format or edge cases, but none are critical for this trivial list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema confirms this. Per guidelines, a baseline of 4 applies because no parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a list of available categories, using a specific verb ('取得します') and resource ('カテゴリ一覧'). It distinguishes from sibling tools, which focus on skills and stats, but does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. Sibling tool names hint at different resources, but the description does not mention any exclusions or preferred contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recommend_skillsプロジェクト推薦A

プロジェクトを分析し、適切なツールを推薦します。デフォルトではプラグイン、MCPサーバー、スキル、ワークフロー、フック、コマンド、エージェントすべてのタイプを推薦します。ユーザーが特定のタイプ（例：「スキルだけ教えて」）を要求した場合のみ types パラメータで絞り込んでください。

ParametersJSON Schema

Name	Required	Description
`types`	No	フィルタするタイプ。指定しない場合はすべてのタイプ（プラグイン、MCP、スキル、ワークフロー、フック、コマンド、エージェント）を推薦します。ユーザーが特定のタイプ（例：「スキルを教えて」「MCPサーバーを教えて」）を明示的に要求した場合のみ指定してください。
`description`	No	何を作りたいか、何を探しているか
`max_results`	No	最大結果数
`project_path`	Yes	プロジェクトのパス

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context about the default behavior (recommends all types) and the filtering rule, but it does not disclose whether the operation is read-only, the return format, or any authentication/rate-limit considerations. This is a moderate gap given the absent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, two sentences, and front-loaded with the core purpose. Every sentence contributes value: the first states the primary function, the second covers default behavior and parameter usage. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, and the description does not explain what the recommendation result looks like (e.g., list of tool names, reasons, confidence). It covers types, defaults, and filtering context well, but leaves the return value ambiguous. Given the moderate complexity, the description is adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter having a description. The description reinforces the types parameter's usage by repeating the default behavior and the condition for filtering, but it does not add meaning beyond what the schema already provides. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: analyze a project and recommend appropriate tools. It specifies the resource (project analysis) and the verb (recommend), and distinguishes itself from siblings like search_skills and get_skill_details by focusing on project-based recommendations rather than search or detail retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: the tool recommends tools based on project analysis, and explicitly instructs when to use the types parameter (only when the user requests a specific type). However, it does not mention sibling alternatives or when not to use this tool, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_skillsキーワード検索A

キーワードですべてのタイプ（プラグイン、MCPサーバー、スキル、ワークフロー、フック、コマンド、エージェント）を検索します。デフォルトではすべてのタイプを検索します。ユーザーが特定のタイプのみを要求した場合のみ types パラメータで絞り込んでください。

ParametersJSON Schema

Name	Required	Description
`query`	Yes	検索キーワード
`types`	No	フィルタするタイプ。指定しない場合はすべてのタイプを検索します。ユーザーが特定のタイプを明示的に要求した場合のみ指定してください。
`max_results`	No	最大結果数

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure but only mentions search behavior and filtering. It does not disclose that this is a read-only operation, nor does it describe the return format or any limitations such as pagination or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the purpose, and contains no redundant information. It is efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description does not explain what the search returns (e.g., result list, count, relevance ordering). The internal filtering guidance is present, but the description lacks information about the return format and read-only behavior, leaving some gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions, and the tool description repeats the types guidance without adding additional semantic meaning. Baseline 3 is appropriate because the schema already explains query, types, and max_results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches all types by keyword, listing each type explicitly. This distinguishes it from sibling tools like recommend_skills and list_categories, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains that the types parameter should only be used when the user explicitly requests a specific type, otherwise all types are searched. However, it does not explicitly name alternatives or describe when to prefer search_skills over sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.9.0Aug 10, 2026
- First observedget_skill_details
- First observedget_stats
- First observedlist_categories
- First observedrecommend_skills
- First observedsearch_skills

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools have clearly distinct purposes: recommend_skills analyzes projects, search_skills uses keywords, and the rest are straightforward. However, recommend_skills and search_skills both return tools and could be confused by an agent, though descriptions clarify the difference.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (recommend_skills, search_skills, list_categories, get_skill_details, get_stats). The naming convention is uniform and predictable.

Tool Count5/5

With only 5 tools, the server is well-scoped for its purpose of recommending and searching tools. Each tool serves a distinct function without unnecessary bloat.

Completeness4/5

The set covers core operations: recommend, search, list categories, get details, and stats. A minor gap is that there is no explicit 'list all tools' without a keyword, though search could potentially handle that. The naming suggests skills only, but descriptions clarify the broader domain.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Skill of Skills A
io.911fund.skills
Quality-ranked, cross-platform directory of AI coding skills, plugins and MCP servers.
Developer Tools AI & Machine Learning
6211
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
StackResolve C
dev.stackresolve
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Developer Tools
151
Code Synapse — Fit Repo Finder A
com.leewaystudio
Finds real, maintained open-source repos that fit your project. MCP grounding for coding agents.
Developer Tools Coding Agents
22

Related MCP Servers

Skill Retriever
RAG Systems Developer Tools Knowledge & Memory
AnthonyAlcaraz
F
license
C
quality
Not graded
maintenance
A graph-based MCP server that discovers, resolves dependencies, and installs the minimal set of Claude Code components—including skills, agents, and commands—tailored to specific tasks.
Updated 6 months ago (2026-03-06 20:20 UTC)
27
7
-
Mother MCP Skills
Developer Tools Agent Orchestration
dmgrok
A
license
Not graded
quality
C
maintenance
Automatically discovers and installs AI skills for your project's tech stack, supporting Claude, Copilot, Codex, and other MCP-compatible agents.
Updated 7 months ago (2026-01-29 16:52 UTC)
14
4
MIT
claude-oracle-mcp
Search Developer Tools
Vvkmnn
A
license
A
quality
D
maintenance
An MCP server for discovering Claude Code skills, plugins, and MCP servers by searching 15,000+ resources from 17 registries, GitHub, and the web with zero setup.
Updated 6 months ago (2026-03-16 13:36 UTC)
3
46
3
MIT
@skill-hub/mcp-serverofficial
Developer Tools
skillhub-club
A
license
A
quality
C
maintenance
Enables AI assistants to discover, search, and install Claude Code Skills from SkillHub, with tools for semantic search, browsing, recommendations, and installation.
Updated 7 months ago (2026-01-23 10:35 UTC)
5
26
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yuji0809/cc-recommender'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

cc-recommender

Features

Installation

Via npm (Recommended)

Local Build

Usage with Claude Code

Option 1: Using npx (Recommended)

Option 2: Global Installation

Option 3: Local Build (For Development)

How to Use

Project Analysis and Recommendations

Keyword Search

Available Tools

Data Sources

Auto-Update Feature

Environment Variables

Development

Quick Start for Developers

Security

Contributing

License

Author

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@skill-hub/mcp-serverofficial

Latest Blog Posts

MCP directory API