LLM 기반 코딩을 위한 구조화된 개발 워크플로를 구현하는 모델 컨텍스트 프로토콜 서버입니다.
이 MCP 서버는 다음을 제공하여 LLM이 체계적이고 깔끔하며 안전한 방식으로 기능을 구축하는 데 도움을 줍니다.
가이드 질문을 통한 구조화된 기능 설명 프로세스
PRD 및 구현 계획 생성
작업 추적을 통한 단계적 개발
진행 상황 추적 및 상태 보고
문서 저장 및 검색 기능
Related MCP server: DevFlow MCP Server
기능 세부 정보, PRD 및 구현 계획
진행 상황 보고서 및 상태 추적
단계 및 작업 세부 정보
start_feature_clarification - 기능 설명 프로세스 시작
provide_clarification - 기능에 대한 설명 질문에 답변합니다.
generate_prd - 제품 요구 사항 문서 및 구현 계획 생성
create_phase - 기능에 대한 개발 단계 생성
add_task - 개발 단계에 작업 추가
update_phase_status - 단계 상태 업데이트
update_task_status - 작업 완료 상태 업데이트
get_next_phase_action - 다음에 무엇을 해야 할지에 대한 지침을 받으세요
get_document_path - 생성된 문서의 경로를 가져옵니다.
save_document - 문서를 특정 위치에 저장합니다.
feature-planning - 기능 개발 계획을 위한 신속한 템플릿
서버에는 다음과 같은 하이브리드 문서 저장 시스템이 포함되어 있습니다.
생성된 문서(PRD, 구현 계획)를 자동으로 파일에 저장합니다.
빠른 액세스를 위해 메모리 내 사본을 유지합니다.
클라이언트가 문서 경로를 검색하고 사용자 정의 위치에 저장할 수 있습니다.
문서는 기본적으로 documents/{featureId}/ 디렉토리에 저장되며, 파일 이름은 문서 유형에 따라 달라집니다.
documents/{featureId}/prd.md - 제품 요구 사항 문서
documents/{featureId}/implementation-plan.md - 구현 계획
save_document 도구를 사용하면 문서를 사용자 정의 위치에 저장할 수 있습니다.
지엑스피1
문서 경로를 얻으려면 get_document_path 도구를 사용하세요.
{
"featureId": "feature-123",
"documentType": "prd"
}이는 경로와 문서가 디스크에 저장되었는지 여부를 모두 반환합니다.
종속성 설치:
npm install서버를 빌드하세요:
npm run build자동 재빌드를 사용한 개발의 경우:
npm run watch호환되는 MCP 클라이언트와 함께 사용하려면:
MacOS의 경우: ~/Library/Application Support/Claude/claude_desktop_config.json Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"vibe-coder-mcp": {
"command": "/path/to/vibe-coder-mcp/build/mcp-server.js"
}
}
}MCP 서버는 stdio를 통해 통신하므로 디버깅이 어려울 수 있습니다. 패키지 스크립트로 제공되는 MCP Inspector를 사용하는 것이 좋습니다.
npm run inspector검사기는 브라우저에서 디버깅 도구에 액세스할 수 있는 URL을 제공합니다.
이 서버는 Model Context Protocol TypeScript SDK의 고수준 McpServer 클래스를 사용하여 구현됩니다. 이 클래스는 리소스, 도구 및 프롬프트를 정의하기 위한 깔끔한 API를 제공하여 MCP 서버를 만드는 프로세스를 간소화합니다.
import { McpServer, ResourceTemplate } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
// Create an MCP server
const server = new McpServer({
name: "Vibe-Coder",
version: "0.3.0"
});
// Add a resource
server.resource(
"features-list",
"features://list",
async (uri) => ({ /* ... */ })
);
// Add a tool
server.tool(
"start_feature_clarification",
{ /* parameters schema */ },
async (params) => ({ /* ... */ })
);
// Add a prompt
server.prompt(
"feature-planning",
{ /* parameters schema */ },
(params) => ({ /* ... */ })
);
// Start the server
const transport = new StdioServerTransport();
await server.connect(transport);Vibe-Coder MCP 서버는 다음 단계에 따라 개발 프로세스를 안내하도록 설계되었습니다.
기능 설명 : 요구 사항을 수집하고 기능의 목적, 대상 사용자 및 제약 조건을 이해하는 것으로 시작합니다.
문서화 : 명확화된 요구 사항을 기반으로 PRD 및 구현 계획을 생성합니다.
단계적 개발 : 명확한 작업을 통해 구현을 논리적 단계로 구분합니다.
진행 상황 추적 : 개발을 안내하기 위해 작업 및 단계 완료를 모니터링합니다.
완료 : 모든 요구 사항이 구현되었고 기능을 사용할 준비가 되었는지 확인합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| phaseId | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| name | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| documentType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| question | Yes | ||
| answer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| documentType | Yes | ||
| filePath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureName | Yes | ||
| initialDescription | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| phaseId | Yes | ||
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| phaseId | Yes | ||
| taskId | Yes | ||
| completed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_taskcreate_phasegenerate_prdget_document_pathget_next_phase_actionprovide_clarificationsave_documentstart_feature_clarificationupdate_phase_statusupdate_task_statusScored across 10 tools
The tools cover distinct aspects of a project management or coding workflow (e.g., task management, phase handling, document operations, and clarification processes), but some overlap exists—such as 'add_task' and 'update_task_status' being clearly related, and 'start_feature_clarification' and 'provide_clarification' potentially serving similar clarification purposes. Without descriptions, it's harder to fully disambiguate, but the tool names suggest reasonable separation for core functions.
Most tools follow a consistent verb_noun or verb_adjective_noun pattern (e.g., 'add_task', 'create_phase', 'update_task_status'), which aids readability and predictability. However, there are minor deviations like 'generate_prd' (using an acronym) and 'get_next_phase_action' (which is slightly longer but still follows the pattern), keeping the naming mostly uniform across the set.
With 10 tools, the count is well-scoped for a server focused on project or feature development workflows. This number allows coverage of key operations (e.g., task and phase management, document handling, clarification processes) without being overwhelming, fitting typical MCP server ranges and the inferred domain scope effectively.
Inferring a domain of project or feature development management, the tools cover creation and updates for tasks and phases, document operations, and clarification steps, but there are notable gaps. For example, there are no tools for deleting tasks/phases, listing or retrieving existing items (beyond 'get_document_path'), or handling broader project settings, which could limit agent workflows in a full lifecycle.
MCP server for generating rough-draft project plans from natural-language prompts.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
LLM Orchestration MCP Agent
Spec-driven development MCP server: 8 phases, bi-directional traceability, 7 quality gates.
