Skip to main content
Glama
deenesjakoruzh
freshtechbro

Vibe Coder MCP

by freshtechbro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Servidor MCP de Vibe Coder

Prueba

Vibe Coder es un servidor MCP (Protocolo de Contexto de Modelo) diseñado para potenciar tu asistente de IA (como Cursor, Cline AI o Claude Desktop) con potentes herramientas para el desarrollo de software. Te ayuda con la investigación, la planificación, la generación de requisitos, la creación de proyectos iniciales y mucho más.

Descripción general y características

Vibe Coder MCP se integra con clientes compatibles con MCP para proporcionar las siguientes capacidades:

  • Enrutamiento de solicitudes semánticas : enruta de forma inteligente las solicitudes mediante correspondencia semántica basada en incrustación con alternativas de pensamiento secuencial.

  • Arquitectura de registro de herramientas : gestión centralizada de herramientas con herramientas de registro automático.

  • Llamadas LLM directas : las herramientas del generador ahora utilizan llamadas LLM directas para lograr una confiabilidad mejorada y un control de salida estructurado.

  • Ejecución de flujo de trabajo : ejecuta secuencias predefinidas de llamadas de herramientas definidas en workflows.json .

  • Investigación y planificación : realiza investigaciones profundas ( research-manager ) y genera documentos de planificación como PRD ( generate-prd ), historias de usuario ( generate-user-stories ), listas de tareas ( generate-task-list ) y reglas de desarrollo ( generate-rules ).

  • Andamiaje de proyectos : genera kits de inicio completos ( generate-fullstack-starter-kit ).

  • Generador de mapas de código : escanea recursivamente una base de código, extrae información semántica y genera un índice Markdown denso en contexto y eficiente en tokens con diagramas de sirena o una representación JSON estructurada con rutas de archivo absolutas para importaciones e información de propiedades de clase mejorada ( map-codebase ).

  • Ejecución asíncrona : Muchas herramientas de larga duración (generadores, investigación, flujos de trabajo) ahora se ejecutan asíncronamente. Devuelven un ID de trabajo inmediatamente y el resultado final se recupera mediante la herramienta get-job-result .

  • Gestión del estado de la sesión : mantiene el estado básico en todas las solicitudes dentro de una sesión (en memoria).

  • Manejo de errores estandarizado : patrones de error consistentes en todas las herramientas.

(Consulte las secciones "Documentación detallada de la herramienta" y "Detalles de las funciones" a continuación para obtener más información)

Related MCP server: Jilebi

Guía de configuración

Siga estos micropasos para poner en funcionamiento el servidor Vibe Coder MCP y conectarlo a su asistente de inteligencia artificial.

Paso 1: Requisitos previos

  1. Comprobar la versión de Node.js:

    • Abra una terminal o un símbolo del sistema.

    • Ejecutar node -v

    • Asegúrese de que la salida muestre v18.0.0 o superior (obligatorio).

    • Si no está instalado o está desactualizado: Descárguelo desde nodejs.org .

  2. Comprobar la instalación de Git:

    • Abra una terminal o un símbolo del sistema.

    • Ejecutar git --version

    • Si no está instalado: descargar desde git-scm.com .

  3. Obtener la clave API de OpenRouter:

    • Visita openrouter.ai

    • Crea una cuenta si no tienes una.

    • Vaya a la sección Claves API.

    • Crea una nueva clave API y cópiala.

    • Mantenga esta clave a mano para el paso 4.

Paso 2: Obtener el código

  1. Crear un directorio de proyecto (opcional):

    • Abra una terminal o un símbolo del sistema.

    • Navegue hasta donde desea almacenar el proyecto:

      cd ~/Documents     # Example: Change to your preferred location

  2. Clonar el repositorio:

    • Correr:

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

      (O utilice la URL de su bifurcación si corresponde)

  3. Navegar al directorio del proyecto:

    • Correr:

      cd vibe-coder-mcp

Paso 3: Ejecute el script de configuración

Elija el script apropiado para su sistema operativo:

Para Windows:

  1. En su terminal (aún en el directorio vibe-coder-mcp), ejecute:

    setup.bat

  2. Espere a que se complete el script (instalará las dependencias, compilará el proyecto y creará los directorios necesarios).

  3. Si ve algún mensaje de error, consulte la sección Solución de problemas a continuación.

Para macOS o Linux:

  1. Hacer que el script sea ejecutable:

    chmod +x setup.sh

  2. Ejecute el script:

    ./setup.sh

  3. Espere a que se complete el script.

  4. Si ve algún mensaje de error, consulte la sección Solución de problemas a continuación.

El script realiza estas acciones:

  • Comprueba la versión de Node.js (v18+)

  • Instala todas las dependencias a través de npm

  • Crea los subdirectorios VibeCoderOutput/ necesarios (como se define en el script).

  • Construye el proyecto TypeScript.

  • Copia .env.example a .env si .env no existe. Deberá editar este archivo.

  • Establece permisos ejecutables (en sistemas Unix).

Paso 4: Configurar variables de entorno ( .env )

El script de instalación (del paso 3) crea automáticamente un archivo .env en el directorio raíz del proyecto copiando la plantilla .env.example , solo si .env no existe ya .

  1. Localice y abra .env : busque el archivo .env en el directorio principal vibe-coder-mcp y ábralo con un editor de texto.

  2. Agregue su clave API de OpenRouter (obligatoria):

    • El archivo contiene una plantilla basada en .env.example :

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

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

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

    • Es fundamental reemplazar "Your OPENROUTER_API_KEY here" por su clave API de OpenRouter. Elimine las comillas si su clave no las requiere.

  3. Configurar directorio de salida (opcional):

    • Para cambiar dónde se guardan los archivos generados (el valor predeterminado es VibeCoderOutput/ dentro del proyecto), agregue esta línea a su archivo .env :

      VIBE_CODER_OUTPUT_DIR=/path/to/your/desired/output/directory

    • Reemplace la ruta con la ruta absoluta que prefiera. Use barras diagonales ( / ) para las rutas. Si esta variable no está configurada, se usará el directorio predeterminado ( VibeCoderOutput/ ).

  4. Configurar el directorio del generador de mapas de código (opcional):

    • Para especificar qué directorio puede escanear la herramienta generadora de mapas de código, agregue esta línea a su archivo .env :

      CODE_MAP_ALLOWED_DIR=/path/to/your/source/code/directory

    • Reemplace la ruta con la ruta absoluta al directorio que contiene el código fuente que desea analizar. Esto es un límite de seguridad: la herramienta no accederá a archivos fuera de este directorio.

    • Tenga en cuenta que CODE_MAP_ALLOWED_DIR (para leer el código fuente) y VIBE_CODER_OUTPUT_DIR (para escribir los archivos de salida) son independientes por razones de seguridad. La herramienta generadora de mapas de código utiliza una validación independiente para las operaciones de lectura y escritura.

  5. Revisar otras configuraciones (opcional):

    • Puede agregar otras variables de entorno compatibles con el servidor, como LOG_LEVEL (por ejemplo, LOG_LEVEL=debug ) o NODE_ENV (por ejemplo, NODE_ENV=development ).

  6. Guarde el archivo .env .

Paso 5: Integración con su asistente de IA (Configuración de MCP)

Este paso crucial conecta Vibe Coder con su asistente de IA agregando su configuración al archivo de configuración MCP del cliente.

5.1: Localice el archivo de configuración MCP de su cliente

La ubicación varía según tu asistente de IA:

  • Cursor AI / Windsurf / RooCode (basado en VS Code):

    1. Abra la aplicación.

    2. Abra la paleta de comandos ( Ctrl+Shift+P o Cmd+Shift+P ).

    3. Escriba y seleccione Preferences: Open User Settings (JSON) .

    4. Esto abre el archivo settings.json donde debe residir el objeto mcpServers .

  • Cline AI (extensión de VS Code):

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

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

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

    • (Nota: Si usa VS Code estándar en lugar de Cursor, reemplace Cursor con Code en la ruta)

  • Escritorio de Claude:

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

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

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

5.2: Agregar la configuración de Vibe Coder

  1. Abra el archivo de configuración identificado anteriormente en un editor de texto.

  2. Busque el objeto JSON "mcpServers": { ... } . Si no existe, puede que tenga que crearlo (asegúrese de que el archivo general siga siendo un JSON válido). Por ejemplo, un archivo vacío podría convertirse en {"mcpServers": {}} .

  3. Agregue el siguiente bloque de configuración dentro de las llaves {} del objeto mcpServers . Si ya hay otros servidores listados, agregue una , después de la llave de cierre } del servidor anterior antes de pegar este bloque.

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

  4. CRUCIAL: Reemplace todas las rutas de marcador de posición (como /path/to/your/vibe-coder-mcp/... ) con las rutas absolutas correctas en el sistema donde clonó el repositorio. Use barras diagonales / para las rutas, incluso en Windows (p. ej., C:/Users/YourName/Projects/vibe-coder-mcp/build/index.js ). Las rutas incorrectas son la causa más común de que el servidor no se conecte.

  5. Guarde el archivo de configuración.

  6. Cierre y reinicie completamente su aplicación de asistente de IA (Cursor, VS Code, Claude Desktop, etc.) para que los cambios surtan efecto.

Paso 6: Pruebe su configuración

  1. Inicie su asistente de IA:

    • Reinicie completamente su aplicación de asistente de IA.

  2. Pruebe un comando simple:

    • Escriba un comando de prueba como: Research modern JavaScript frameworks

  3. Verifique la respuesta adecuada:

    • Si funciona correctamente, debería recibir una respuesta de investigación.

    • En caso contrario, consulte la sección Solución de problemas a continuación.

Arquitectura del proyecto

El servidor Vibe Coder MCP sigue una arquitectura modular centrada en un patrón de registro de herramientas:

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

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

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

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

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

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

Estructura del directorio

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

## Semantic Routing System

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

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

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

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

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

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

Patrón de registro de herramientas

El Registro de herramientas es un componente central para administrar las definiciones y la ejecución de herramientas:

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

Proceso de pensamiento secuencial

El mecanismo de pensamiento secuencial proporciona una ruta de respaldo basada en LLM:

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

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

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

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

Gestión del estado de la sesión

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

Motor de ejecución de flujo de trabajo

El sistema Workflow permite secuencias de varios pasos:

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

Configuración del flujo de trabajo

Los flujos de trabajo se definen en el archivo workflows.json , ubicado en el directorio raíz del proyecto. Este archivo contiene secuencias predefinidas de llamadas a herramientas que se pueden ejecutar con un solo comando.

Ubicación y estructura de los archivos

  • El archivo workflows.json debe ubicarse en el directorio raíz del proyecto (mismo nivel que package.json)

  • El archivo sigue esta estructura:

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

Plantillas de parámetros

Los parámetros de paso del flujo de trabajo admiten cadenas de plantilla que pueden hacer referencia a:

  • Entradas de flujo de trabajo: {workflow.input.paramName}

  • Resultados del paso anterior: {steps.stepId.output.content[0].text}

Activación de flujos de trabajo

Utilice la herramienta run-workflow con:

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

Documentación detallada de la herramienta

Cada herramienta del directorio src/tools/ incluye documentación completa en su propio archivo README.md. Estos archivos abarcan:

  • Descripción general y propósito de la herramienta

  • Especificaciones de entrada/salida

  • Diagramas de flujo de trabajo (Mermaid)

  • Ejemplos de uso

  • Indicaciones del sistema utilizadas

  • Detalles de manejo de errores

Consulte estos archivos README individuales para obtener información detallada:

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

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

  • src/tools/research-manager/README.md

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

  • src/tools/task-list-generator/README.md

  • src/tools/user-stories-generator/README.md

  • src/tools/workflow-runner/README.md

  • src/tools/code-map-generator/README.md

Categorías de herramientas

Herramientas de análisis e información

  • Generador de mapas de código ( map-codebase ) : escanea una base de código para extraer información semántica (clases, funciones, comentarios) y genera un mapa Markdown legible por humanos con diagramas de Mermaid o una representación JSON estructurada con rutas de archivos absolutas para importaciones e información de propiedades de clase mejorada.

  • Gerente de investigación ( research-manager ) : realiza investigaciones profundas sobre temas técnicos utilizando Perplexity Sonar, proporcionando resúmenes y fuentes.

Herramientas de planificación y documentación

  • Generador de reglas ( generate-rules ): crea reglas y pautas de desarrollo específicas del proyecto.

  • Generador de PRD ( generate-prd ): genera documentos completos de requisitos del producto.

  • Generador de historias de usuario ( generate-user-stories ): crea historias de usuario detalladas con criterios de aceptación.

  • Generador de listas de tareas ( generate-task-list ): crea listas de tareas de desarrollo estructuradas con dependencias.

Herramienta de andamiaje de proyectos

  • Generador de kits de inicio fullstack ( generate-fullstack-starter-kit ): crea kits de inicio de proyectos personalizados con tecnologías frontend/backend específicas, incluidos scripts de configuración y configuración básicos.

Flujo de trabajo y orquestación

  • Ejecutor de flujo de trabajo ( run-workflow ): ejecuta secuencias predefinidas de llamadas de herramientas para tareas de desarrollo comunes.

Almacenamiento de archivos generados

De forma predeterminada, los resultados de las herramientas del generador se almacenan como referencia histórica en el directorio VibeCoderOutput/ del proyecto. Esta ubicación se puede sobrescribir configurando la variable de entorno VIBE_CODER_OUTPUT_DIR en el archivo .env o en la configuración del asistente de IA.

Límites de seguridad para operaciones de lectura y escritura

Por razones de seguridad, las herramientas Vibe Coder MCP mantienen límites de seguridad separados para las operaciones de lectura y escritura:

  • Operaciones de lectura : Herramientas como el generador de mapas de código solo leen de directorios autorizados explícitamente mediante la variable de entorno CODE_MAP_ALLOWED_DIR . Esto crea un límite de seguridad claro y evita el acceso no autorizado a archivos fuera del directorio permitido.

  • Operaciones de escritura : Todos los archivos de salida se escriben en el directorio VIBE_CODER_OUTPUT_DIR (o sus subdirectorios). Esta separación garantiza que las herramientas solo puedan escribir en las ubicaciones de salida designadas, protegiendo así el código fuente de modificaciones accidentales.

Estructura de ejemplo (ubicación predeterminada):

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

Ejemplos de uso

Interactúe con las herramientas a través de su asistente de IA conectado:

  • Investigación: Research modern JavaScript frameworks

  • Generar reglas: Create development rules for a mobile banking application

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

  • Generar historias de usuario: Generate user stories for an e-commerce website

  • Generar lista de tareas: Create a task list for a weather app based on [user stories]

  • Pensamiento secuencial: Think through the architecture for a microservices-based e-commerce platform

  • Kit de inicio Fullstack: Create a starter kit for a React/Node.js blog application with user authentication

  • Ejecutar flujo de trabajo: Run workflow newProjectSetup with input { "projectName": "my-new-app", "description": "A simple task manager" }

  • Base de código del mapa: Generate a code map for the current project , map-codebase path="./src" , o Generate a JSON representation of the codebase structure with output_format="json"

Ejecución local (opcional)

Si bien el uso principal es la integración con un asistente de IA (usando stdio), puedes ejecutar el servidor directamente para realizar pruebas:

Modos de ejecución

  • Modo de producción (Stdio):

    npm start

    • Los registros van a stderr (imita el inicio del asistente de IA)

    • Utilice NODE_ENV=producción

  • Modo de desarrollo (Stdio, Pretty Logs):

    npm run dev

    • Los registros van a la salida estándar con un formato atractivo

    • Requiere nodemon y pino-pretty

    • Utilice NODE_ENV=desarrollo

  • Modo SSE (interfaz HTTP):

    # Production mode over HTTP
npm run start:sse

# Development mode over HTTP
npm run dev:sse

    • Utiliza HTTP en lugar de stdio

    • Configurado a través de PORT en .env (predeterminado: 3000)

    • Acceso en http://localhost:3000

Solución de problemas detallada

Problemas de conexión

El servidor MCP no se detecta en el Asistente de IA

  1. Comprobar ruta de configuración:

    • Verifique que la ruta absoluta en la matriz args sea correcta

    • Asegúrese de que todas las barras sean barras diagonales / pares en Windows

    • Ejecute node <path-to-build/index.js> directamente para probar si Node puede encontrarlo

  2. Formato de configuración de verificación:

    • Asegúrese de que JSON sea válido sin errores de sintaxis

    • Compruebe que las comas entre propiedades sean correctas

    • Verifique que el objeto mcpServers contenga su servidor

  3. Reiniciar el Asistente:

    • Cerrar completamente (no solo minimizar) la aplicación

    • Vuelva a abrir e intente nuevamente

El servidor se inicia pero las herramientas no funcionan

  1. Marcar la bandera deshabilitada:

    • Asegúrese de que "disabled": false esté configurado

    • Elimine cualquier comentario // ya que JSON no los admite

  2. Verificar la matriz de aprobación automática:

    • Compruebe que los nombres de las herramientas en la matriz autoApprove coincidan exactamente

    • Intente agregar "process-request" a la matriz si usa enrutamiento híbrido

Problemas con la clave API

  1. Problemas clave de OpenRouter:

    • Verifique nuevamente que la clave esté copiada correctamente

    • Verifique que la clave esté activa en su panel de control de OpenRouter

    • Comprueba si tienes suficientes créditos

  2. Problemas de variables ambientales:

    • Verifique que la clave sea correcta en ambos:

      • El archivo .env (para ejecuciones locales)

      • Bloque de configuración env de su asistente de IA

Problemas de ruta y permisos

  1. Directorio de compilación no encontrado:

    • Ejecute npm run build para asegurarse de que exista el directorio de compilación

    • Verifique si la salida de la compilación va a un directorio diferente (verifique tsconfig.json)

  2. Errores de permisos de archivos:

    • Asegúrese de que su usuario tenga acceso de escritura al directorio workflow-agent-files

    • En sistemas Unix, verifique si build/index.js tiene permiso de ejecución

Depuración de registros

  1. Para carreras locales:

    • Verifique la salida de la consola para ver si hay mensajes de error

    • Intente ejecutar con LOG_LEVEL=debug en su archivo .env

  2. Para ejecuciones del Asistente de IA:

    • Establezca "NODE_ENV": "production" en la configuración del entorno

    • Compruebe si el asistente tiene una consola de registro o una ventana de salida

Problemas específicos de las herramientas

  1. El enrutamiento semántico no funciona:

    • La primera ejecución puede descargar el modelo de incrustación: verifique los mensajes de descarga

    • Pruebe una solicitud más explícita que mencione el nombre de la herramienta

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.

  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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored across 11 tools

Disambiguation3/5

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

Naming Consistency4/5

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

Tool Count4/5

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

Completeness3/5

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

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Arthur

    moechehabb
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server that enables developers to summon AI development team agents directly from their IDE to help with tasks like PR reviews, security evaluation, and CI/CD deployment setup.
    -

  • Jilebi

    Datron
    A
    license
    Not graded
    quality
    B
    maintenance
    A plugin-based MCP server that enables AI assistants to interact with external systems through custom tools, resources, and prompts.
    4
    AGPL 3.0

  • Kortx MCP Server

    effatico
    A
    license
    A
    quality
    C
    maintenance
    A lightweight MCP server that provides coding copilots with access to GPT-5, Perplexity Sonar, and GPT Image models, offering tools for planning, debugging, research, and image generation.
    8
    8 npm
    4
    MIT

  • mcdev-mcp

    use-ai-for-mc
    A
    license
    A
    quality
    B
    maintenance
    An MCP server that empowers AI coding agents to work effectively with Minecraft mod development, providing static analysis of decompiled source code and runtime interaction with a running Minecraft instance.
    31
    55 npm
    14
    MIT

Appeared in Searches