Skip to main content
Glama
cc-recommender

cc-recommender

by yuji0809

プロジェクト推薦

recommend_skills

Analyzes a project and recommends relevant Claude Code skills, plugins, MCP servers, workflows, hooks, commands, or agents, with optional type filters, to help users discover tools to install.

Instructions

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_path": "<project_path>"
    },
    "name": "recommend_skills"
  }
}

Input Schema

NameRequiredDescriptionDefault
typesNoフィルタするタイプ。指定しない場合はすべてのタイプ(プラグイン、MCP、スキル、ワークフロー、フック、コマンド、エージェント)を推薦します。ユーザーが特定のタイプ(例:「スキルを教えて」「MCPサーバーを教えて」)を明示的に要求した場合のみ指定してください。
descriptionNo何を作りたいか、何を探しているか
max_resultsNo最大結果数
project_pathYesプロジェクトのパス

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.9.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full disclosure burden. It does explain the default breadth of recommendations and the filtering rule, but says nothing about whether the call is read-only, what project analysis actually entails (file scanning, cost, latency), or the form of the returned recommendations — notable since there is no output schema.

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

Conciseness4/5

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

Three short sentences, front-loaded with purpose, then default scope, then the filtering rule. Effectively no filler, though the types explanation overlaps content already present in the schema.

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?

For a project-analysis tool with four parameters and no output schema, the description leaves the result shape and the analysis scope undocumented, and never mentions max_results or the free-text description parameter. What it does cover (scope defaults, filtering) is accurate, so it is adequate rather than complete.

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 description coverage is 100%, and the description's discussion of types largely restates the schema's own description of that parameter. The other three parameters (project_path, description, max_results) receive no added meaning in the description, so the baseline 3 applies.

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 states a specific verb+resource pair — analyze the project and recommend appropriate tools — and enumerates the seven recommendation categories, which resolves the ambiguity created by the name recommend_skills (it is not skill-only). It stops short of explicitly distinguishing this from siblings such as search_skills or get_skill_details.

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?

Clear default behavior is stated (all types recommended unless asked otherwise), plus an explicit condition for narrowing: only when the user names a specific type. The example utterance "スキルだけ教えて" makes the trigger concrete. No guidance about when this tool is preferable to search_skills, which keeps it from a 5.

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