Vibe Engineering MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_initializeB | Initializes or connects to a Vibe Engineering Project with SQLite operational state and .vibe/ directory |
| project_inspectB | Returns a full high-density status report of the engineering control plane (tasks, modules, git state, checkpoint) |
| project_resumeB | Provides complete, high-density continuation context for a fresh worker model resuming development |
| requirements_compileC | Compiles human-level product specifications into structured engineering capabilities and acceptance criteria |
| architecture_generateC | Synthesizes and records system design, modular boundaries, observable entrypoints, and contracts |
| architecture_validateB | Validates architecture DAG consistency, cycle prevention, and interface completeness |
| task_createC | Creates a new engineering task with dependencies and optional observable contract specification |
| task_nextA | Returns the next READY task in the dependency DAG for a worker to claim (prioritizing repair tasks and high priority tasks) |
| task_claimB | Claims a READY task for execution by a specific worker model |
| task_completeA | Submits a task for verification through the Completion Gate. Runs tests, executes the observable harness, inspects git diff, and enforces contract rules. If verification fails, an automatic repair task is created. |
| task_failC | Explicitly marks a task as FAILED and records reason |
| workspace_createB | Creates an isolated workspace and branch for a worker to implement a specific task safely |
| workspace_statusB | Returns status of all active worker workspaces |
| repo_read_fileB | Safely reads a file within the project workspace. Traversal outside workspace is blocked. |
| repo_write_fileB | Safely writes or updates a file within the project workspace, ensuring parent directories exist. |
| repo_delete_fileC | Safely deletes a file within the project workspace. |
| terminal_execA | Executes a terminal command safely scoped to the project workspace. Evaluates security policies, logs execution history, and captures stdout, stderr, exit code, and execution time. |
| git_statusB | Returns git working tree status, staged files, modified files, untracked files, and current branch |
| git_diffC | Returns git diff of modified files or staged changes |
| git_commitB | Stages changes and creates a git commit with structured message |
| git_branchC | Creates and checks out a new branch |
| git_mergeB | Merges specified branch into current branch with --no-ff |
| module_runC | Executes a module through its registered runnable harness, capturing full execution output and telemetry |
| module_observeC | Captures and records reproducible observable evidence from an executed command or system state |
| contract_verifyC | Validates collected observable evidence against contract rules (exit codes, output regex, JSON schema, artifacts) |
| integration_verifyC | Executes end-to-end integration harness across multiple modules to verify complete system behavior |
| checkpoint_createA | Creates a persistent checkpoint recording complete engineering state (git commit SHA, verified capabilities, tasks, failures, observations) for cold resumption |
| checkpoint_loadB | Loads a specific checkpoint by ID to inspect prior milestone state |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 28 tools
Most tools have clearly distinct resource-action purposes, with prefixes and descriptions that separate tasks, git, repo, workspace, architecture, and verification concerns. Some overlap exists among status/context tools such as project_inspect, project_resume, workspace_status, and checkpoint_load, but their descriptions make the intended use reasonably clear.
All tool names use consistent snake_case with predictable domain prefixes such as task_, git_, repo_, workspace_, architecture_, and checkpoint_. The verb/noun ordering is not perfectly uniform, but the convention is highly readable and consistent across the set.
28 tools is heavy and exceeds the ideal 3-15 range for a single MCP server. The complex engineering lifecycle justifies many of them, but there is likely room to consolidate status/context tools, making the surface borderline rather than well-scoped.
The set covers the major lifecycle stages: project setup, requirements, architecture, task DAGs, workspaces, file operations, terminal execution, git, modules, contracts, integration verification, and checkpoints. Minor gaps include no explicit task_update/task_list, checkpoint_list, or workspace_cleanup, but agents can work around these through project_inspect and terminal_exec.