Which integrations are available for this server?

Utilizes the Model Context Protocol TypeScript SDK for implementing the server, providing an API for defining resources, tools, and prompts.

How do I use Vibe-Coder MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Vibe-Coder MCP Server start feature clarification for a new user authentication system" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

Vibe-Coder MCP Server

by crazyrabbitLTC

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Vibe-Coder MCP Server

A Model Context Protocol server that implements a structured development workflow for LLM-based coding.

Overview

This MCP server helps LLMs build features in an organized, clean, and safe manner by providing:

A structured feature clarification process with guided questions
PRD and implementation plan generation
Phased development with task tracking
Progress tracking and status reporting
Document storage and retrieval capabilities

Related MCP server: DevFlow MCP Server

Features

Resources

Feature details, PRDs, and implementation plans
Progress reports and status tracking
Phase and task details

Tools

start_feature_clarification - Begin the feature clarification process
provide_clarification - Answer clarification questions about a feature
generate_prd - Generate a Product Requirements Document and implementation plan
create_phase - Create a development phase for a feature
add_task - Add tasks to a development phase
update_phase_status - Update the status of a phase
update_task_status - Update the completion status of a task
get_next_phase_action - Get guidance on what to do next
get_document_path - Get the path of a generated document
save_document - Save a document to a specific location

Prompts

feature-planning - A prompt template for planning feature development

Document Storage

The server includes a hybrid document storage system that:

Automatically saves generated documents (PRDs, implementation plans) to files
Maintains an in-memory copy for quick access
Allows clients to retrieve document paths and save to custom locations

Default Storage Location

Documents are stored in the documents/{featureId}/ directory by default, with filenames based on document type:

documents/{featureId}/prd.md - Product Requirements Document
documents/{featureId}/implementation-plan.md - Implementation Plan

Custom Storage

You can use the save_document tool to save documents to custom locations:

{
  "featureId": "feature-123",
  "documentType": "prd",
  "filePath": "/custom/path/feature-123-prd.md"
}

Path Retrieval

To get the path of a document, use the get_document_path tool:

{
  "featureId": "feature-123",
  "documentType": "prd"
}

This returns both the path and whether the document has been saved to disk.

Development

Install dependencies:

npm install

Build the server:

npm run build

For development with auto-rebuild:

npm run watch

Installation

To use with compatible MCP clients:

On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "vibe-coder-mcp": {
      "command": "/path/to/vibe-coder-mcp/build/mcp-server.js"
    }
  }
}

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

Implementation Notes

This server is implemented using the high-level McpServer class from the Model Context Protocol TypeScript SDK, which simplifies the process of creating MCP servers by providing a clean API for defining resources, tools, and prompts.

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);

Workflow

The Vibe-Coder MCP server is designed to guide the development process through the following steps:

Feature Clarification: Start by gathering requirements and understanding the feature's purpose, target users, and constraints
Documentation: Generate a PRD and implementation plan based on the clarified requirements
Phased Development: Break down the implementation into logical phases with clear tasks
Progress Tracking: Monitor the completion of tasks and phases to guide development
Completion: Verify that all requirements have been implemented and the feature is ready for use

Available Tools

10 tools

add_taskD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`phaseId`	Yes
`description`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

create_phaseD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`name`	Yes
`description`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

generate_prdD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

get_document_pathD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`documentType`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

get_next_phase_actionD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

provide_clarificationD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`question`	Yes
`answer`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

save_documentD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`documentType`	Yes
`filePath`	No

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

start_feature_clarificationD

ParametersJSON Schema

Name	Required	Description	Default
`featureName`	Yes
`initialDescription`	No

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

update_phase_statusD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`phaseId`	Yes
`status`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

update_task_statusD

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes
`phaseId`	Yes
`taskId`	Yes
`completed`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

Tool Schema Changelog

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

10 tool updatesAug 15, 2025
- First observedadd_task
- First observedcreate_phase
- First observedgenerate_prd
- First observedget_document_path
- First observedget_next_phase_action
- First observedprovide_clarification
- First observedsave_document
- First observedstart_feature_clarification
- First observedupdate_phase_status
- First observedupdate_task_status

Install Server

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

TDQS

D1.8/5.0

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness3/5

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.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113398
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
llm-orchestration-mcp-agent
ai.getvda
LLM Orchestration MCP Agent
1
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
1

Related MCP Servers

Spec-driven Development MCP
Developer Tools Coding Agents CI/CD & DevOps
kevinlin
A
license
B
quality
D
maintenance
An MCP server that enables AI-powered IDEs to implement a structured development workflow from requirements gathering to code implementation, guiding users through goal collection, requirements specification, design documentation, task planning, and execution.
Updated 8 months ago (2026-01-13 01:55 UTC)
9
17
21
MIT
DevFlow MCP Server
Project Management Developer Tools
KlausFreiberufler
A
license
A
quality
B
maintenance
MCP server that integrates DevFlow with AI code assistants to enforce structured development workflows including planning, task tracking, and code review gates.
Updated 3 days ago (2026-09-03 09:45 UTC)
65
247
1
MIT
Accordo
Developer Tools Coding Agents Autonomous Agents
AndurilCode
A
license
Not graded
quality
D
maintenance
A YAML-driven workflow guidance MCP server that enables AI coding agents to follow structured development workflows with real-time state tracking and progression control.
Updated 10 months ago (2025-10-27 20:12 UTC)
5
MIT
Architect-to-Product (A2P)
Developer Tools CI/CD & DevOps Software Architecture
BernhardJackiewicz
A
license
Not graded
quality
C
maintenance
An MCP server that adds engineering discipline to AI-assisted development, enforcing evidence-gated TDD, security review, backup strategy, and deployment generation to turn AI-generated code into production-ready software.
Updated 2 months ago (2026-07-12 18:40 UTC)
21
10
MIT

Appeared in Searches

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/crazyrabbitLTC/mcp-vibecoder'

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