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는 Cursor, Cline AI, Claude Desktop과 같은 AI 비서에 강력한 소프트웨어 개발 도구를 제공하도록 설계된 MCP(모델 컨텍스트 프로토콜) 서버입니다. 조사, 계획, 요구사항 생성, 초기 프로젝트 생성 등 다양한 작업에 도움을 줍니다!

개요 및 기능

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단계: 코드 받기

프로젝트 디렉토리 만들기 (선택 사항):
- 터미널이나 명령 프롬프트를 엽니다.
- 프로젝트를 저장할 위치로 이동합니다.
  지엑스피1
저장소 복제:
- 달리다:
  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/ )가 사용됩니다.
코드맵 생성기 디렉토리 구성(선택 사항):
- code-map-generator 도구가 스캔할 수 있는 디렉토리를 지정하려면 .env 파일에 다음 줄을 추가하세요.
  CODE_MAP_ALLOWED_DIR=/path/to/your/source/code/directory
- 분석하려는 소스 코드가 있는 디렉터리의 절대 경로 로 경로를 바꾸세요. 이는 보안 경계이므로 도구는 이 디렉터리 외부의 파일에는 접근하지 않습니다.
- 보안상의 이유로 CODE_MAP_ALLOWED_DIR (소스 코드 읽기용)과 VIBE_CODER_OUTPUT_DIR (출력 파일 쓰기용)은 별개입니다. code-map-generator 도구는 읽기 및 쓰기 작업에 대해 별도의 유효성 검사를 사용합니다.
다른 설정 검토(선택 사항):
- LOG_LEVEL (예: LOG_LEVEL=debug ) 또는 NODE_ENV (예: NODE_ENV=development )와 같이 서버에서 지원하는 다른 환경 변수를 추가할 수 있습니다.
.env 파일을 저장합니다.

5단계: AI Assistant와 통합(MCP 설정)

이 중요한 단계에서는 클라이언트의 MCP 설정 파일에 구성을 추가하여 Vibe Coder를 AI 어시스턴트에 연결합니다.

5.1: 클라이언트의 MCP 설정 파일 찾기

위치는 AI 비서에 따라 다릅니다.

커서 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 코드 확장):
- 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
- 리눅스 : ~/.config/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
- (참고: Cursor 대신 표준 VS Code를 사용하는 경우 경로에서 Cursor``Code 로 바꾸세요)
클로드 데스크탑:
- 윈도우 : %APPDATA%\Claude\claude_desktop_config.json
- macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
- 리눅스 : ~/.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

순차적 사고 과정

순차적 사고 메커니즘은 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

워크플로 실행 엔진

Workflow 시스템은 여러 단계의 시퀀스를 가능하게 합니다.

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 파일에 포괄적인 설명서를 포함하고 있습니다. 이 파일에는 다음 내용이 포함되어 있습니다.

도구 개요 및 목적
입력/출력 사양
워크플로 다이어그램(Mermaid)
사용 예
사용된 시스템 프롬프트
오류 처리 세부 정보

자세한 내용은 다음 개별 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 다이어그램이 포함된 사람이 읽을 수 있는 마크다운 맵이나 가져오기 및 향상된 클래스 속성 정보를 위한 절대 파일 경로가 포함된 구조화된 JSON 표현을 생성합니다.
연구 관리자( research-manager ) : Perplexity Sonar를 사용하여 기술 주제에 대한 심층 연구를 수행하고 요약과 출처를 제공합니다.

계획 및 문서화 도구

규칙 생성기( generate-rules ): 프로젝트별 개발 규칙과 가이드라인을 생성합니다.
PRD 생성기( generate-prd ): 포괄적인 제품 요구 사항 문서를 생성합니다.
사용자 스토리 생성기( generate-user-stories ): 수용 기준이 포함된 자세한 사용자 스토리를 생성합니다.
작업 목록 생성기( generate-task-list ): 종속성을 포함한 구조화된 개발 작업 목록을 작성합니다.

프로젝트 스캐폴딩 도구

Fullstack Starter Kit Generator( generate-fullstack-starter-kit ): 기본 설정 스크립트 및 구성을 포함하여 지정된 프런트엔드/백엔드 기술을 사용하여 맞춤형 프로젝트 스타터 키트를 생성합니다.

워크플로 및 오케스트레이션

워크플로우 러너( run-workflow ): 일반적인 개발 작업을 위해 미리 정의된 도구 호출 시퀀스를 실행합니다.

생성된 파일 저장소

기본적으로 생성기 도구의 출력은 프로젝트 내의 VibeCoderOutput/ 디렉터리에 기록 참조용으로 저장됩니다. 이 위치는 .env 파일 또는 AI Assistant 구성에서 VIBE_CODER_OUTPUT_DIR 환경 변수를 설정하여 재정의할 수 있습니다.

읽기 및 쓰기 작업에 대한 보안 경계

보안상의 이유로 Vibe Coder MCP 도구는 읽기 및 쓰기 작업에 대해 별도의 보안 경계를 유지합니다.

읽기 작업 : code-map-generator와 같은 도구는 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
Fullstack Starter Kit: 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
```
- 로그는 보기 좋은 포맷으로 stdout으로 전송됩니다.
- 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 Assistant에서 MCP 서버가 감지되지 않음

구성 경로 확인:
- args 배열의 절대 경로가 올바른지 확인하세요
- 모든 슬래시가 정방향 슬래시인지 확인하십시오 / Windows에서도 마찬가지입니다.
- Node에서 찾을 수 있는지 테스트하려면 node <path-to-build/index.js> 직접 실행하세요.
구성 형식 확인:
- JSON이 구문 오류 없이 유효한지 확인하세요.
- 속성 사이의 쉼표가 올바른지 확인하세요
- mcpServers 개체에 서버가 포함되어 있는지 확인하세요.
어시스턴트를 다시 시작합니다.
- 응용 프로그램을 완전히 닫으세요(단순히 최소화하는 것이 아니라)
- 다시 열어서 다시 시도하세요

서버는 시작되지만 도구가 작동하지 않습니다

비활성화된 플래그 확인:
- "disabled": false 설정되어 있는지 확인하세요.
- JSON이 지원하지 않으므로 // 주석을 제거하세요.
autoApprove 배열 확인:
- autoApprove 배열의 도구 이름이 정확히 일치하는지 확인하세요.
- 하이브리드 라우팅을 사용하는 경우 배열에 "process-request" 를 추가해 보세요.

API 키 문제

OpenRouter 주요 문제:
- 키가 올바르게 복사되었는지 다시 한번 확인하세요
- OpenRouter 대시보드에서 키가 활성화되어 있는지 확인하세요.
- 충분한 크레딧이 있는지 확인하세요
환경 변수 문제:
- 다음 두 가지 모두에서 키가 올바른지 확인하세요.
  - .env 파일(로컬 실행용)
  - AI 어시스턴트의 구성 환경 블록

경로 및 권한 문제

빌드 디렉토리를 찾을 수 없습니다:
- npm run build 실행하여 빌드 디렉토리가 있는지 확인하세요.
- 빌드 출력이 다른 디렉토리로 이동하는지 확인하세요(tsconfig.json 확인)
파일 권한 오류:
- 사용자에게 workflow-agent-files 디렉토리에 대한 쓰기 액세스 권한이 있는지 확인하세요.
- Unix 시스템에서 build/index.js에 실행 권한이 있는지 확인하세요.

로그 디버깅

지역 실행의 경우:
- 오류 메시지에 대한 콘솔 출력을 확인하세요.
- .env 파일에서 LOG_LEVEL=debug 로 실행해보세요.
AI Assistant 실행의 경우:
- 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 Assistant와 통합(MCP 설정)

5.1: 클라이언트의 MCP 설정 파일 찾기

5.2: Vibe Coder 구성 추가

6단계: 구성 테스트

프로젝트 아키텍처

디렉토리 구조

도구 레지스트리 패턴

순차적 사고 과정

세션 상태 관리

워크플로 실행 엔진

워크플로 구성

파일 위치 및 구조

매개변수 템플릿

워크플로 트리거

자세한 도구 설명서

도구 카테고리

분석 및 정보 도구

계획 및 문서화 도구

프로젝트 스캐폴딩 도구

워크플로 및 오케스트레이션

생성된 파일 저장소

읽기 및 쓰기 작업에 대한 보안 경계

사용 예

로컬에서 실행(선택 사항)

실행 모드

자세한 문제 해결

연결 문제

AI Assistant에서 MCP 서버가 감지되지 않음

서버는 시작되지만 도구가 작동하지 않습니다

API 키 문제

경로 및 권한 문제

로그 디버깅

도구별 문제

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

4단계: 환경 변수( `.env` ) 구성