vibe-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MISTRAL_API_KEY | No | Mistral API key for Vibe, used when not relying on the system keyring login (`vibe --setup`). | |
| VIBE_MCP_CONFIG | No | Path to the optional vibe-mcp config.toml file (default: ~/.config/vibe-mcp/config.toml). | |
| DBUS_SESSION_BUS_ADDRESS | No | D-Bus session bus address that must reach the server when using the keyring login; often missing over SSH or in tmux. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vibe_submitA | Queue a coding task for Mistral Vibe (a cheaper model) in an isolated git worktree. spec: complete and self-contained; Vibe sees neither this chat nor project docs. skill: name of a Vibe skill (.vibe/skills//SKILL.md in the repo or ~) to follow. scope: repo-relative paths the task may touch; jobs with overlapping scopes run one after another (omit = whole repo). base_job: build on another job's result. Returns at once. Then: vibe_wait, vibe_result, vibe_apply. |
| vibe_waitA | Wait until any job (every job if wait_all) in job_ids ends, or timeout seconds pass. Default job_ids: all active jobs. timeout=0 just reports status. One line per job. |
| vibe_resultA | Outcome of a job: Vibe's own summary (unverified), diffstat, added files, scope violations, tokens and cost. diff=true appends the diff (capped). |
| vibe_cancelA | Cancel a queued job, or kill a running one. Its worktree is kept. |
| vibe_applyA | Stage a finished job's changes in the main checkout (git merge --squash, no commit). Conflicts are reported and nothing changes. discard=true drops the job's worktree and branch instead. |
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 5 tools
Each tool maps to a distinct lifecycle phase: submit queues work, wait blocks for completion, result inspects the outcome, apply stages or discards changes, and cancel aborts a job. The boundaries are reinforced by descriptions that cross-reference the natural workflow (submit -> wait -> result -> apply), leaving little room for misselection.
All tools share a consistent vibe_ prefix with single-word suffixes, which is predictable and readable. The minor deviation is that four names are verbs (submit, wait, cancel, apply) while vibe_result is a noun, though that is idiomatic for an inspection tool.
Five tools is well-scoped for a job-delegation lifecycle, and each one earns its place with no redundant overlap. Nothing feels thin because wait with timeout=0 doubles as a status poll, and nothing feels padded.
The surface covers the full lifecycle: enqueue, await, inspect (summary, diffstat, diff, cost, scope violations), apply/discard, and cancel. Minor gaps remain, such as no dedicated job-listing/history tool for finished jobs and no way to un-apply a staged squash without manual git work, but these are workable.