de en es ja ko ru zh

Vibe Coder MCP

Name: Vibe Coder MCP
Author: freshtechbro

by freshtechbro

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Vibe Coder MCP サーバー

テスト

Vibe Coderは、AIアシスタント（Cursor、Cline AI、Claude Desktopなど）をソフトウェア開発のための強力なツールで強化するために設計されたMCP（Model Context Protocol）サーバーです。調査、計画、要件定義、スタータープロジェクトの作成など、さまざまな作業に役立ちます。

概要と機能

Vibe Coder MCP は MCP 互換クライアントと統合して、次の機能を提供します。

セマンティックリクエストルーティング: 埋め込みベースのセマンティックマッチングと順次思考フォールバックを使用して、リクエストをインテリジェントにルーティングします。
ツールレジストリアーキテクチャ: 自己登録ツールによる集中ツール管理。
直接 LLM 呼び出し: ジェネレーターツールは、信頼性の向上と構造化された出力制御のために直接 LLM 呼び出しを使用するようになりました。
ワークフロー実行: workflows.jsonで定義されたツール呼び出しの定義済みシーケンスを実行します。
調査と計画: 詳細な調査 ( research-manager ) を実行し、PRD ( generate-prd )、ユーザーストーリー ( generate-user-stories )、タスクリスト ( generate-task-list )、開発ルール ( generate-rules ) などの計画ドキュメントを生成します。
プロジェクトスキャフォールディング: フルスタックスターターキットを生成します ( generate-fullstack-starter-kit )。
コードマップジェネレーター: コードベースを再帰的にスキャンし、セマンティック情報を抽出して、トークン効率が高くコンテキスト密度の高い、Mermaid ダイアグラム付きの Markdown インデックス、またはインポート用の絶対ファイルパスと拡張クラスプロパティ情報を含む構造化 JSON 表現 ( map-codebase ) を生成します。
非同期実行：長時間実行されるツール（ジェネレータ、リサーチ、ワークフローなど）の多くが非同期で実行されるようになりました。これらのツールは即座にジョブIDを返し、最終結果はget-job-resultツールを使用して取得されます。
セッション状態管理: セッション内 (メモリ内) のリクエスト間で基本状態を維持します。
標準化されたエラー処理: すべてのツールにわたって一貫したエラーパターン。

(詳細については、以下の「ツールの詳細なドキュメント」および「機能の詳細」セクションを参照してください)

Related MCP server: Jilebi

セットアップガイド

Vibe Coder MCP サーバーを実行し、AI アシスタントに接続するには、次のマイクロステップに従います。

ステップ1: 前提条件

Node.jsのバージョンを確認する:
- ターミナルまたはコマンドプロンプトを開きます。
- node -vを実行する
- 出力に v18.0.0 以上が表示されていることを確認します (必須)。
- インストールされていない、または古くなっている場合: nodejs.orgからダウンロードします。
Git のインストールを確認します。
- ターミナルまたはコマンドプロンプトを開きます。
- git --versionを実行する
- インストールされていない場合: git-scm.comからダウンロードします。
OpenRouter APIキーを取得します:
- openrouter.aiにアクセスしてください
- アカウントをお持ちでない場合は作成してください。
- API キーセクションに移動します。
- 新しい API キーを作成してコピーします。
- このキーをステップ 4 で使えるようにしておきます。

ステップ2: コードを取得する

プロジェクトディレクトリを作成します(オプション):
- ターミナルまたはコマンドプロンプトを開きます。
- プロジェクトを保存する場所に移動します。
  cd ~/Documents # Example: Change to your preferred location
リポジトリをクローンします。
- 走る：
  git clone https://github.com/freshtechbro/vibe-coder-mcp.git
  (または、該当する場合はフォークの URL を使用します)
プロジェクトディレクトリに移動します。
- 走る：
  cd vibe-coder-mcp

ステップ3: セットアップスクリプトを実行する

ご使用のオペレーティングシステムに適したスクリプトを選択してください。

Windowsの場合:

ターミナル (vibe-coder-mcp ディレクトリ内) で、次を実行します。
```
setup.bat
```
スクリプトが完了するまで待ちます (依存関係がインストールされ、プロジェクトがビルドされ、必要なディレクトリが作成されます)。
エラーメッセージが表示された場合は、以下のトラブルシューティングセクションを参照してください。

macOS または Linux の場合:

スクリプトを実行可能にします。
```
chmod +x setup.sh
```
スクリプトを実行します:
```
./setup.sh
```
スクリプトが完了するまで待ちます。
エラーメッセージが表示された場合は、以下のトラブルシューティングセクションを参照してください。

スクリプトは次のアクションを実行します。

Node.js のバージョンをチェックします (v18+)
npm経由ですべての依存関係をインストールします
必要なVibeCoderOutput/サブディレクトリを作成します (スクリプトでの定義に従って)。
TypeScript プロジェクトをビルドします。
**.envが存在しない場合は、 .env.exampleを.envにコピーします。**このファイルを編集する必要があります。
実行権限を設定します (Unix システムの場合)。

ステップ4: 環境変数（ `.env` ）を構成する

セットアップスクリプト (手順 3) は、 .envがまだ存在しない場合にのみ、 .env.exampleテンプレートをコピーして、プロジェクトのルートディレクトリに.envファイルを自動的に作成します。

**.envを見つけて開く:**メインのvibe-coder-mcpディレクトリで.envファイルを見つけて、テキストエディターで開きます。

OpenRouter APIキーを追加します（必須）:

ファイルには.env.exampleに基づいたテンプレートが含まれています。

# OpenRouter Configuration
## Specifies your unique API key for accessing OpenRouter services.
## Replace "Your OPENROUTER_API_KEY here" with your actual key obtained from OpenRouter.ai.
OPENROUTER_API_KEY="Your OPENROUTER_API_KEY here"

## Defines the base URL for the OpenRouter API endpoints.
## The default value is usually correct and should not need changing unless instructed otherwise.
OPENROUTER_BASE_URL=https://openrouter.ai/api/v1

## Sets the specific Gemini model to be used via OpenRouter for certain AI tasks.
## ':free' indicates potential usage of a free tier model if available and supported by your key.
GEMINI_MODEL=google/gemini-2.0-flash-thinking-exp:free

**重要なのは、 "Your OPENROUTER_API_KEY here"を実際のOpenRouter APIキーに置き換えることです。**キーに引用符が不要な場合は、引用符を削除してください。

出力ディレクトリを構成する（オプション）:
- 生成されたファイルの保存場所を変更するには (デフォルトはプロジェクト内のVibeCoderOutput/ )、次の行を.envファイルに追加します。
  VIBE_CODER_OUTPUT_DIR=/path/to/your/desired/output/directory
- パスを任意の絶対パスに置き換えてください。パスにはスラッシュ ( / ) を使用してください。この変数が設定されていない場合は、デフォルトのディレクトリ ( VibeCoderOutput/ ) が使用されます。
コードマップジェネレーターディレクトリを構成する (オプション):
- コードマップジェネレーターツールがスキャンできるディレクトリを指定するには、次の行を.envファイルに追加します。
  CODE_MAP_ALLOWED_DIR=/path/to/your/source/code/directory
- パスを、分析対象のソースコードを含むディレクトリへの絶対パスに置き換えてください。これはセキュリティ境界であり、ツールはこのディレクトリ外のファイルにはアクセスしません。
- セキュリティ上の理由から、 CODE_MAP_ALLOWED_DIR （ソースコードの読み取り用）とVIBE_CODER_OUTPUT_DIR （出力ファイルの書き込み用）は別々に設定されていることに注意してください。コードマップ生成ツールは、読み取り操作と書き込み操作に対して別々の検証を行います。
その他の設定を確認する（オプション）:
- LOG_LEVEL (例: LOG_LEVEL=debug ) やNODE_ENV (例: NODE_ENV=development ) など、サーバーでサポートされている他の環境変数を追加できます。
.envファイルを保存します。

ステップ5：AIアシスタントとの統合（MCP設定）

この重要なステップでは、クライアントの MCP 設定ファイルに構成を追加することで、Vibe Coder を AI アシスタントに接続します。

5.1: クライアントのMCP設定ファイルを見つける

場所は AI アシスタントによって異なります。

Cursor AI / Windsurf / RooCode (VS Code ベース):
1. アプリケーションを開きます。
2. コマンドパレットを開きます ( Ctrl+Shift+PまたはCmd+Shift+P )。
3. 入力してPreferences: Open User Settings (JSON)を選択します。
4. これにより、 mcpServersオブジェクトが存在するはずのsettings.jsonファイルが開きます。
Cline AI (VS Code 拡張機能):
- Windows : %APPDATA%\Cursor\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
- macOS : ~/Library/Application Support/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
- Linux : ~/.config/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
- (注: カーソルの代わりに標準の VS Code を使用する場合は、パス内のCursorをCodeに置き換えてください)
クロードデスクトップ:
- Windows : %APPDATA%\Claude\claude_desktop_config.json
- macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
- Linux : ~/.config/Claude/claude_desktop_config.json

5.2: Vibe Coder 設定を追加する

上記の設定ファイルをテキストエディターで開きます。
"mcpServers": { ... }というJSONオブジェクトを探します。存在しない場合は作成する必要があるかもしれません（ファイル全体が有効なJSONであることを確認してください）。例えば、空のファイルは{"mcpServers": {}}のように記述される可能性があります。

mcpServersオブジェクトの中括弧{}**内に、**以下の設定ブロックを追加します。既に他のサーバーがリストされている場合は、このブロックを貼り付ける前に、前のサーバーの閉じ括弧}の後にカンマ,を追加してください。

// This is the unique identifier for this MCP server instance within your client's settings
"vibe-coder-mcp": {
  // Specifies the command used to execute the server. Should be 'node' if Node.js is in your system's PATH
  "command": "node",
  // Provides the arguments to the 'command'. The primary argument is the absolute path to the compiled server entry point
  // !! IMPORTANT: Replace with the actual absolute path on YOUR system. Use forward slashes (/) even on Windows !!
  "args": ["/Users/username/Documents/Dev Projects/Vibe-Coder-MCP/build/index.js"],
  // Sets the current working directory for the server process when it runs
  // !! IMPORTANT: Replace with the actual absolute path on YOUR system. Use forward slashes (/) even on Windows !!
  "cwd": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP",
  // Defines the communication transport protocol between the client and server
  "transport": "stdio",
  // Environment variables to be passed specifically to the Vibe Coder server process when it starts
  // API Keys should be in the .env file, NOT here
  "env": {
    // Absolute path to the LLM configuration file used by Vibe Coder
    // !! IMPORTANT: Replace with the actual absolute path on YOUR system !!
    "LLM_CONFIG_PATH": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP/llm_config.json",
    // Sets the logging level for the server
    "LOG_LEVEL": "debug",
    // Specifies the runtime environment
    "NODE_ENV": "production",
    // Directory where Vibe Coder tools will save their output files
    // !! IMPORTANT: Replace with the actual absolute path on YOUR system !!
    "VIBE_CODER_OUTPUT_DIR": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP/VibeCoderOutput",
    // Directory that the code-map-generator tool is allowed to scan
    // This is a security boundary - the tool will not access files outside this directory
    "CODE_MAP_ALLOWED_DIR": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP/src"
  },
  // A boolean flag to enable (false) or disable (true) this server configuration
  "disabled": false,
  // A list of tool names that the MCP client is allowed to execute automatically
  "autoApprove": [
    "research",
    "generate-rules",
    "generate-user-stories",
    "generate-task-list",
    "generate-prd",
    "generate-fullstack-starter-kit",
    "refactor-code",
    "git-summary",
    "run-workflow",
    "map-codebase"
  ]
}

重要： すべてのプレースホルダーパス（ /path/to/your/vibe-coder-mcp/...など）を、リポジトリをクローンしたシステム上の正しい絶対パスに置き換えてください。Windowsでもパスにはスラッシュ「 /を使用してください（例： C:/Users/YourName/Projects/vibe-coder-mcp/build/index.js ）。パスの誤りは、サーバーへの接続に失敗する最も一般的な原因です。
設定ファイルを保存します。
変更を有効にするには、AI アシスタントアプリケーション (Cursor、VS Code、Claude Desktop など)を完全に閉じて再起動します。

ステップ6: 構成をテストする

AIアシスタントを起動する:
- AI アシスタントアプリケーションを完全に再起動します。
簡単なコマンドをテストする:
- 次のようなテストコマンドを入力します: Research modern JavaScript frameworks
適切な応答を確認する:
- 正しく動作している場合は、調査の応答が返されるはずです。
- そうでない場合は、以下のトラブルシューティングのセクションを確認してください。

プロジェクトアーキテクチャ

Vibe Coder MCP サーバーは、ツールレジストリパターンを中心としたモジュラーアーキテクチャに従います。

flowchart TD
    subgraph Initialization
        Init[index.ts] --> Config[Load Configuration]
        Config --> Server[Create MCP Server]
        Server --> ToolReg[Register Tools]
        ToolReg --> InitEmbed[Initialize Embeddings]
        InitEmbed --> Ready[Server Ready]
    end

    subgraph Request_Flow
        Req[Client Request] --> ReqProc[Request Processor]
        ReqProc --> Route[Routing System]
        Route --> Execute[Tool Execution]
        Execute --> Response[Response to Client]
    end

    subgraph Routing_System ["Routing System (Hybrid Matcher)"]
        Route --> Semantic[Semantic Matcher]
        Semantic --> |High Confidence| Registry[Tool Registry]
        Semantic --> |Low Confidence| SeqThink[Sequential Thinking]
        SeqThink --> Registry
    end

    subgraph Tool_Execution
        Registry --> |Get Definition| Definition[Tool Definition]
        Definition --> |Validate Input| ZodSchema[Zod Validation]
        ZodSchema --> |Execute| Executor[Tool Executor]
        Executor --> |May Use| Helper[Utility Helpers]
        Helper --> |Research| Research[Research Helper]
        Helper --> |File Ops| File[File I/O]
        Helper --> |Embeddings| Embed[Embedding Helper]
        Helper --> |Git| Git[Git Helper]
        Executor --> ReturnResult[Return Result]
    end

    subgraph Error_Handling
        ReturnResult --> |Success| Success[Success Response]
        ReturnResult --> |Error| ErrorHandler[Error Handler]
        ErrorHandler --> CustomErr[Custom Error Types]
        CustomErr --> FormattedErr[Formatted Error Response]
    end

    Execute --> |Session State| State[Session State]
    State --> |Persists Between Calls| ReqProc

ディレクトリ構造

vibe-coder-mcp/
├── .env                  # Environment configuration
├── mcp-config.json       # Example MCP configuration
├── package.json          # Project dependencies
├── README.md             # This documentation
├── setup.bat             # Windows setup script
├── setup.sh              # macOS/Linux setup script
├── tsconfig.json         # TypeScript configuration
├── vitest.config.ts      # Vitest (testing) configuration
├── workflows.json        # Workflow definitions
├── build/                # Compiled JavaScript (after build)
├── docs/                 # Additional documentation
├── VibeCoderOutput/      # Tool output directory
│   ├── research-manager/
│   ├── rules-generator/
│   ├── prd-generator/
│   ├── user-stories-generator/
│   ├── task-list-generator/
│   ├── fullstack-starter-kit-generator/
│   └── workflow-runner/
└── src/                  # Source code
    ├── index.ts          # Entry point
    ├── logger.ts         # Logging configuration (Pino)
    ├── server.ts         # MCP server setup
    ├── services/         # Core services
    │   ├── AIService.ts  # AI model interaction (OpenRouter)
    │   ├── JobManager.ts # Manages async jobs
    │   └── ToolService.ts# Tool registration and routing
    ├── tools/            # MCP Tools
    │   ├── index.ts      # Tool registration
    │   ├── sequential-thinking.ts  # Fallback routing
    │   ├── fullstack-starter-kit-generator/  # Project gen
    │   ├── prd-generator/            # PRD creation
    │   ├── research-manager/         # Research tool
    │   ├── rules-generator/          # Rule generation
    │   ├── task-list-generator/      # Task list generation
    │   ├── user-stories-generator/   # User story generation
    │   └── workflow-runner/          # Workflow execution engine
    ├── types/            # TypeScript type definitions
{{ ... }}

## Semantic Routing System

Vibe Coder uses a sophisticated routing approach to select the right tool for each request:

```mermaid
flowchart TD
    Start[Client Request] --> Process[Process Request]
    Process --> Hybrid[Hybrid Matcher]

    subgraph "Primary: Semantic Routing"
        Hybrid --> Semantic[Semantic Matcher]
        Semantic --> Embeddings[Query Embeddings]
        Embeddings --> Tools[Tool Embeddings]
        Tools --> Compare[Compare via Cosine Similarity]
        Compare --> Score[Score & Rank Tools]
        Score --> Confidence{High Confidence?}
    end

    Confidence -->|Yes| Registry[Tool Registry]

    subgraph "Fallback: Sequential Thinking"
        Confidence -->|No| Sequential[Sequential Thinking]
        Sequential --> LLM[LLM Analysis]
        LLM --> ThoughtChain[Thought Chain]
        ThoughtChain --> Extraction[Extract Tool Name]
        Extraction --> Registry
    end

    Registry --> Executor[Execute Tool]
    Executor --> Response[Return Response]

ツールレジストリパターン

ツールレジストリは、ツールの定義と実行を管理するための中心的なコンポーネントです。

flowchart TD
    subgraph "Tool Registration (at import)"
        Import[Import Tool] --> Register[Call registerTool]
        Register --> Store[Store in Registry Map]
    end

    subgraph "Tool Definition"
        Def[ToolDefinition] --> Name[Tool Name]
        Def --> Desc[Description]
        Def --> Schema[Zod Schema]
        Def --> Exec[Executor Function]
    end

    subgraph "Server Initialization"
        Init[server.ts] --> Import
        Init --> GetAll[getAllTools]
        GetAll --> Loop[Loop Through Tools]
        Loop --> McpReg[Register with MCP Server]
    end

    subgraph "Tool Execution"
        McpReg --> ExecTool[executeTool Function]
        ExecTool --> GetTool[Get Tool from Registry]
        GetTool --> Validate[Validate Input]
        Validate -->|Valid| ExecFunc[Run Executor Function]
        Validate -->|Invalid| ValidErr[Return Validation Error]
        ExecFunc -->|Success| SuccessResp[Return Success Response]
        ExecFunc -->|Error| HandleErr[Catch & Format Error]
        HandleErr --> ErrResp[Return Error Response]
    end

連続的な思考プロセス

Sequential Thinking メカニズムは、LLM ベースのフォールバックルーティングを提供します。

flowchart TD
    Start[Start] --> Estimate[Estimate Number of Steps]
    Estimate --> Init[Initialize with System Prompt]
    Init --> First[Generate First Thought]
    First --> Context[Add to Context]
    Context --> Loop{Needs More Thoughts?}

    Loop -->|Yes| Next[Generate Next Thought]
    Next -->|Standard| AddStd[Add to Context]
    Next -->|Revision| Rev[Mark as Revision]
    Next -->|New Branch| Branch[Mark as Branch]
    Rev --> AddRev[Add to Context]
    Branch --> AddBranch[Add to Context]
    AddStd --> Loop
    AddRev --> Loop
    AddBranch --> Loop

    Loop -->|No| Extract[Extract Final Solution]
    Extract --> End[End With Tool Selection]

    subgraph "Error Handling"
        Next -->|Error| Retry[Retry with Simplified Request]
        Retry -->|Success| AddRetry[Add to Context]
        Retry -->|Failure| FallbackEx[Extract Partial Solution]
        AddRetry --> Loop
        FallbackEx --> End
    end

セッション状態管理

flowchart TD
    Start[Client Request] --> SessionID[Extract Session ID]
    SessionID --> Store{State Exists?}

    Store -->|Yes| Retrieve[Retrieve Previous State]
    Store -->|No| Create[Create New State]

    Retrieve --> Context[Add Context to Tool]
    Create --> NoContext[Execute Without Context]

    Context --> Execute[Execute Tool]
    NoContext --> Execute

    Execute --> SaveState[Update Session State]
    SaveState --> Response[Return Response to Client]

    subgraph "Session State Structure"
        State[SessionState] --> PrevCall[Previous Tool Call]
        State --> PrevResp[Previous Response]
        State --> Timestamp[Timestamp]
    end

ワークフロー実行エンジン

ワークフローシステムでは、複数のステップのシーケンスが可能になります。

flowchart TD
    Start[Client Request] --> Parse[Parse Workflow Request]
    Parse --> FindFlow[Find Workflow in workflows.json]
    FindFlow --> Steps[Extract Steps]

    Steps --> Loop[Process Each Step]
    Loop --> PrepInput[Prepare Step Input]
    PrepInput --> ExecuteTool[Execute Tool via Registry]
    ExecuteTool --> SaveOutput[Save Step Output]
    SaveOutput --> NextStep{More Steps?}

    NextStep -->|Yes| MapOutput[Map Output to Next Input]
    MapOutput --> Loop

    NextStep -->|No| FinalOutput[Prepare Final Output]
    FinalOutput --> End[Return Workflow Result]

    subgraph "Input/Output Mapping"
        MapOutput --> Direct[Direct Value]
        MapOutput --> Extract[Extract From Previous]
        MapOutput --> Transform[Transform Values]
    end

ワークフロー構成

ワークフローは、プロジェクトのルートディレクトリにあるworkflows.jsonファイルで定義されます。このファイルには、単一のコマンドで実行できるツール呼び出しのシーケンスが事前に定義されています。

ファイルの場所と構造

workflows.jsonファイルはプロジェクトのルートディレクトリ (package.json と同じレベル) に配置する必要があります。

ファイルは次の構造に従います。

{
  "workflows": {
    "workflowName1": {
      "description": "Description of what this workflow does",
      "inputSchema": {
        "param1": "string",
        "param2": "string"
      },
      "steps": [
        {
          "id": "step1_id",
          "toolName": "tool-name",
          "params": {
            "param1": "{workflow.input.param1}"
          }
        },
        {
          "id": "step2_id",
          "toolName": "another-tool",
          "params": {
            "paramA": "{workflow.input.param2}",
            "paramB": "{steps.step1_id.output.content[0].text}"
          }
        }
      ],
      "output": {
        "summary": "Workflow completed message",
        "details": ["Output line 1", "Output line 2"]
      }
    }
  }
}

パラメータテンプレート

ワークフローステップパラメータは、以下を参照できるテンプレート文字列をサポートします。

ワークフロー入力: {workflow.input.paramName}
前のステップの出力: {steps.stepId.output.content[0].text}

ワークフローのトリガー

run-workflowツールを次のように使用します。

Run the newProjectSetup workflow with input {"productDescription": "A task manager app"}

詳細なツールドキュメント

src/tools/ディレクトリ内の各ツールには、それぞれにREADME.mdファイルという包括的なドキュメントが含まれています。これらのファイルの内容は以下のとおりです。

ツールの概要と目的
入出力仕様
ワークフロー図（マーメイド）
使用例
使用されるシステムプロンプト
エラー処理の詳細

詳しい情報については、以下の個別の README を参照してください。

src/tools/fullstack-starter-kit-generator/README.md
src/tools/prd-generator/README.md
src/tools/research-manager/README.md
src/tools/rules-generator/README.md
src/tools/task-list-generator/README.md
src/tools/user-stories-generator/README.md
src/tools/workflow-runner/README.md
src/tools/code-map-generator/README.md

ツールカテゴリ

分析および情報ツール

コードマップジェネレーター ( map-codebase ) : コードベースをスキャンしてセマンティック情報 (クラス、関数、コメント) を抽出し、Mermaid ダイアグラムを含む人間が判読可能な Markdown マップ、またはインポート用の絶対ファイルパスと拡張クラスプロパティ情報を含む構造化 JSON 表現を生成します。
リサーチマネージャー ( research-manager ) : Perplexity Sonar を使用して技術的なトピックに関する詳細な調査を実行し、要約とソースを提供します。

計画およびドキュメントツール

**ルールジェネレーター ( generate-rules ):**プロジェクト固有の開発ルールとガイドラインを作成します。
**PRD ジェネレーター ( generate-prd ):**包括的な製品要件ドキュメントを生成します。
**ユーザーストーリージェネレーター ( generate-user-stories ):**受け入れ基準を備えた詳細なユーザーストーリーを作成します。
**タスクリストジェネレーター ( generate-task-list ):**依存関係を持つ構造化された開発タスクリストを構築します。

プロジェクトスキャフォールディングツール

**フルスタックスターターキットジェネレーター ( generate-fullstack-starter-kit ):**基本的なセットアップスクリプトと構成を含む、指定されたフロントエンド/バックエンドテクノロジーを使用してカスタマイズされたプロジェクトスターターキットを作成します。

ワークフローとオーケストレーション

**ワークフローランナー ( run-workflow ):**一般的な開発タスクに対して事前定義された一連のツール呼び出しを実行します。

生成されたファイルの保存

デフォルトでは、ジェネレータツールからの出力は、履歴参照のためにプロジェクト内のVibeCoderOutput/ディレクトリに保存されます。この場所は、 .envファイルまたはAIアシスタント設定でVIBE_CODER_OUTPUT_DIR環境変数を設定することで上書きできます。

読み取りおよび書き込み操作のセキュリティ境界

セキュリティ上の理由から、Vibe Coder MCP ツールは読み取り操作と書き込み操作に対して個別のセキュリティ境界を維持します。

読み取り操作：コードマップジェネレータなどのツールは、 CODE_MAP_ALLOWED_DIR環境変数で明示的に許可されたディレクトリからのみ読み取ります。これにより明確なセキュリティ境界が設定され、許可されたディレクトリ外のファイルへの不正アクセスを防止します。
書き込み操作：すべての出力ファイルはVIBE_CODER_OUTPUT_DIRディレクトリ（またはそのサブディレクトリ）に書き込まれます。この分離により、ツールは指定された出力場所にのみ書き込みを行うため、ソースコードが誤って変更されるのを防ぎます。

構造の例（デフォルトの場所）:

VibeCoderOutput/
  ├── research-manager/         # Research reports
  │   └── TIMESTAMP-QUERY-research.md
  ├── rules-generator/          # Development rules
  │   └── TIMESTAMP-PROJECT-rules.md
  ├── prd-generator/            # PRDs
  │   └── TIMESTAMP-PROJECT-prd.md
  ├── user-stories-generator/   # User stories
  │   └── TIMESTAMP-PROJECT-user-stories.md
  ├── task-list-generator/      # Task lists
  │   └── TIMESTAMP-PROJECT-task-list.md
  ├── fullstack-starter-kit-generator/  # Project templates
  │   └── TIMESTAMP-PROJECT/
  ├── code-map-generator/       # Code maps and diagrams
  │   └── TIMESTAMP-code-map/
  └── workflow-runner/          # Workflow outputs
      └── TIMESTAMP-WORKFLOW/

使用例

接続された AI アシスタントを介してツールを操作します。

調査: Research modern JavaScript frameworks
ルールの生成: Create development rules for a mobile banking application
PRD の生成: Generate a PRD for a task management application
ユーザーストーリーを生成する: Generate user stories for an e-commerce website
タスクリストの生成: Create a task list for a weather app based on [user stories]
シーケンシャルシンキング： Think through the architecture for a microservices-based e-commerce platform
フルスタックスターターキット: Create a starter kit for a React/Node.js blog application with user authentication
ワークフローの実行: Run workflow newProjectSetup with input { "projectName": "my-new-app", "description": "A simple task manager" }
コードベースのマップ: Generate a code map for the current project ( map-codebase path="./src" 、または、 Generate a JSON representation of the codebase structure with output_format="json"

ローカルで実行（オプション）

主な用途は AI アシスタントとの統合 (stdio を使用) ですが、テストのためにサーバーを直接実行することもできます。

実行モード

プロダクションモード（Stdio）：
```
npm start
```
- ログは stderr に出力されます (AI アシスタントの起動を模倣します)
- NODE_ENV=production を使用する
開発モード (Stdio、Pretty Logs):
```
npm run dev
```
- ログはきれいなフォーマットで標準出力に出力されます
- nodemonとpino-pretty必要です
- NODE_ENV=development を使用する
SSE モード (HTTP インターフェース):
```
# Production mode over HTTP
npm run start:sse

# Development mode over HTTP
npm run dev:sse
```
- stdioの代わりにHTTPを使用する
- .env の PORT で設定 (デフォルト: 3000)
- http://localhost:3000にアクセスします

詳細なトラブルシューティング

接続の問題

AIアシスタントでMCPサーバーが検出されない

構成パスを確認します:
- args配列の絶対パスが正しいことを確認します
- Windowsでもすべてのスラッシュがスラッシュ/であることを確認してください
- Node がそれを見つけられるかどうかをテストするには、直接node <path-to-build/index.js>を実行します。
構成形式を確認してください:
- JSONが構文エラーなしで有効であることを確認する
- プロパティ間のカンマが正しいことを確認してください
- mcpServersオブジェクトにサーバーが含まれていることを確認します
アシスタントを再起動します。
- アプリケーションを完全に閉じる（最小化ではなく）
- もう一度開いてお試しください

サーバーは起動するがツールが動作しない

無効フラグをチェック:
- "disabled": falseに設定されていることを確認する
- JSONは//コメントをサポートしていないため、削除してください。
autoApprove配列を検証します:
- autoApprove配列内のツール名が完全に一致していることを確認します
- ハイブリッドルーティングを使用している場合は、配列に"process-request"を追加してみてください。

APIキーの問題

OpenRouter の主な問題:
- キーが正しくコピーされたことを再確認する
- OpenRouterダッシュボードでキーがアクティブであることを確認します
- 十分なクレジットがあるか確認してください
環境変数の問題:
- 両方でキーが正しいことを確認します。
  - .envファイル (ローカル実行用)
  - AIアシスタントの設定envブロック

パスと権限の問題

ビルドディレクトリが見つかりません:
- npm run build実行してビルドディレクトリが存在することを確認します。
- ビルド出力が別のディレクトリに送られるかどうかを確認します（tsconfig.json を確認します）
ファイル権限エラー:
- ユーザーが workflow-agent-files ディレクトリへの書き込み権限を持っていることを確認します。
- Unixシステムでは、build/index.jsに実行権限があるか確認する

ログデバッグ

ローカル実行の場合:
- コンソール出力でエラーメッセージを確認します
- .envファイルでLOG_LEVEL=debug指定して実行してみてください
AIアシスタント実行の場合:
- env設定で"NODE_ENV": "production"に設定する
- アシスタントにログコンソールまたは出力ウィンドウがあるかどうかを確認します

ツール固有の問題

セマンティックルーティングが機能しない:
- 最初の実行では埋め込みモデルがダウンロードされる可能性があります - ダウンロードメッセージを確認してください
- ツール名を明記したより明確なリクエストを試してください

Available Tools

11 tools

analyze-dependenciesB

Analyzes dependency manifest files (currently supports package.json) to list project dependencies.

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	The relative path to the dependency manifest file (e.g., 'package.json', 'client/package.json', 'requirements.txt').

TDQS

B3.1/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 full burden for behavioral disclosure. While 'analyzes' and 'list project dependencies' imply a read-only operation, it doesn't explicitly state whether this requires specific permissions, what format the output takes, whether it handles errors gracefully, or any performance characteristics. For a tool with no annotation coverage, this is insufficient behavioral context.

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 extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place, with no redundant information. It's appropriately sized for a simple single-parameter tool.

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 simple read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more behavioral context about what the analysis produces and any limitations. The mention of 'currently supports package.json' suggests evolving capabilities but doesn't fully address completeness.

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 has 100% description coverage, with the single parameter 'filePath' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (which mentions multiple file types including 'requirements.txt' while the description only mentions 'package.json'). Baseline 3 is appropriate when schema does the heavy lifting.

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's purpose: analyzing dependency manifest files to list project dependencies. It specifies the verb 'analyzes' and resource 'dependency manifest files', and mentions current support for 'package.json'. However, it doesn't distinguish this tool from its siblings, which appear to be various generation and processing tools rather than dependency analysis tools.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or scenarios where this tool would be preferred over other approaches. The sibling tools are all different in function (code generation, summarization, refactoring), so no explicit comparison is needed, but no usage context is provided.

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

generate-code-stubB

Generates a code stub (function, class, etc.) in a specified language based on a description. Can optionally use content from a file (relative path) as context.

ParametersJSON Schema

Name	Required	Description
`classProperties`	No	For classes: list of properties with names, optional types, and descriptions.
`contextFilePath`	No	Optional relative path to a file whose content should be used as additional context.
`description`	Yes	Detailed description of what the stub should do, including its purpose, parameters, return values, or properties.
`language`	Yes	The programming language for the stub (e.g., 'typescript', 'python', 'javascript')
`methods`	No	For classes/interfaces: list of method signatures with names and descriptions.
`name`	Yes	The name of the function, class, interface, etc.
`parameters`	No	For functions/methods: list of parameters with names, optional types, and descriptions.
`returnType`	No	For functions/methods: the expected return type string.
`stubType`	Yes	The type of code structure to generate (function, class, etc.)

TDQS

B3.3/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 of behavioral disclosure. It mentions the core action ('Generates') and optional file context, but lacks details on permissions, rate limits, error handling, or what the generated output looks like (e.g., format, completeness). For a tool with 9 parameters and no annotations, this is a significant gap in transparency.

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 front-loaded and efficient: a single sentence that states the core purpose and key optional feature. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy for an AI agent to parse quickly.

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?

Given the tool's complexity (9 parameters, no output schema, no annotations), the description is incomplete. It covers the basic purpose but lacks details on behavioral traits, output format, or error scenarios. However, the high schema coverage (100%) mitigates some gaps, making it minimally adequate but with clear room for improvement.

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%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'language' and 'description' as key inputs and hinting at 'contextFilePath' as optional file context. It doesn't provide additional syntax, examples, or constraints beyond what's in the schema descriptions.

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's purpose: 'Generates a code stub (function, class, etc.) in a specified language based on a description.' It specifies the verb ('Generates'), resource ('code stub'), and key parameters (language, description). However, it doesn't explicitly differentiate from siblings like 'generate-fullstack-starter-kit' or 'refactor-code', which might also involve code generation.

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 usage context by mentioning 'based on a description' and 'optionally use content from a file as context,' but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'generate-fullstack-starter-kit' (which might be for larger projects) or 'refactor-code' (which modifies existing code). No exclusions or clear alternatives are stated.

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

generate-fullstack-starter-kitA

Generates full-stack project starter kits with custom tech stacks, research-informed recommendations, and setup scripts.

ParametersJSON Schema

Name	Required	Description
`include_optional_features`	No	Optional features to include (e.g., ['Docker', 'CI/CD'])
`request_recommendation`	No	Whether to request recommendations for tech stack components based on research
`tech_stack_preferences`	No	Optional tech stack preferences (e.g., { frontend: 'Vue', backend: 'Python' })
`use_case`	Yes	The specific use case for the starter kit (e.g., 'E-commerce site', 'Blog platform')

TDQS

A3.5/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 behavioral disclosure. While it mentions what the tool generates, it doesn't describe important behavioral aspects like whether this creates files/directories, requires specific permissions, has rate limits, or what the output looks like. For a generation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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, well-structured sentence that efficiently communicates the tool's core functionality without unnecessary words. It's front-loaded with the main purpose and includes three key features in a parallel structure, making every element earn its place.

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?

Given the tool's complexity (generating full-stack projects with multiple parameters) and the absence of both annotations and output schema, the description provides adequate but incomplete context. It covers what the tool does but lacks details about behavioral aspects and output format that would be helpful for an agent to use it effectively.

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 schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about what the tool generates overall. This meets the baseline expectation when schema coverage is complete.

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 purpose with specific verbs ('generates') and resources ('full-stack project starter kits'), and distinguishes it from siblings by specifying custom tech stacks, research-informed recommendations, and setup scripts. It goes beyond just restating the name to explain what the tool actually produces.

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 usage context through phrases like 'with custom tech stacks' and 'research-informed recommendations', suggesting when this tool might be appropriate. However, it doesn't explicitly state when to use it versus alternatives like 'generate-code-stub' or 'generate-prd' among the sibling tools, leaving some ambiguity about tool selection.

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

generate-git-summaryA

Retrieves a summary of current Git changes (diff). Can show staged or unstaged changes.

ParametersJSON Schema

Name	Required	Description	Default
`staged`	No	If true, get the summary for staged changes only. Defaults to false (unstaged changes).

TDQS

A3.5/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. It discloses that the tool retrieves summaries (implying read-only behavior) and specifies the scope (staged vs. unstaged changes). However, it lacks details on permissions, rate limits, or output format, leaving gaps in behavioral context.

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 concise sentences with zero waste, front-loaded with the main purpose. Every word earns its place by clarifying the tool's function and parameter context efficiently.

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?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter scope, but lacks details on output format or behavioral traits like error handling, which could be important for an AI 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 has 100% description coverage, so the schema already fully documents the 'staged' parameter. The description adds marginal value by mentioning 'staged or unstaged changes,' but doesn't provide additional syntax or format details beyond what the schema states.

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 verb ('retrieves') and resource ('summary of current Git changes'), specifying it's about diff information. It distinguishes between staged and unstaged changes, though it doesn't explicitly differentiate from sibling tools like 'generate-task-list' or 'process-request' which might also involve Git operations.

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 usage by mentioning 'staged or unstaged changes,' which suggests when to use it based on the type of changes needed. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'generate-task-list' for Git-related tasks or any exclusions.

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

generate-prdC

Creates comprehensive product requirements documents based on a product description and research.

ParametersJSON Schema

Name	Required	Description	Default
`productDescription`	Yes	Description of the product to create a PRD for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'creates' implies a write operation, it doesn't specify whether this generates new files, modifies existing ones, requires specific permissions, or has any rate limits. The description mentions 'based on research' but doesn't clarify if research is performed automatically or needs to be provided separately.

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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a single-parameter tool and front-loads the essential information.

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?

For a tool that creates comprehensive documents with no annotations and no output schema, the description is insufficient. It doesn't explain what 'comprehensive' means, what sections the PRD includes, whether it generates markdown/PDF/other formats, or what the return value looks like. The mention of 'research' is vague and unexplained.

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%, so the schema already documents the single parameter 'productDescription' with its constraints. The description adds minimal value beyond what's in the schema by mentioning this is 'based on a product description', but doesn't provide additional context about format expectations or examples.

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 verb 'creates' and the resource 'comprehensive product requirements documents', specifying it's based on product description and research. However, it doesn't explicitly differentiate from siblings like 'generate-user-stories' or 'generate-task-list' which might also create documentation artifacts.

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?

The description provides no guidance on when to use this tool versus alternatives like 'generate-user-stories' or 'generate-task-list' which might be more appropriate for specific documentation needs. There's no mention of prerequisites, constraints, or typical use cases.

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

generate-rulesC

Creates project-specific development rules based on product description, user stories, and research.

ParametersJSON Schema

Name	Required	Description
`productDescription`	Yes	Description of the product being developed
`ruleCategories`	No	Optional categories of rules to generate (e.g., 'Code Style', 'Security')
`userStories`	No	Optional user stories to inform the rules

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 full burden for behavioral disclosure. While 'Creates' implies a write operation, the description doesn't specify what kind of rules are generated, format of output, whether this is a one-time generation or iterative process, or any permissions/rate limits. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that front-loads the core purpose. Every word earns its place by specifying what is created and what inputs inform the creation. There's no redundancy or unnecessary elaboration.

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?

For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the rules take, whether they're returned as text/structured data, or what the scope/limitations of the generation are. Given the complexity of rule generation and lack of structured output information, the description should provide more context about the tool's behavior and results.

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%, so the schema already documents all three parameters thoroughly. The description mentions the same parameters (product description, user stories, research) but adds no additional semantic context beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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's purpose: 'Creates project-specific development rules' with specific inputs (product description, user stories, research). It uses a specific verb ('Creates') and identifies the resource ('development rules'), but doesn't explicitly differentiate from sibling tools like 'generate-task-list' or 'generate-prd' that might also create project artifacts.

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?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'generate-task-list', 'generate-user-stories', and 'generate-prd' that also generate project artifacts, there's no indication of when rule generation is appropriate versus task generation or requirements documentation. No exclusions or prerequisites are mentioned.

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

generate-task-listC

Creates structured development task lists with dependencies based on product description, user stories, and research.

ParametersJSON Schema

Name	Required	Description	Default
`productDescription`	Yes	Description of the product
`userStories`	Yes	User stories (in Markdown format) to use for task list generation

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 full burden. It states the tool 'creates' (implying a write/mutation operation) but doesn't disclose behavioral traits like whether it's idempotent, what format the output takes, if it has rate limits, or if it requires specific permissions. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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?

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words. However, it could be slightly more structured by separating purpose from input details, but this is minor.

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?

Given the tool creates task lists (a non-trivial operation), has no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., format, structure of dependencies), potential side effects, or error conditions. For a creation tool with these gaps, more context is needed to use it effectively.

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%, so the schema already documents both parameters ('productDescription' and 'userStories') with descriptions and constraints. The description adds marginal value by listing these inputs ('based on product description, user stories, and research'), but doesn't provide additional semantics beyond what's in the schema (e.g., it mentions 'research' which isn't a parameter). Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Creates structured development task lists with dependencies' - a specific verb ('creates') and resource ('task lists'). It mentions the inputs ('based on product description, user stories, and research'), which helps distinguish it from siblings like 'generate-user-stories' or 'generate-prd'. However, it doesn't explicitly differentiate from all siblings (e.g., 'analyze-dependencies' might overlap).

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or compare to siblings like 'generate-fullstack-starter-kit' or 'process-request'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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

generate-user-storiesC

Creates detailed user stories with acceptance criteria based on a product description and research.

ParametersJSON Schema

Name	Required	Description	Default
`productDescription`	Yes	Description of the product to create user stories for

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 of behavioral disclosure. It states the tool 'creates' user stories, implying a generative/mutation operation, but doesn't address permissions, side effects, rate limits, or output format. This leaves significant gaps for a tool that likely produces structured content.

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, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function and scope, making it easy to parse quickly.

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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the generated user stories look like, how many are produced, or any behavioral traits like error handling. For a generative tool with no structured output documentation, this leaves the agent with insufficient information.

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 description adds minimal value beyond the input schema, which has 100% coverage. It mentions 'product description and research' as inputs, but the schema only includes 'productDescription' (with a description field). The description doesn't clarify the 'research' aspect or provide additional context for the parameter's use.

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's purpose: 'Creates detailed user stories with acceptance criteria based on a product description and research.' It specifies the verb ('creates'), resource ('user stories'), and scope ('detailed' with 'acceptance criteria'), though it doesn't explicitly differentiate from sibling tools like 'generate-prd' or 'generate-task-list'.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over sibling tools such as 'generate-prd' (for product requirements) or 'generate-task-list' (for tasks), nor does it specify prerequisites or exclusions for usage.

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

process-requestA

Processes natural language requests, determines the best tool using semantic matching and fallbacks, and either asks for confirmation or executes the tool directly.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	Natural language request to process and route to the appropriate tool

TDQS

A3.5/5.0

Behavior3/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 discloses key behavioral traits: semantic matching with fallbacks, and conditional execution (confirmation or direct execution). However, it doesn't cover aspects like error handling, performance characteristics, rate limits, or authentication needs. For a routing tool with no annotation coverage, this provides basic but incomplete behavioral context.

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, well-structured sentence that efficiently conveys the tool's purpose, mechanism, and outcome. It is front-loaded with the core function and avoids unnecessary details, making every word earn its place.

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?

Given the tool's complexity (routing with semantic matching) and lack of annotations or output schema, the description is moderately complete. It explains the core behavior but omits details like return values, error cases, or integration with sibling tools. For a routing tool without structured output documentation, it should provide more context on what happens after processing.

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 schema description coverage is 100%, with the single parameter 'request' documented as 'Natural language request to process and route to the appropriate tool'. The description adds no additional parameter semantics beyond what the schema provides, such as examples or format details. With high schema coverage, the baseline score of 3 is appropriate.

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's function: 'Processes natural language requests, determines the best tool using semantic matching and fallbacks, and either asks for confirmation or executes the tool directly.' This specifies the verb ('processes'), resource ('natural language requests'), and core mechanism ('semantic matching and fallbacks'). However, it doesn't explicitly differentiate from sibling tools like 'analyze-dependencies' or 'generate-prd', which appear to be specialized generators rather than request routers.

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 usage context: it's for processing natural language requests to route to tools. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., direct tool invocation or other routing mechanisms) or provide exclusions. The context is clear but lacks explicit guidance on alternatives or prerequisites.

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

refactor-codeC

Refactors a given code snippet based on specific instructions, optionally using surrounding file context.

ParametersJSON Schema

Name	Required	Description
`codeContent`	Yes	The actual code snippet to be refactored.
`contextFilePath`	No	Optional relative path to a file whose content provides broader context for the refactoring task.
`language`	Yes	The programming language of the code snippet (e.g., 'typescript', 'python', 'javascript')
`refactoringInstructions`	Yes	Specific instructions on how the code should be refactored (e.g., 'extract the loop into a separate function', 'improve variable names', 'add error handling', 'convert promises to async/await').

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 of behavioral disclosure. While it states the tool refactors code based on instructions, it doesn't describe what 'refactor' entails operationally—e.g., whether it modifies code in-place, returns transformed code, handles errors, requires specific permissions, or has rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose without unnecessary words. It clearly states what the tool does and includes the optional context aspect, making every part of the sentence earn its place.

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?

Given the complexity of a code refactoring tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'refactor' means in practice, what the output looks like (e.g., transformed code, error messages), or behavioral aspects like safety or limitations. For a 4-parameter tool that performs mutations, more context is needed to guide effective use.

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%, with all parameters well-documented in the schema itself. The description adds minimal value beyond the schema, mentioning 'code snippet' and 'surrounding file context' which align with 'codeContent' and 'contextFilePath' parameters but don't provide additional semantic context. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Refactors a given code snippet based on specific instructions, optionally using surrounding file context.' It specifies the verb ('refactors'), resource ('code snippet'), and scope ('optionally using surrounding file context'). However, it doesn't explicitly distinguish this tool from sibling tools like 'generate-code-stub' or 'analyze-dependencies', which might also involve code manipulation.

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?

The description provides no guidance on when to use this tool versus alternatives. It mentions optional context usage but doesn't specify scenarios where this tool is appropriate compared to siblings like 'generate-code-stub' for creating new code or 'analyze-dependencies' for code analysis. There's no mention of prerequisites, limitations, or typical use cases.

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

researchC

Performs deep research on a given topic using Perplexity Sonar and enhances the result.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The research query or topic to investigate

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 of behavioral disclosure. It mentions 'enhances the result' but doesn't explain what this entails—whether it involves summarization, citation, formatting, or other processing. It also omits details like rate limits, authentication needs, or potential side effects, leaving significant gaps for an AI agent to understand the tool's behavior.

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?

The description is concise and front-loaded in a single sentence, efficiently stating the core action and method. There's no wasted verbiage, and it directly addresses the tool's function. However, it could be slightly more structured by separating purpose from enhancement details, but it remains clear and to the point.

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?

Given the complexity of a research tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'enhances the result' means, the format or depth of output, or any behavioral traits. For a tool that likely produces rich, variable outputs, this lack of detail makes it inadequate for an AI agent to use effectively without trial and error.

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 description adds minimal semantic context beyond the input schema, which has 100% coverage for the single parameter 'query'. It implies the parameter is a research topic but doesn't elaborate on format, scope, or examples. Since schema coverage is high, the baseline is 3, but the description doesn't compensate with additional insights like expected query types or limitations.

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's purpose: 'Performs deep research on a given topic using Perplexity Sonar and enhances the result.' It specifies the verb ('performs deep research'), resource ('topic'), and method ('using Perplexity Sonar'), distinguishing it from sibling tools like 'generate-prd' or 'analyze-dependencies'. However, it doesn't explicitly differentiate from potential similar tools not present in the sibling list.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention specific contexts, prerequisites, or exclusions. For example, it doesn't clarify if this is for technical research, market analysis, or general inquiries, nor does it compare to siblings like 'process-request' or 'generate-task-list' that might overlap in information gathering.

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.

11 tool updatesv1.0.0Apr 1, 2025
- First observedanalyze-dependencies
- First observedgenerate-code-stub
- First observedgenerate-fullstack-starter-kit
- First observedgenerate-git-summary
- First observedgenerate-prd
- First observedgenerate-rules
- First observedgenerate-task-list
- First observedgenerate-user-stories
- First observedprocess-request
- First observedrefactor-code
- First observedresearch

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.1/5.0

Scored 2026-04-18 10:40 across 11 tools

Disambiguation3/5

Most tools have distinct purposes (e.g., generate-code-stub vs. refactor-code vs. analyze-dependencies), but there is some overlap in the generative tools (generate-prd, generate-rules, generate-task-list, generate-user-stories) which all involve creating project artifacts from similar inputs, potentially causing confusion. The process-request tool is also ambiguous as it acts as a meta-tool that could interfere with direct tool selection.

Naming Consistency4/5

Tool names follow a consistent verb-noun pattern with hyphens (e.g., generate-code-stub, analyze-dependencies, refactor-code), which is clear and predictable. However, process-request deviates slightly by using a more generic verb and not fitting the 'generate/analyze/refactor' pattern, though it remains readable.

Tool Count4/5

With 11 tools, the count is reasonable for a code and project assistance server, covering areas like code generation, refactoring, dependency analysis, and project planning. It's slightly on the higher side but well-scoped, as most tools serve distinct functions without being overwhelming.

Completeness3/5

The tool set covers key areas for coding and project development (e.g., code generation, refactoring, dependency analysis, Git summaries, and project documentation generation), but there are notable gaps such as missing code testing, deployment, or debugging tools. The research tool adds value, but the surface feels incomplete for end-to-end development workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5365
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Arthur
moechehabb
-
license
Not graded
quality
Not graded
maintenance
An MCP server that enables developers to summon AI development team agents directly from their IDE to help with tasks like PR reviews, security evaluation, and CI/CD deployment setup.
Updated a year ago (2025-10-12 01:37 UTC)
-
Jilebi
Developer Tools
Datron
A
license
Not graded
quality
B
maintenance
A plugin-based MCP server that enables AI assistants to interact with external systems through custom tools, resources, and prompts.
Updated 7 days ago (2026-10-01 14:06 UTC)
4
AGPL 3.0
Kortx MCP Server
AI & Machine Learning Search Developer Tools
effatico
A
license
A
quality
C
maintenance
A lightweight MCP server that provides coding copilots with access to GPT-5, Perplexity Sonar, and GPT Image models, offering tools for planning, debugging, research, and image generation.
Updated 10 months ago (2025-11-28 08:47 UTC)
8
26 npm
4
MIT
mcdev-mcp
Games & Gamification Code Analysis Autonomous Agents
use-ai-for-mc
A
license
A
quality
B
maintenance
An MCP server that empowers AI coding agents to work effectively with Minecraft mod development, providing static analysis of decompiled source code and runtime interaction with a running Minecraft instance.
Updated a month ago (2026-08-31 10:27 UTC)
31
45 npm
14
MIT

Vibe Coder MCP サーバー

概要と機能

セットアップガイド

ステップ1: 前提条件

ステップ2: コードを取得する

ステップ3: セットアップスクリプトを実行する

ステップ4: 環境変数（ .env ）を構成する

ステップ5：AIアシスタントとの統合（MCP設定）

5.1: クライアントのMCP設定ファイルを見つける

5.2: Vibe Coder 設定を追加する

ステップ6: 構成をテストする

プロジェクトアーキテクチャ

ディレクトリ構造

ツールレジストリパターン

連続的な思考プロセス

セッション状態管理

ワークフロー実行エンジン

ワークフロー構成

ファイルの場所と構造

パラメータテンプレート

ワークフローのトリガー

詳細なツールドキュメント

ツールカテゴリ

分析および情報ツール

計画およびドキュメントツール

プロジェクトスキャフォールディングツール

ワークフローとオーケストレーション

生成されたファイルの保存

読み取りおよび書き込み操作のセキュリティ境界

使用例

ローカルで実行（オプション）

実行モード

詳細なトラブルシューティング

接続の問題

AIアシスタントでMCPサーバーが検出されない

サーバーは起動するがツールが動作しない

APIキーの問題

パスと権限の問題

ログデバッグ

ツール固有の問題

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

ステップ4: 環境変数（ `.env` ）を構成する