vibecompass-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VIBECOMPASS_ROOT | No | Absolute path to local project-memory root for local mode (required for local or hybrid mode) | |
| VIBECOMPASS_API_KEY | No | API key for hosted mode (required for hosted or hybrid mode) | |
| VIBECOMPASS_API_URL | No | API URL (optional, defaults to https://vibecompass.dev) | https://vibecompass.dev |
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 |
|---|---|
| get_project_contextA | Call this FIRST at the START of every coding session. Returns a summary of the entire project: domains, features, their statuses, recent decisions, and open conflicts. Use this to orient yourself before writing any code. If you need detail on a specific feature, follow up with get_feature_context. |
| get_feature_contextA | Get FULL details for a specific feature before working on it. Returns description, components, involved files, repo ownership, recent decisions, and open conflicts for that feature. Always call this before modifying code that belongs to a feature. |
| get_decision_logA | Check past architectural decisions before proposing changes. Prevents re-debating settled decisions. Call this when you are unsure why something was built a certain way, or before making a significant architectural choice. |
| get_conflictsA | Check for open conflicts before starting work. Conflicts indicate areas where code changes contradicted prior decisions or where patterns collided. You MUST check conflicts before modifying affected features. |
| get_file_contextA | Before modifying any file, call this to understand which feature and component owns it. This prevents accidental cross-feature changes and helps you stay within the right domain. For multi-repo projects, pass file paths in repo:path form (for example "web:src/app/page.tsx"). |
| list_pending_proposalsA | Read hosted proposal summaries for Hybrid mode. This is read-only: local project-memory files remain authoritative, and proposal application must happen through the VibeCompass package sync flow. |
| log_decisionA | Log EVERY significant architectural decision you make during this session. This creates a permanent record that future sessions will read. If you chose between two approaches, log why. If you changed an existing pattern, explain the reasoning. Future sessions depend on this. |
| update_feature_statusA | Update a feature's status when you make progress. Mark "in_progress" when you start working on it, "complete" when done, "blocked" if stuck. This keeps the project brain accurate for the next session. |
| flag_conflictA | Flag a conflict when you notice contradictory patterns, duplicated logic across features, or disagreement with a past decision. Conflicts are surfaced to the developer in the dashboard for resolution. Do not try to auto-resolve conflicts — flag them and move on. |
| add_session_summaryA | Call this at the END of every coding session. Summarize what you accomplished, what is left to do, and any blockers. List all features you touched. The next AI session will read this summary to continue where you left off. |
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 10 tools
Every tool targets a distinct purpose: session summary, conflict management, decision logging, feature/file/project context, proposals, and status updates. No two tools overlap in functionality.
All tools follow a clear verb_noun pattern (e.g., get_feature_context, log_decision) using snake_case, making them predictable and easy to navigate.
With 10 tools, the set is well-scoped for a project context server. It covers session handling, conflicts, decisions, features, files, proposals, and status without being too numerous or sparse.
The tool surface covers the full lifecycle for project context: reading current state (get_project_context, get_feature_context, get_file_context, get_conflicts, get_decision_log, list_pending_proposals) and updating it (add_session_summary, flag_conflict, log_decision, update_feature_status). No obvious gaps.