VibeWise 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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vibe_statusA | VibeWise: check the learning gate for this project - active mode, current checkpoint stage, pending decision, and what you must do next. Call this before starting any coding work and whenever unsure whether coding is allowed. |
| vibe_startB | VibeWise: activate learning-first mode (creates .vibe-wise/, runs onboarding one question at a time, or resumes a paused/pending state). Call before the first build task. |
| vibe_onboard_answerB | VibeWise: record one onboarding answer from the user and get the next question. Never answer these yourself. |
| vibe_checkpointA | VibeWise: open a checkpoint BEFORE doing the work. kind=build: ask how the USER would approach the problem (their reasoning first, never your design). kind=design: present the agreed design + tradeoffs for confirmation. kind=implement: present the exact code changes for approval - the only gate that authorizes writing code. |
| vibe_confirmA | VibeWise: resolve the open checkpoint with the USER's decision. option=confirm for 'Confirm and continue' (design) or 'Implement this step' (implement); option=discuss when they asked questions; option=approach + userText to record the user's own build-stage reasoning. Without this tool's record, code must not be written. |
| vibe_reportA | VibeWise: record the implementation report after approved coding: what changed, how it works, why it fits the design, and real verification results. |
| vibe_map_updateC | VibeWise: update the evidence-based project map (purpose, components, flow, boundaries, unknowns). Mark unknowns as unknown. |
| vibe_pauseB | VibeWise: pause learning mode (gate off) at the user's request, or resume it. |
| vibe_resetA | VibeWise: restart learning from scratch. Call without confirm for a preview token; back up + reset only after the user explicitly confirms, passing the token back. |
| vibe_read_notesB | VibeWise: read all learning notes (.vibe-wise/*.md) plus the parsed gate state. Use for session restoration and compaction recovery; search ALL of progress.md for pending decisions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| VibeWise behavior guide | How to run learning-first development through the vibe_* tools. Read once per conversation. |
TDQS
Scored across 10 tools
Most tools map to distinct lifecycle stages (start, checkpoint, confirm, report, reset), but vibe_status and vibe_read_notes both surface gate/state info, and vibe_pause's 'resume' overlaps with vibe_start's 'resumes a paused/pending state'. Descriptions mostly disambiguate these, so confusion risk is low.
Every tool uses the same vibe_ prefix with a consistent snake_case noun/verb (vibe_status, vibe_start, vibe_checkpoint, vibe_map_update). No camelCase or mixed conventions, so the pattern is fully predictable.
10 tools is well within the ideal 3-15 range and each corresponds to a distinct step of the learning-gate workflow. No tool feels redundant or filler.
The surface covers the full learning lifecycle: activation, onboarding, checkpoints, confirmation, reporting, map maintenance, pause/resume, reset, and state reading. Minor gap: no explicit way to answer/close an onboarding session or query individual notes, but agents can work around these.