Skip to main content
Glama

Vibe Coder MCP Server

npm version npm downloads npm total downloads GitHub release Node.js Version License GitHub stars

Vibe Coder is an MCP (Model Context Protocol) server designed to supercharge your AI assistant (like Cursor, Cline AI, or Claude Desktop) with powerful tools for software development. It helps with research, planning, generating requirements, creating starter projects, and more!

🆕 What's New in Version 0.3.5

🎉 Latest Release - Enhanced CLI, REPL, and Parameter Extraction

Major Improvements:

  • ✨ Complete Hybrid Matcher Overhaul: All 15 MCP tools now have comprehensive parameter extraction

  • 🚀 CLI/REPL Experience: Interactive confirmations, job status polling with visual progress

  • 🔧 Fixed Critical Bugs: Task-list-generator auto-generates user stories, multi-turn conversations work flawlessly

  • 📊 Better Tool Matching: Multi-strategy approach (keyword 35%, pattern 30%, semantic 15%, LLM 20%)

  • ⚡ TypeScript Strict Mode: Zero any types, all explicit typing, production-grade code quality

User Experience Enhancements:

  • Low-confidence matches now prompt for user confirmation

  • Visual progress indicators for long-running jobs

  • Cleaner output with JSON log filtering in interactive mode

  • Session persistence across commands

  • Enhanced error messages and validation feedback

Previous Notable Releases

Version 0.3.1 - Global Installation & Synchronization

  • Fixed global/local version synchronization issues

  • Enhanced clean build process for installations

  • Improved packaging workflow for NPM publication

Version 0.2.8 - CLI Interactive Mode

  • Fixed configuration persistence in interactive mode

  • Enhanced project root detection for CLI users

  • Improved context-aware configuration

Version 0.2.3 - Interactive REPL & Setup Wizard

  • Interactive REPL Mode with chat-style interface and session persistence

  • Enhanced Setup Wizard with automatic first-run detection

  • Configuration Templates in src/config-templates/

  • Performance Improvements with optimized memory usage

  • Unified CLI Binary - single vibe command for all operations

Related MCP server: Jilebi

🚀 Quick Start

# Install globally (recommended)
npm install -g vibe-coder-mcp@latest

# Run setup wizard on first use
vibe --setup

# Or use instantly with npx (no installation)
npx vibe-coder-mcp@latest --setup

The setup wizard will:

  1. ✅ Configure your OpenRouter API key

  2. ✅ Set up project directories

  3. ✅ Create configuration files from templates

  4. ✅ Validate your environment

  5. ✅ Get you ready to use all features!

📦 Installation

npm version npm downloads

# Recommended: Install globally for the 'vibe' command
npm install -g vibe-coder-mcp@latest

# Or run instantly without installation
npx vibe-coder-mcp@latest

Installation Methods

Global Installation (Recommended)

npm install -g vibe-coder-mcp@latest

# Use the 'vibe' command anywhere
vibe                                    # Start MCP server
vibe "create a PRD for a todo app"     # CLI mode
vibe --interactive                     # Interactive REPL mode
vibe --setup                           # Setup wizard

Quick Run with npx

# No installation needed
npx vibe-coder-mcp@latest
npx vibe-coder-mcp@latest "research React best practices"

Local Project Installation

npm install vibe-coder-mcp
npx vibe-coder-mcp "map the codebase structure"

Command Line Usage

# MCP Server Mode (for Claude Desktop, Cursor, etc.)
vibe                                    # Start with stdio transport
vibe --sse                             # Start with Server-Sent Events

# CLI Mode - Natural Language Commands
vibe "research modern JavaScript frameworks"
vibe "create a PRD for an e-commerce platform"
vibe "map the codebase structure" --json
vibe "generate user stories for auth system"

# Interactive REPL Mode
vibe --interactive                     # Chat interface with context retention

# Configuration
vibe --setup                           # Run setup wizard
vibe --help                            # Show all options
vibe --version                         # Show version

Interactive Mode Features:

  • Chat-style conversation with context retention

  • Live tool execution with progress indicators

  • Session persistence and history

  • Markdown rendering support

  • Multiple themes and customization

  • Slash commands for quick actions

🎯 MCP Client Integration (Claude Desktop, Cursor, Cline AI)

Quick Integration Guide

Vibe-Coder MCP integrates seamlessly with any MCP-compatible client. Here's how to configure it:

In your MCP client's server configuration dialog:

  • Server Name: vibe-coder-mcp

  • Command/URL: npx

  • Arguments: vibe-coder-mcp

  • Environment Variables:

    • OPENROUTER_API_KEY: Your OpenRouter API key (required)

    • VIBE_PROJECT_ROOT: /path/to/your/project (required)

    • LOG_LEVEL: info (optional)

    • NODE_ENV: production (optional)

Option 2: Global Installation

# First install globally
npm install -g vibe-coder-mcp

Then configure:

  • Command/URL: vibe

  • Arguments: (leave empty)

  • Environment Variables: Same as Option 1

Option 3: Node with Full Path

  • Command/URL: node

  • Arguments: /path/to/node_modules/vibe-coder-mcp/build/index.js

  • Environment Variables: Same as Option 1

Claude Desktop Specific Configuration

For Claude Desktop users, add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "vibe-coder-mcp": {
      "command": "npx",
      "args": ["vibe-coder-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "your-openrouter-api-key",
        "VIBE_PROJECT_ROOT": "/path/to/your/project",
        "LOG_LEVEL": "info",
        "NODE_ENV": "production"
      }
    }
  }
}

See example_claude_desktop_config.json for a complete example.

Available Tools After Integration

Once configured, your MCP client will have access to:

  • vibe-task-manager: AI-native task management with RDD methodology

  • research-manager: Deep research using Perplexity integration

  • map-codebase: Advanced codebase analysis (35+ languages)

  • curate-context: Intelligent context curation for AI development

  • generate-prd: Product requirements document generator

  • generate-user-stories: User story generator

  • generate-task-list: Task list generator

  • generate-fullstack-starter-kit: Project scaffolding tool

  • run-workflow: Multi-step workflow execution

Testing Your Integration

After configuration, test by asking your AI assistant:

  • "Use vibe to research React best practices"

  • "Map the codebase for this project"

  • "Generate a PRD for a task management app"

🆕 Unified Project Root Configuration

Zero Configuration for CLI Users

# Automatic project detection - just run from your project!
cd /path/to/your/project
vibe "map the codebase structure"

Simple Configuration for MCP Clients

{
  "env": {
    "OPENROUTER_API_KEY": "your_key_here",
    "VIBE_PROJECT_ROOT": "/path/to/your/project"
  }
}
  • One Variable: VIBE_PROJECT_ROOT replaces multiple directory configs

  • Auto-Detection: CLI automatically detects project root

  • Backward Compatible: Legacy variables still supported

🔧 Environment Configuration

Required: You need an OpenRouter API key to use Vibe Coder MCP.

Get Your OpenRouter API Key

  1. Visit openrouter.ai

  2. Create an account if you don't have one

  3. Navigate to API Keys section

  4. Create a new API key and copy it

Set Up Environment Variables

Option 1: Using Setup Wizard (Recommended for v0.2.3+)

# Run the interactive setup wizard
vibe --setup

# The wizard will:
# • Configure your OpenRouter API key
# • Set up project directories
# • Create configuration files
# • Validate your setup

Option 2: Environment Variables

# Set your OpenRouter API key
export OPENROUTER_API_KEY="your_api_key_here"

# Optional: Set custom directories
export VIBE_CODER_OUTPUT_DIR="/path/to/output/directory"
export VIBE_PROJECT_ROOT="/path/to/your/project"

# Legacy variables (still supported for backward compatibility)
export CODE_MAP_ALLOWED_DIR="/path/to/your/source/code"
export VIBE_TASK_MANAGER_READ_DIR="/path/to/your/project"

Option 3: Create .env file (templates provided in v0.2.3+) Create a .env file in your working directory (or copy from src/config-templates/.env.template):

# Required: Your OpenRouter API key
OPENROUTER_API_KEY="your_api_key_here"

# Optional: Unified project root configuration
VIBE_CODER_OUTPUT_DIR="/path/to/output/directory"
VIBE_PROJECT_ROOT="/path/to/your/project"
VIBE_USE_PROJECT_ROOT_AUTO_DETECTION="true"

# Legacy variables (still supported for backward compatibility)
CODE_MAP_ALLOWED_DIR="/path/to/your/source/code"  
VIBE_TASK_MANAGER_READ_DIR="/path/to/your/project"

# Optional: Other settings
OPENROUTER_BASE_URL="https://openrouter.ai/api/v1"
GEMINI_MODEL="google/gemini-2.5-flash-preview-05-20"

Directory Configuration (Unified & Simplified)

🆕 Unified Configuration (Recommended)

  • VIBE_PROJECT_ROOT: Single variable for all project operations (automatic detection enabled by default for CLI)

  • VIBE_USE_PROJECT_ROOT_AUTO_DETECTION: Enable automatic project root detection for CLI users (default: "true")

  • VIBE_CODER_OUTPUT_DIR: Where generated files are saved (default: ./VibeCoderOutput/)

Legacy Configuration (Still Supported)

  • CODE_MAP_ALLOWED_DIR: Security boundary for code analysis (fallback if VIBE_PROJECT_ROOT not set)

  • VIBE_TASK_MANAGER_READ_DIR: Security boundary for task manager operations (fallback if VIBE_PROJECT_ROOT not set)

Auto-Detection Benefits:

  • Zero Configuration: CLI users get automatic project root detection

  • Context Aware: Different behavior for CLI vs MCP client usage

  • Intelligent Fallbacks: 5-priority resolution chain ensures reliable operation

🔌 MCP Client Setup

Configure your AI assistant to connect to Vibe Coder MCP:

For Cursor AI / Windsurf / VS Code MCP Clients

Add this to your MCP settings (usually in settings.json):

{
  "mcpServers": {
    "vibe-coder-mcp": {
      "command": "npx",
      "args": ["vibe-coder-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "your_api_key_here"
      }
    }
  }
}

For Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "vibe-coder-mcp": {
      "command": "npx",
      "args": ["vibe-coder-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "your_api_key_here",
        "VIBE_PROJECT_ROOT": "/path/to/your/project"
      }
    }
  }
}

💻 CLI Usage Guide

Vibe Coder includes a powerful command-line interface with multiple modes for direct interaction with all tools.

Interactive Setup Wizard (Enhanced in v0.2.3)

# First-time setup (runs automatically on first use)
vibe --setup

# Features:
# • Smart first-run detection
# • OS-specific configuration paths
# • Non-interactive mode for CI/CD
# • Configuration validation
# • Backup system for existing configs

# Reconfigure existing installation
vibe --reconfigure

Interactive REPL Mode (NEW in v0.2.3!)

# Start interactive chat session
vibe --interactive

# Or with alias
vibe -i

# Resume a previous session
vibe --resume <session-id>

REPL Features:

  • 🎯 Chat Interface: Natural conversation flow with context retention

  • 📝 Multi-line Input: Use """ for multi-line messages

  • 🎨 Themes: Multiple color themes with /theme command

  • 💾 Session Management: Auto-save and resume capabilities

  • 📊 Markdown Rendering: Rich text formatting in responses

  • Live Progress: Real-time execution feedback

  • 🔧 Slash Commands: Quick actions like /tools, /history, /save

  • 🎮 Auto-completion: Tab completion for commands and tools

CLI Command Examples

Research & Analysis

vibe "research modern React patterns and best practices"
vibe "analyze current trends in microservices architecture"
vibe "research security best practices for Node.js APIs"

Project Planning

vibe "create a PRD for an e-commerce platform with user authentication"
vibe "generate user stories for authentication system"
vibe "create development tasks from user stories"

Code Analysis & Generation

vibe "map the codebase structure"
vibe "create context for implementing authentication"
vibe "generate a fullstack starter kit for e-commerce"
vibe "create coding standards for TypeScript projects"

Task Management

vibe "create a new project for building a todo app"
vibe "list all my projects"
vibe "show project status for MyApp"
vibe "create high priority task for implementing OAuth"

CLI Options

# Output formats
vibe "research React hooks" --json
vibe "create PRD for todo app" --yaml

# Verbosity control
vibe "create project MyApp" --verbose
vibe "research Node.js patterns" --quiet

# Interactive REPL mode (NEW!)
vibe --interactive
vibe -i

# Session management (NEW!)
vibe --resume <session-id>
vibe --list-sessions

Interactive REPL Commands (v0.2.3+)

Once in interactive mode (vibe --interactive), use these commands:

# Help and navigation
/help              # Show available commands
/tools             # List all MCP tools
/status            # Show session status

# Session management
/save              # Save current session
/sessions          # List saved sessions
/export [file]     # Export session to markdown

# Conversation control
/clear             # Clear conversation history
/history           # Show conversation history

# Customization
/theme             # Change color theme
/markdown          # Toggle markdown rendering
/config            # Manage configuration

# Exit
/quit or /exit     # Exit interactive mode

File Organization

Generated files are automatically organized in VibeCoderOutput/:

VibeCoderOutput/
├── research/                    # Research reports
├── prd-generator/              # Product requirements
├── user-stories-generator/     # User stories
├── task-list-generator/        # Development tasks
├── fullstack-starter-kit-generator/  # Project templates
├── map-codebase/              # Code analysis
├── vibe-task-manager/         # Task management data
└── workflow-runner/           # Workflow outputs

🔄 Migration Guide (v0.2.3)

Breaking Changes

None! Version 0.2.3 is fully backward compatible. All existing configurations and workflows continue to work.

Technical Improvements

  • Unified CLI architecture with single entry point

  • Better error handling and recovery

  • Improved resource cleanup

  • Enhanced type safety throughout codebase

  • Memory leak prevention in long-running sessions

  • CI/CD Pipeline Optimization:

    • 70% faster execution (~3 minutes vs ~10 minutes)

    • Focused on essential checks: type-check, lint, build

    • Unit tests moved to local development workflow

    • See CI/CD Guide for details

  • Memory usage optimized for large codebases

  • Faster first-run experience with smart detection


📚 Development Setup (Advanced)

If you want to contribute to development or run from source, follow the detailed setup guide below.

Overview & Features

Vibe Coder MCP integrates with MCP-compatible clients to provide the following capabilities:

🚀 Core Architecture

  • Quad Transport Support: stdio, SSE, WebSocket, and HTTP transport protocols for maximum client compatibility

  • Dynamic Port Allocation: Intelligent port management with conflict resolution and graceful degradation

  • Semantic Request Routing: Intelligently routes requests using embedding-based semantic matching with sequential thinking fallbacks

  • Tool Registry Architecture: Centralized tool management with self-registering tools

  • Unified Communication Protocol: Agent coordination across all transport mechanisms with real-time notifications

  • Session State Management: Maintains context across requests within sessions

🧠 AI-Native Task Management

  • Vibe Task Manager: Production-ready task management with 99.9% test success rate and comprehensive integration (Functional but actively being enhanced)

  • Natural Language Processing: 21 supported intents with multi-strategy recognition (pattern matching + LLM fallback)

  • Recursive Decomposition Design (RDD): Intelligent project breakdown into atomic tasks

  • Agent Orchestration: Multi-agent coordination with capability mapping, load balancing, and real-time status synchronization

  • Multi-Transport Agent Support: Full integration across stdio, SSE, WebSocket, and HTTP transports

  • Real Storage Integration: Zero mock code policy - all production integrations

  • Artifact Parsing Integration: Seamless integration with PRD Generator and Task List Generator outputs

  • Session Persistence: Enhanced session tracking with orchestration workflow triggers

  • Comprehensive CLI: Natural language command-line interface with extensive functionality

🔍 Advanced Code Analysis & Context Curation

  • Code Map Tool: 35+ programming language support with 95-97% token reduction optimization

  • Context Curation Tool: Language-agnostic project detection with 95%+ accuracy across 35+ languages

  • Intelligent Codemap Caching: Configurable caching system that reuses recent codemaps to optimize workflow performance

  • Enhanced Import Resolution: Third-party integration for accurate dependency mapping

  • Multi-Strategy File Discovery: 4 parallel strategies for comprehensive analysis

  • Memory Optimization: Sophisticated caching and resource management

  • Security Boundaries: Separate read/write path validation for secure operations

📋 Research & Planning Suite

  • Research Tool: Deep research using Perplexity Sonar via OpenRouter

  • Context Curation: Intelligent codebase analysis with 8-phase workflow pipeline and intelligent codemap caching for AI-driven development

  • Document Generators: PRDs (prd-generator), user stories (user-stories-generator), task lists (task-list-generator), development rules (rules-generator)

  • Project Scaffolding: Full-stack starter kits (fullstack-starter-kit-generator) with dynamic template generation

  • Workflow Execution: Predefined sequences of tool calls defined in workflows.json

Performance & Reliability

  • Asynchronous Execution: Job-based processing with real-time status tracking

  • Performance Optimized: <200ms response times, <400MB memory usage

  • Comprehensive Testing: 99.9% test success rate across 2,100+ tests with full integration validation

  • Production Ready: Zero mock implementations, real service integrations

  • Enhanced Error Handling: Advanced error recovery with automatic retry, escalation, and pattern analysis

  • Dynamic Port Management: Intelligent port allocation with conflict resolution and graceful degradation

  • Real-Time Monitoring: Agent health monitoring, task execution tracking, and performance analytics

(See "Detailed Tool Documentation" and "Feature Details" sections below for more)

Development Setup Guide

For developers who want to run from source or contribute to the project.

Step 1: Prerequisites

  1. Check Node.js Version:

    • Open a terminal or command prompt.

    • Run node -v

    • Ensure the output shows v20.0.0 or higher (required).

    • If not installed or outdated: Download from nodejs.org.

  2. Check Git Installation:

    • Open a terminal or command prompt.

    • Run git --version

    • If not installed: Download from git-scm.com.

  3. Get OpenRouter API Key:

    • Visit openrouter.ai

    • Create an account if you don't have one.

    • Navigate to API Keys section.

    • Create a new API key and copy it.

    • Keep this key handy for Step 4.

Step 2: Get the Code

  1. Create a Project Directory (optional):

    • Open a terminal or command prompt.

    • Navigate to where you want to store the project:

      cd ~/Documents     # Example: Change to your preferred location
  2. Clone the Repository:

    • Run:

      git clone https://github.com/freshtechbro/vibe-coder-mcp.git

      (Or use your fork's URL if applicable)

  3. Navigate to Project Directory:

    • Run:

      cd vibe-coder-mcp

Step 3: Run the Setup Script

Choose the appropriate script for your operating system:

For Windows:

  1. In your terminal (still in the vibe-coder-mcp directory), run:

    setup.bat
  2. Wait for the script to complete (it will install dependencies, build the project, and create necessary directories).

  3. If you see any error messages, refer to the Troubleshooting section below.

For macOS or Linux:

  1. Make the script executable:

    chmod +x setup.sh
  2. Run the script:

    ./setup.sh
  3. Wait for the script to complete.

  4. If you see any error messages, refer to the Troubleshooting section below.

The script performs these actions:

  • Checks Node.js version (v20+ required)

  • Installs all dependencies via npm

  • Creates necessary VibeCoderOutput/ subdirectories

  • Builds the TypeScript project

  • Creates configuration from templates if not present (v0.2.3+)

  • Sets executable permissions (on Unix systems)

Note: The setup process is now faster (v0.2.3+) with optimized dependency installation and simplified build process.

Step 4: Configure Environment Variables

New in v0.2.3: Configuration templates are provided in src/config-templates/ for easy setup.

vibe --setup

The wizard will guide you through configuration and create all necessary files.

Option B: Manual Configuration

  1. Copy templates (if not already done by setup script):

    cp src/config-templates/.env.template .env
    cp src/config-templates/llm_config.template.json llm_config.json
    cp src/config-templates/mcp-config.template.json mcp-config.json
  2. Edit .env file with your configuration:

    # OpenRouter Configuration (REQUIRED)
    OPENROUTER_API_KEY="your_actual_api_key_here"
    
    # Optional configurations
    OPENROUTER_BASE_URL=https://openrouter.ai/api/v1
    GEMINI_MODEL=google/gemini-2.5-flash-preview-05-20
    
    # Project directories (optional - auto-detected for CLI users)
    VIBE_PROJECT_ROOT=/path/to/your/project
    VIBE_CODER_OUTPUT_DIR=/path/to/output
  3. Configure Output Directory (Optional):

    • To change where generated files are saved (default is VibeCoderOutput/ inside the project), add this line to your .env file:

      VIBE_CODER_OUTPUT_DIR=/path/to/your/desired/output/directory
    • Replace the path with your preferred absolute path. Use forward slashes (/) for paths. If this variable is not set, the default directory (VibeCoderOutput/) will be used.

  4. 🆕 Configure Unified Project Root (Recommended):

    • To set up the new unified project root configuration, add this line to your .env file:

      VIBE_PROJECT_ROOT=/path/to/your/project/root
    • Replace the path with the absolute path to your project's root directory.

    • Benefits: Single configuration variable for all tools (Code Map Generator, Task Manager, Context Curator)

    • Auto-Detection: For CLI users, project root is automatically detected from the current working directory

    • Backward Compatibility: Legacy variables are still supported if you prefer separate configurations

  5. Legacy Directory Configuration (Optional):

    • If you prefer separate directory configurations, you can still use the original variables:

      CODE_MAP_ALLOWED_DIR=/path/to/your/source/code/directory
      VIBE_TASK_MANAGER_READ_DIR=/path/to/your/project/source/directory
    • Note: These variables work as fallbacks if VIBE_PROJECT_ROOT is not set

    • Security: All variables work with the strict filesystem security implementation

  6. Review Other Settings (Optional):

    • You can add other environment variables supported by the server, such as LOG_LEVEL (e.g., LOG_LEVEL=debug) or NODE_ENV (e.g., NODE_ENV=development).

  7. Save the .env File.

Step 5: Integrate with Your AI Assistant (MCP Settings)

This crucial step connects Vibe Coder to your AI assistant by adding its configuration to the client's MCP settings file.

5.1: Locate Your Client's MCP Settings File

The location varies depending on your AI assistant:

  • Cursor AI / Windsurf / RooCode (VS Code based):

    1. Open the application.

    2. Open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P).

    3. Type and select Preferences: Open User Settings (JSON).

    4. This opens your settings.json file where the mcpServers object should reside.

  • Cline AI (VS Code Extension):

    • Windows: %APPDATA%\Cursor\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json

    • macOS: ~/Library/Application Support/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

    • Linux: ~/.config/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

    • (Note: If using standard VS Code instead of Cursor, replace Cursor with Code in the path)

  • Claude Desktop:

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Linux: ~/.config/Claude/claude_desktop_config.json

5.2: Add the Vibe Coder Configuration

  1. Open the settings file identified above in a text editor.

  2. Find the "mcpServers": { ... } JSON object. If it doesn't exist, you may need to create it (ensure the overall file remains valid JSON). For example, an empty file might become {"mcpServers": {}}.

  3. Add the following configuration block inside the curly braces {} of the mcpServers object. If other servers are already listed, add a comma , after the previous server's closing brace } before pasting this block.

    // 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",
        // 🆕 Unified project root for all tools (recommended)
        // This single variable configures all tools with the same project boundary
        "VIBE_PROJECT_ROOT": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP",
        // Legacy variables (optional - used as fallbacks if VIBE_PROJECT_ROOT not set)
        "CODE_MAP_ALLOWED_DIR": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP/src",
        "VIBE_TASK_MANAGER_READ_DIR": "/Users/username/Documents/Dev Projects/Vibe-Coder-MCP"
      },
      // 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",
        "rules-generator",
        "user-stories-generator",
        "task-list-generator",
        "prd-generator",
        "fullstack-starter-kit-generator",
        "refactor-code",
        "git-summary",
        "run-workflow",
        "map-codebase"
      ]
    }
  4. CRUCIAL: Replace all placeholder paths (like /path/to/your/vibe-coder-mcp/...) with the correct absolute paths on your system where you cloned the repository. Use forward slashes / for paths, even on Windows (e.g., C:/Users/YourName/Projects/vibe-coder-mcp/build/index.js). Incorrect paths are the most common reason the server fails to connect.

  5. Save the settings file.

  6. Completely close and restart your AI assistant application (Cursor, VS Code, Claude Desktop, etc.) for the changes to take effect.

Step 6: Test Your Configuration

  1. Start Your AI Assistant:

    • Completely restart your AI assistant application.

  2. Test a Simple Command:

    • Type a test command like: Research modern JavaScript frameworks

  3. Check for Proper Response:

    • If working correctly, you should receive a research response.

    • If not, check the Troubleshooting section below.

AI Agent Integration

The Vibe Coder MCP system includes comprehensive system instructions designed to help AI agents and MCP clients effectively leverage the full ecosystem. These instructions provide detailed guidance on tool usage, integration patterns, and best practices.

System Instructions File

The VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md file contains comprehensive guidance for AI agents on how to use the Vibe Coder MCP ecosystem effectively. This file should be integrated into your AI development environment to train your agents on optimal tool usage.

Platform-Specific Integration

Claude Desktop

Place the system instructions in your project's system instructions or custom instructions:

  1. Open Claude Desktop

  2. Navigate to project settings

  3. Add the contents of VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md to the system instructions field

  4. Save and restart Claude Desktop

ChatGPT

Add the system instructions to your custom instructions or project settings:

  1. Open ChatGPT settings

  2. Navigate to custom instructions or project configuration

  3. Paste the contents of VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md

  4. Save the configuration

VS Code Extensions (Cline, Roo Coder, Augment)

Integrate the system instructions into your extension's configuration:

  1. Cline: Place in system instructions or memories section

  2. Roo Coder: Add to system instructions or rules folder

  3. Augment: Place in system instructions or memories

  4. Other VS Code forks: Place in system instructions or rules folder with "always active" setting

General MCP Clients

For other MCP-compatible clients:

  1. Locate the system instructions or rules configuration

  2. Add the contents of VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md

  3. Set as "always active" or "persistent" if the option is available

  4. Restart the client to apply changes

Key Integration Benefits

  • Comprehensive Tool Knowledge: Agents learn about all 15+ available tools and their capabilities

  • Workflow Orchestration: Guidance on chaining tools together for complex development workflows

  • Job Polling Protocol: Critical instructions for handling asynchronous operations correctly

  • Best Practices: Performance optimization and error handling strategies

  • Integration Patterns: Common workflows for research, planning, and implementation

Usage Examples

Once integrated, your AI agents will be able to:

# Research-driven development
"Research modern React patterns, then create a PRD and generate user stories"

# Complete project setup
"Set up a new e-commerce project with React frontend and Node.js backend"

# Context-aware development
"Analyze this codebase and suggest improvements with implementation tasks"

# Multi-agent coordination
"Register frontend and backend agents, then distribute authentication tasks"

Verification

To verify successful integration:

  1. Ask your AI agent about available Vibe Coder tools

  2. Request a workflow that uses multiple tools in sequence

  3. Check that the agent follows proper job polling protocols

  4. Confirm that outputs are saved to the correct directories

🎯 Unified CLI Architecture (v0.2.3+)

The new unified CLI (unified-cli.ts) provides a single entry point for all Vibe Coder operations:

flowchart TD
    Start[vibe command] --> Detect{First Run?}
    Detect -->|Yes| Setup[Setup Wizard]
    Detect -->|No| Parse[Parse Arguments]
    
    Setup --> Config[Save Configuration]
    Config --> Parse
    
    Parse --> Mode{Mode?}
    Mode -->|--interactive| REPL[Interactive REPL]
    Mode -->|"message"| CLI[CLI Execution]
    Mode -->|none| MCP[MCP Server]
    Mode -->|--setup| Setup
    
    REPL --> Session[Session Management]
    Session --> Chat[Chat Interface]
    Chat --> Tools[Tool Execution]
    
    CLI --> Router[Hybrid Router]
    Router --> Tools
    
    MCP --> Transport{Transport?}
    Transport -->|stdio| Stdio[Stdio Server]
    Transport -->|sse| SSE[SSE Server]

Benefits of Unified CLI:

  • Single binary for all operations (vibe)

  • Consistent command interface

  • Shared configuration management

  • Seamless mode switching

  • Better resource utilization

Project Architecture

The Vibe Coder MCP server follows a modular, TypeScript ESM architecture with dual transport support and comprehensive tool ecosystem:

flowchart TD
    subgraph "Core Architecture"
        Init[index.ts] --> Config[Configuration Loader]
        Config --> Transport{Transport Type}
        Transport --> |stdio| StdioTransport[Stdio Transport]
        Transport --> |sse| SSETransport[SSE Transport]
        StdioTransport --> Server[MCP Server]
        SSETransport --> Server
        Server --> ToolReg[Tool Registry]
        ToolReg --> InitEmbed[Initialize Embeddings]
        InitEmbed --> Ready[Server Ready]
    end

    subgraph "Request Processing"
        Req[Client Request] --> SessionMgr[Session Manager]
        SessionMgr --> Router[Hybrid Router]
        Router --> Semantic[Semantic Matcher]
        Router --> Sequential[Sequential Thinking]
        Semantic --> |High Confidence| Execute[Tool Execution]
        Sequential --> |Fallback| Execute
        Execute --> JobMgr[Job Manager]
        JobMgr --> Response[Response to Client]
    end

    subgraph "Tool Ecosystem"
        Execute --> Research[Research Tool]
        Execute --> TaskMgr[Vibe Task Manager]
        Execute --> CodeMap[Code Map Tool]
        Execute --> FullStack[Fullstack Generator]
        Execute --> PRDGen[PRD Generator]
        Execute --> UserStories[User Stories Generator]
        Execute --> TaskList[Task List Generator]
        Execute --> Rules[Rules Generator]
        Execute --> Workflow[Workflow Runner]
    end

    subgraph "Support Services"
        JobMgr --> AsyncJobs[Async Job Processing]
        Execute --> FileOps[File Operations]
        Execute --> LLMHelper[LLM Integration]
        Execute --> ErrorHandler[Error Handling]
        Execute --> StateManager[Session State]
    end

    subgraph "Configuration & Security"
        Config --> LLMConfig[LLM Config Mapping]
        Config --> MCPConfig[MCP Tool Config]
        Config --> EnvVars[Environment Variables]
        FileOps --> SecurityBoundary[Security Boundaries]
        SecurityBoundary --> ReadOps[Read Operations]
        SecurityBoundary --> WriteOps[Write Operations]
    end

Directory Structure

vibe-coder-mcp/
├── .env                              # Environment configuration
├── .env.example                      # Environment template
├── llm_config.json                   # LLM model mappings
├── mcp-config.json                   # MCP tool configurations
├── package.json                      # Project dependencies
├── README.md                         # This documentation
├── VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md  # System prompt 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
│   ├── map-codebase/                # Code Map Tool docs
│   ├── handover/                     # Development handover docs
│   └── *.md                          # Various documentation files
├── VibeCoderOutput/                  # Tool output directory
│   ├── research/                    # Research reports
│   ├── rules-generator/              # Development rules
│   ├── prd-generator/                # Product requirements
│   ├── user-stories-generator/       # User stories
│   ├── task-list-generator/          # Task lists
│   ├── fullstack-starter-kit-generator/  # Project templates
│   ├── map-codebase/                # Code maps and diagrams
│   ├── vibe-task-manager/            # Task management data
│   └── workflow-runner/              # Workflow outputs
└── src/                              # Source code
    ├── index.ts                      # Entry point
    ├── logger.ts                     # Logging configuration (Pino)
    ├── server.ts                     # MCP server setup
    ├── services/                     # Core services
    │   ├── routing/                  # Semantic routing system
    │   │   ├── embeddingStore.ts     # Embedding management
    │   │   ├── hybridMatcher.ts      # Hybrid routing logic
    │   │   └── toolRegistry.ts       # Tool registry
    │   ├── sse-notifier/             # SSE notification system
    │   ├── JobManager.ts             # Async job management
    │   └── ToolService.ts            # Tool execution service
    ├── tools/                        # MCP Tools
    │   ├── index.ts                  # Tool registration
    │   ├── sequential-thinking.ts    # Fallback routing
    │   ├── map-codebase/            # Code analysis tool
    │   │   ├── cache/                # Memory management
    │   │   ├── grammars/             # Tree-sitter grammars
    │   │   ├── importResolvers/      # Import resolution adapters
    │   │   └── *.ts                  # Core implementation
    │   ├── fullstack-starter-kit-generator/  # Project scaffolding
    │   ├── prd-generator/            # PRD creation
    │   ├── research/                # Research tool
    │   ├── rules-generator/          # Rule generation
    │   ├── task-list-generator/      # Task list generation
    │   ├── user-stories-generator/   # User story generation
    │   ├── vibe-task-manager/        # AI-native task management
    │   │   ├── __tests__/            # Comprehensive test suite
    │   │   ├── cli/                  # Command-line interface
    │   │   ├── core/                 # Core algorithms
    │   │   ├── integrations/         # Tool integrations
    │   │   ├── prompts/              # LLM prompts (YAML)
    │   │   ├── services/             # Business logic services
    │   │   ├── types/                # TypeScript definitions
    │   │   └── utils/                # Utility functions
    │   └── workflow-runner/          # Workflow execution engine
    ├── types/                        # TypeScript type definitions
    └── utils/                        # Shared utilities
        ├── configLoader.ts           # Configuration management
        ├── errors.ts                 # Error handling
        └── llmHelper.ts              # LLM integration helpers

Semantic Routing System

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

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]

Tool Registry Pattern

The Tool Registry is a central component for managing tool definitions and execution:

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

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

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

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

Sequential Thinking Process

The Sequential Thinking mechanism provides LLM-based fallback routing:

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

Session State Management

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 Execution Engine

The Workflow system enables multi-step sequences:

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

Workflow Configuration

Workflows are defined in the workflows.json file located in the root directory of the project. This file contains predefined sequences of tool calls that can be executed with a single command.

File Location and Structure

  • The workflows.json file must be placed in the project root directory (same level as package.json)

  • The file follows this structure:

    {
      "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"]
          }
        }
      }
    }

Parameter Templates

Workflow step parameters support template strings that can reference:

  • Workflow inputs: {workflow.input.paramName}

  • Previous step outputs: {steps.stepId.output.content[0].text}

Triggering Workflows

Use the run-workflow tool with:

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

Detailed Tool Documentation

Each tool in the src/tools/ directory includes comprehensive documentation in its own README.md file. These files cover:

  • Tool overview and purpose

  • Input/output specifications

  • Workflow diagrams (Mermaid)

  • Usage examples

  • System prompts used

  • Error handling details

Refer to these individual READMEs for in-depth information:

  • src/tools/fullstack-starter-kit-generator/README.md

  • src/tools/prd-generator/README.md

  • src/tools/research/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/map-codebase/README.md

Tool Categories

Analysis & Information Tools

  • Code Map Tool (map-codebase): Scans a codebase to extract semantic information (classes, functions, comments) and generates either a human-readable Markdown map with Mermaid diagrams or a structured JSON representation with absolute file paths for imports and enhanced class property information.

  • Context Curation Tool (curate-context): Intelligent codebase analysis and context package curation with 8-phase workflow pipeline, intelligent codemap caching, language-agnostic project detection supporting 35+ programming languages, and multi-strategy file discovery for AI-driven development tasks.

  • Research Tool (research): Performs deep research on technical topics using Perplexity Sonar, providing summaries and sources.

Planning & Documentation Tools

  • Rules Generator (rules-generator): Creates project-specific development rules and guidelines.

  • PRD Generator (prd-generator): Generates comprehensive product requirements documents.

  • User Stories Generator (user-stories-generator): Creates detailed user stories with acceptance criteria.

  • Task List Generator (task-list-generator): Builds structured development task lists with dependencies.

Project Scaffolding Tool

  • Fullstack Starter Kit Generator (fullstack-starter-kit-generator): Creates customized project starter kits with specified frontend/backend technologies, including basic setup scripts and configuration.

Workflow & Orchestration

  • Workflow Runner (run-workflow): Executes predefined sequences of tool calls for common development tasks.

Generated File Storage

By default, outputs from the generator tools are stored for historical reference in the VibeCoderOutput/ directory within the project. This location can be overridden by setting the VIBE_CODER_OUTPUT_DIR environment variable in your .env file or AI assistant configuration.

Security Boundaries for Read and Write Operations

For security reasons, the Vibe Coder MCP tools maintain separate security boundaries for read and write operations with a security-by-default approach:

  • Read Operations:

    • Code Map Tool: Only reads from directories explicitly authorized through the CODE_MAP_ALLOWED_DIR environment variable

    • Vibe Task Manager: Only reads from directories authorized through the VIBE_TASK_MANAGER_READ_DIR environment variable (defaults to process.cwd())

    • Security Mode: The Vibe Task Manager defaults to 'strict' security mode, which prevents access to system directories like /private/var/spool/postfix/, /System/, and other unauthorized paths

    • Filesystem Security: Comprehensive blacklist enforcement and permission checking prevent EACCES errors and unauthorized file access

  • Write Operations: All output files are written to the VIBE_CODER_OUTPUT_DIR directory (or its subdirectories). This separation ensures that tools can only write to designated output locations, protecting your source code from accidental modifications.

  • Security Implementation: The filesystem security system includes:

    • Adaptive Timeout Management: Prevents operations from hanging indefinitely with intelligent retry and cancellation

    • Path Validation: Comprehensive validation of all file paths before access

    • Permission Checking: Proactive permission verification to prevent access errors

    • System Directory Protection: Built-in blacklist of system directories that should never be accessed

Example structure (default location):

VibeCoderOutput/
  ├── research/                # 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/
  ├── map-codebase/            # Code maps and diagrams
  │   └── TIMESTAMP-code-map/
  └── workflow-runner/          # Workflow outputs
      └── TIMESTAMP-WORKFLOW/

System Instructions for MCP Clients

For optimal performance with AI assistants and MCP clients, use the comprehensive system instructions provided in VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md. This document contains detailed guidance for:

  • Tool-specific usage patterns and best practices

  • Natural language command structures

  • Asynchronous job polling guidelines

  • Integration workflows and examples

  • Error handling and troubleshooting

How to Use System Instructions

For Claude Desktop:

  1. Open Claude Desktop settings

  2. Navigate to "Custom Instructions" or "System Prompt"

  3. Copy the entire content from VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md

  4. Paste into the custom instructions field

  5. Save settings

For Augment:

  1. Access Augment settings/preferences

  2. Find "Custom Instructions" or "System Configuration"

  3. Copy and paste the system instructions

  4. Apply changes

For Claude Code/Windsurf/Other MCP Clients:

  1. Locate the custom instructions or system prompt configuration

  2. Copy the content from VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md

  3. Paste into the appropriate field

  4. Save/apply the configuration

Benefits of Using System Instructions:

  • 98%+ tool operation success rate

  • Optimal natural language command recognition

  • Proper asynchronous job handling

  • Efficient workflow orchestration

  • Reduced errors and improved troubleshooting

Usage Examples

Via CLI (Direct Command Line)

# Research and analysis
vibe "research modern JavaScript frameworks"
vibe "create development rules for a mobile banking application"

# Project planning
vibe "generate a PRD for a task management application"
vibe "generate user stories for an e-commerce website"
vibe "create a task list for a weather app based on user stories"

# Code generation and analysis
vibe "create a starter kit for a React/Node.js blog application with user authentication"
vibe "map the codebase structure" --json
vibe "curate context for adding authentication to my React app"

# Task management
vibe "create a new project for building a todo app"
vibe "list all my projects"
vibe "show status of my React project"

# Workflow automation
vibe "run workflow newProjectSetup with input {\"projectName\": \"my-new-app\"}"

Via MCP Client (AI Assistant Integration)

Interact with the tools via your connected AI assistant:

  • Research: Research modern JavaScript frameworks

  • Generate Rules: Create development rules for a mobile banking application

  • Generate PRD: Generate a PRD for a task management application

  • Generate User Stories: Generate user stories for an e-commerce website

  • Generate Task List: Create a task list for a weather app based on [user stories]

  • Sequential Thinking: 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: Run workflow newProjectSetup with input { "projectName": "my-new-app", "description": "A simple task manager" }

  • Map Codebase: Generate a code map for the current project, map-codebase path="./src", or Generate a JSON representation of the codebase structure with output_format="json"

  • Context Curation: Curate context for adding authentication to my React app, Generate context package for refactoring the user service, or Analyze this codebase for performance optimization opportunities

  • Vibe Task Manager: Create a new project for building a todo app, List all my projects, Run task authentication-setup, What's the status of my React project?

Vibe Task Manager - AI-Native Task Management

The Vibe Task Manager is a comprehensive task management system designed specifically for AI agents and development workflows. It provides intelligent project decomposition, natural language command processing, and seamless integration with other Vibe Coder tools.

Status: Functional and production-ready with 99.9% test success rate, but actively being enhanced with new features and improvements.

Key Features

  • Natural Language Processing: Understands commands like "Create a project for building a React app" or "Show me all pending tasks"

  • Recursive Decomposition Design (RDD): Automatically breaks down complex projects into atomic, executable tasks

  • Artifact Parsing Integration: Seamlessly imports PRD files from VibeCoderOutput/prd-generator/ and task lists from VibeCoderOutput/generated_task_lists/

  • Session Persistence: Enhanced session tracking with orchestration workflow triggers for reliable multi-step operations

  • Comprehensive CLI: Full command-line interface with natural language processing and structured commands

  • Agent Orchestration: Coordinates multiple AI agents for parallel task execution

  • Integration Ready: Works seamlessly with Code Map Tool, Research Tool, and other tools

  • File Storage: All project data stored in VibeCoderOutput/vibe-task-manager/ following established conventions

Quick Start Examples

# Project Management
"Create a new project for building a todo app with React and Node.js"
"List all my projects"
"Show me the status of my web app project"

# Task Management
"Create a high priority task for implementing user authentication"
"List all pending tasks for the todo-app project"
"Run the database setup task"

# Project Analysis (Enhanced with Intelligent Lookup)
"Decompose my React project into development tasks"
"Decompose PID-TODO-APP-REACT-001 into tasks"  # Using project ID
"Decompose \"Todo App with React\" into tasks"  # Using exact name
"Decompose todo into tasks"  # Using partial name (fuzzy matching)
"Refine the authentication task to include OAuth support"
"What's the current progress on my mobile app?"

🎯 Enhanced Project Lookup Features

  • Intelligent Parsing: Automatically detects project IDs, names, or partial matches

  • Comprehensive Validation: Validates project readiness before decomposition

  • Enhanced Error Messages: Provides actionable guidance with available projects and usage examples

  • Multiple Input Formats: Supports project IDs, quoted names, partial names, and fuzzy matching

  • Confidence Scoring: Shows parsing confidence levels for better user feedback

Command Structure

The Vibe Task Manager supports both structured commands and natural language:

Structured Commands:

  • vibe-task-manager create project "Name" "Description" --options

  • vibe-task-manager list projects --status pending

  • vibe-task-manager run task task-id --force

  • vibe-task-manager status project-id --detailed

Natural Language (Recommended):

  • "Create a project for [description]"

  • "Show me all [status] projects"

  • "Run the [task name] task"

  • "What's the status of [project]?"

  • "Parse PRD files for [project name]" (NEW)

  • "Import task list from [file path]" (NEW)

  • "Parse all PRDs and create projects automatically" (NEW)

For complete documentation, see src/tools/vibe-task-manager/README.md and the system instructions in VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md.

Implementation Status & Performance Metrics

Current Epic Status

The Vibe Coder MCP project follows an epic-based development approach with comprehensive tracking:

gantt
    title Vibe Coder MCP Development Progress
    dateFormat  YYYY-MM-DD
    section Core Infrastructure
    Tool Registry & Routing    :done, epic1, 2024-01-01, 2024-02-15
    MCP Server Implementation  :done, epic2, 2024-01-15, 2024-03-01
    Async Job Management       :done, epic3, 2024-02-15, 2024-03-15

    section Tool Development
    Research & Planning Tools  :done, epic4, 2024-02-01, 2024-04-01
    Code Map Tool              :done, epic5, 2024-03-01, 2024-05-15
    Vibe Task Manager Core     :done, epic6, 2024-04-01, 2024-06-15

    section Advanced Features
    Performance Optimization   :active, epic7, 2024-06-01, 2024-07-15
    Security Implementation    :epic8, 2024-07-01, 2024-08-15
    Analytics & Monitoring     :epic9, 2024-07-15, 2024-09-01

Epic Completion Summary

  • Epic 1-5: ✅ Complete (100% - Core infrastructure and basic tools)

  • Epic 6.1: ✅ Complete (98.3% test success rate - Deep MCP Tool Integration)

  • Epic 6.2: 🔄 In Progress (Performance Optimization - 75% complete)

  • Epic 7.1: 📋 Planned (Security Implementation - Ready for implementation)

  • Epic 8: 📋 Planned (Advanced Analytics & Monitoring - Designed)

Performance Targets & Current Metrics (v0.2.3)

Metric

Target

Current

Status

Test Success Rate

98%+

99.9%

Exceeded

Response Time (Task Operations)

<200ms

<150ms

Exceeded

Response Time (Sync Operations)

<500ms

<350ms

Exceeded

Job Completion Rate

95%+

96.7%

Met

Memory Usage (Code Map Tool)

<512MB

<400MB

Optimized

Unit Test Coverage

>70%

73%

Met

CI/CD Pipeline Speed

<5min

~3min

Optimized

Security Overhead

<50ms

<35ms

Optimized

Zero Mock Code Policy

100%

100%

Achieved

Tool-Specific Status

Vibe Task Manager

  • Status: Production Ready (Functional but actively being enhanced)

  • Test Coverage: 99.9%

  • Features: RDD methodology, agent orchestration, natural language processing, artifact parsing, session persistence, comprehensive CLI

  • Performance: <50ms response time for task operations

  • Recent Additions: PRD/task list integration, enhanced session tracking, orchestration workflows

Code Map Tool

  • Status: Production Ready with Advanced Features

  • Memory Optimization: 95-97% token reduction achieved

  • Language Support: 35+ programming languages

  • Import Resolution: Enhanced with adapter-based architecture

Context Curation Tool

  • Status: Production Ready with Intelligent Codemap Caching

  • Language Support: 35+ programming languages with 95%+ accuracy

  • Workflow Pipeline: 8-phase intelligent analysis and curation

  • Project Detection: Language-agnostic with multi-strategy file discovery

  • Performance Optimization: Intelligent caching system that reuses recent codemaps (configurable 1-1440 minutes)

Research Tool

  • Status: Production Ready

  • Integration: Perplexity Sonar API

  • Performance: <2s average research query response

Other Tools

  • Fullstack Generator: Production Ready

  • PRD/User Stories/Task List Generators: Production Ready

  • Workflow Runner: Production Ready

Running Locally (Optional)

While the primary use is integration with an AI assistant (using stdio), you can run the server directly for testing:

Running Modes

  • Production Mode (Stdio):

    npm start
    • Logs go to stderr (mimics AI assistant launch)

    • Use NODE_ENV=production

  • Development Mode (Stdio, Pretty Logs):

    npm run dev
    • Logs go to stdout with pretty formatting

    • Requires nodemon and pino-pretty

    • Use NODE_ENV=development

  • SSE Mode (HTTP Interface):

    # Production mode over HTTP
    npm run start:sse
    
    # Development mode over HTTP
    npm run dev:sse

Detailed Troubleshooting

Connection Issues

MCP Server Not Detected in AI Assistant

  1. Check Configuration Path:

    • Verify the absolute path in the args array is correct

    • Ensure all slashes are forward slashes / even on Windows

    • Run node <path-to-build/index.js> directly to test if Node can find it

  2. Check Configuration Format:

    • Make sure JSON is valid without syntax errors

    • Check that commas between properties are correct

    • Verify that the mcpServers object contains your server

  3. Restart the Assistant:

    • Completely close (not just minimize) the application

    • Reopen and try again

Server Starts But Tools Don't Work

  1. Check Disabled Flag:

    • Ensure "disabled": false is set

    • Remove any // comments as JSON doesn't support them

  2. Verify autoApprove Array:

    • Check that tool names in the autoApprove array match exactly

    • Try adding "process-request" to the array if using hybrid routing

API Key Issues

  1. OpenRouter Key Problems:

    • Double-check that the key is correctly copied

    • Verify the key is active in your OpenRouter dashboard

    • Check if you have sufficient credits

  2. Environment Variable Issues:

    • Verify the key is correct in both:

      • The .env file (for local runs)

      • Your AI assistant's configuration env block

Path & Permission Issues

  1. Build Directory Not Found:

    • Run npm run build to ensure the build directory exists

    • Check if build output is going to a different directory (check tsconfig.json)

  2. File Permission Errors:

    • Ensure your user has write access to the workflow-agent-files directory

    • On Unix systems, check if build/index.js has execute permission

Log Debugging

  1. For Local Runs:

    • Check the console output for error messages

    • Try running with LOG_LEVEL=debug in your .env file

  2. For AI Assistant Runs:

    • Set "NODE_ENV": "production" in the env configuration

    • Check if the assistant has a logging console or output window

Tool-Specific Issues

  1. Semantic Routing Not Working:

    • First run may download embedding model - check for download messages

    • Try a more explicit request that mentions the tool name

Documentation

Core Documentation

  • System Instructions: VIBE_CODER_MCP_SYSTEM_INSTRUCTIONS.md - Complete usage guide for MCP clients

  • CI/CD Guide: CI_CD_GUIDE.md - Streamlined pipeline documentation (70% faster)

  • NPM Publishing Guide: NPM_PUBLISHING_GUIDE.md - Release and deployment process

  • System Architecture: docs/ARCHITECTURE.md - Comprehensive system architecture with Mermaid diagrams

  • Performance & Testing: docs/PERFORMANCE_AND_TESTING.md - Performance metrics, testing strategies, and quality assurance

  • Vibe Task Manager: src/tools/vibe-task-manager/README.md - Comprehensive task management documentation

  • Context Curation Tool: src/tools/curate-context/README.md - Language-agnostic codebase analysis documentation

  • Code Map Tool: src/tools/map-codebase/README.md - Advanced codebase analysis documentation

Tool Documentation

  • Individual Tool READMEs: Each tool directory contains detailed documentation

  • Configuration Guides: Environment setup and configuration management

  • API Reference: Tool schemas and parameters documented in system instructions

  • Integration Examples: Practical workflows and usage patterns

Architecture Documentation

  • System Architecture: Mermaid diagrams in README and system instructions

  • Tool Architecture: Individual tool architecture diagrams

  • Performance Metrics: Current status and optimization strategies

  • Development Guidelines: Contributing and development best practices

Contributing

We welcome contributions! Please see our contributing guidelines and ensure all tests pass before submitting pull requests.

Development Workflow

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes with comprehensive tests

  4. Ensure all checks pass locally:

    # Run CI checks (REQUIRED before PR - matches GitHub Actions)
    npm run type-check    # TypeScript validation (must pass)
    npm run lint          # Code quality checks (must pass)
    npm run build         # Build verification (must pass)
    
    # Run tests locally (RECOMMENDED before PR)
    npm run test:unit     # Fast unit tests (~3 minutes)
    
    # Optional: Thorough testing for major changes
    npm run test:integration
    npm test              # All tests
  5. Submit a pull request with detailed description

Quality Standards

  • Type Safety: NO any types - strict TypeScript required

  • CI Pipeline: Must pass type-check, lint, and build (automated)

  • Testing: Run unit tests locally before PR submission

  • Test Coverage: Maintain >70% coverage for unit tests

  • Documentation: Update relevant docs for changes

  • Performance: Consider impact on CI pipeline speed (<5 min target)

Common Troubleshooting

OpenRouter API Key Issues

Problem: Tools fail with authentication errors

  • Solution: Verify your OpenRouter API key is correctly set in .env

  • Check: Ensure the key has no extra spaces or quotes

  • Verify: Test your key at openrouter.ai

  • Credits: Ensure you have sufficient credits in your OpenRouter account

Path Configuration Problems

Problem: "Path not found" or "Access denied" errors

  • Solution: Use absolute paths with forward slashes (/) in all configurations

  • Windows: Convert paths like C:\Users\name to C:/Users/name

  • Permissions: Ensure the user has read/write access to configured directories

  • Environment Variables: Verify VIBE_CODER_OUTPUT_DIR and VIBE_PROJECT_ROOT are set correctly (or legacy variables CODE_MAP_ALLOWED_DIR and VIBE_TASK_MANAGER_READ_DIR)

Build Failures

Problem: TypeScript compilation errors

  • Solution: Run npm run clean && npm run build

  • Dependencies: Delete node_modules and package-lock.json, then run npm install

  • Node Version: Ensure Node.js v20+ is installed (node -v)

  • TypeScript: Check for syntax errors with npm run lint

Test Failures

Problem: Tests fail locally or type-check errors in CI

  • Type Errors: Run npm run type-check locally to catch issues early

  • Lint Issues: Use npm run lint:fix to auto-fix style problems

  • Environment: Ensure .env file exists with valid OPENROUTER_API_KEY

  • Memory: Tests may fail on systems with <4GB RAM

  • Network: Some tests require internet connectivity

  • Cleanup: Run npm run clean before running tests

  • CI Pipeline: See CI/CD Guide for pipeline details

Memory/Performance Issues

Problem: High memory usage or slow performance

  • Large Codebases: Code Map Tool may consume significant memory for projects with >10,000 files

  • Solution: Increase Node.js memory limit: NODE_OPTIONS='--max-old-space-size=4096' npm start

  • Caching: Clear cache directories in VibeCoderOutput/ if they grow too large

  • Monitoring: Use npm run test:memory to identify memory leaks

MCP Client Connection Issues

Problem: Server not detected by AI assistant

  • Paths: Verify all paths in MCP configuration use forward slashes and are absolute

  • Restart: Completely close and restart your AI assistant application

  • Logs: Check LOG_LEVEL=debug in configuration for detailed error messages

  • Transport: Ensure "transport": "stdio" is set correctly

  • Disabled: Verify "disabled": false in your configuration

Tool-Specific Issues

Vibe Task Manager:

  • If natural language commands fail, try using structured commands

  • Check VibeCoderOutput/vibe-task-manager/ for project files

  • Ensure project names don't contain special characters

Code Map Tool:

  • For permission errors, verify CODE_MAP_ALLOWED_DIR is set

  • Large repositories may timeout - try smaller subdirectories

  • Some languages require additional setup (see tool README)

Context Curator:

  • If codemap generation fails, check recent codemaps in cache

  • Verify sufficient disk space for large context packages

  • Check file permissions in target directories

Network and Proxy Issues

Problem: Cannot reach external services

  • Proxy: Set HTTP_PROXY and HTTPS_PROXY environment variables if behind a proxy

  • SSL: For SSL issues, try NODE_TLS_REJECT_UNAUTHORIZED=0 (development only)

  • Firewall: Ensure firewall allows outbound HTTPS connections

  • DNS: Try using public DNS servers if resolution fails

Getting Help

If issues persist:

  1. Check existing issues at GitHub Issues

  2. Enable debug logging: LOG_LEVEL=debug

  3. Collect error messages and logs

  4. Create a new issue with:

    • Node.js version (node -v)

    • Operating system

    • Error messages

    • Steps to reproduce

📅 Changelog

Version 0.3.5 (Latest)

  • Enhanced Hybrid Matcher: Complete parameter extraction for all 15 tools

  • CLI/REPL Improvements: Interactive confirmations, job polling with progress

  • Bug Fixes: Task-list-generator auto-generates user stories, multi-turn conversations fixed

  • TypeScript Strict Mode: Zero any types, production-grade code quality

Version 0.3.1

  • Global installation synchronization fixes

  • Enhanced clean build process

  • Improved NPM packaging workflow

Version 0.2.8

  • CLI interactive mode configuration persistence

  • Enhanced project root detection

Version 0.2.7

  • Added missing configuration files to npm package

  • Resolved configuration loading errors

Version 0.2.3

  • Interactive REPL mode with chat interface

  • Enhanced setup wizard with auto-detection

  • Configuration templates

  • Unified CLI binary

For full release history, see GitHub Releases

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

11 tools
analyze-dependenciesB

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

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesThe 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
NameRequiredDescriptionDefault
classPropertiesNoFor classes: list of properties with names, optional types, and descriptions.
contextFilePathNoOptional relative path to a file whose content should be used as additional context.
descriptionYesDetailed description of what the stub should do, including its purpose, parameters, return values, or properties.
languageYesThe programming language for the stub (e.g., 'typescript', 'python', 'javascript')
methodsNoFor classes/interfaces: list of method signatures with names and descriptions.
nameYesThe name of the function, class, interface, etc.
parametersNoFor functions/methods: list of parameters with names, optional types, and descriptions.
returnTypeNoFor functions/methods: the expected return type string.
stubTypeYesThe 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
NameRequiredDescriptionDefault
include_optional_featuresNoOptional features to include (e.g., ['Docker', 'CI/CD'])
request_recommendationNoWhether to request recommendations for tech stack components based on research
tech_stack_preferencesNoOptional tech stack preferences (e.g., { frontend: 'Vue', backend: 'Python' })
use_caseYesThe 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
NameRequiredDescriptionDefault
stagedNoIf 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
NameRequiredDescriptionDefault
productDescriptionYesDescription 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
NameRequiredDescriptionDefault
productDescriptionYesDescription of the product being developed
ruleCategoriesNoOptional categories of rules to generate (e.g., 'Code Style', 'Security')
userStoriesNoOptional 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
NameRequiredDescriptionDefault
productDescriptionYesDescription of the product
userStoriesYesUser 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
NameRequiredDescriptionDefault
productDescriptionYesDescription 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
NameRequiredDescriptionDefault
requestYesNatural 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
NameRequiredDescriptionDefault
codeContentYesThe actual code snippet to be refactored.
contextFilePathNoOptional relative path to a file whose content provides broader context for the refactoring task.
languageYesThe programming language of the code snippet (e.g., 'typescript', 'python', 'javascript')
refactoringInstructionsYesSpecific 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
NameRequiredDescriptionDefault
queryYesThe 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. Dates show when Glama detected each change.

  1. 11 tool updatesv1.0.0
    • 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

TDQS

B3.1/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • -
    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.
    -
  • 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.
    4
    AGPL 3.0
  • 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.
    8
    18
    4
    MIT

Latest Blog Posts

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/freshtechbro/vibe-coder-mcp'

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