Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Vote-gated change control for WithVibe — the agent proposes a change via MCP; team approves first.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
The maker has not listed install details in the registry. See the maker’s README below.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 7, 2026
The registry name was verified with the GitHub account withvibe, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.1.0) reached the registry 5 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code.
In the same category: Spec Driven Development, Remote Desktop Commander, Excaliself
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Find, read, create, edit, and organize Excalidraw drawings in your self-hosted Excaliself instance.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
Turn any WithVibe env into a team-voted workspace. When this plugin is enabled, the AI doesn't apply a prompt straight away — it opens a proposal the team votes on, and only an approved proposal gets built. Enable it on any env and that env becomes a vote-gated sandbox.
You (in chat): "add a dark-mode toggle"
│ ▼ voter_propose_change ──────► Proposal #7 opens (10-min vote) │ 👍 👎 team votes in the panel voter_await_decision ◄─────── APPROVED ✅ / REJECTED ✗ │ ▼ (only if approved) agent makes the change ──► voter_record_change ──► shows up in History
It's content-agnostic — it knows nothing about what the env contains. Whatever the env is (an app, a doc, a 3D scene, a config), enabling Voter makes every change go through the team first. Multiple envs = multiple independent boards.
WithVibe auto-injects an enabled plugin's MCP tools into the agent's turn. Voter uses that to gate prompts without any change to WithVibe core:
voter_propose_change(prompt) — opens a proposal and tells the agent to not touch anything yet.voter_await_decision(proposal_id) — long-polls the vote. The platform's MCP bridge caps a single tool call at 60s, so this returns after ~45s with STILL_VOTING and the agent simply calls it again until it's terminal.APPROVED, the agent makes the change and calls voter_record_change. On REJECTED / EXPIRED it makes no change.Meanwhile every teammate votes in the plugin's own UI panel — independent of the agent. The gate is agent-cooperative (enforced via tool instructions), which is the right trade-off for a friendly workflow; hardening it to be unbypassable is a later option that would need a small core hook.
| Tool | Purpose |
|---|---|
voter_propose_change | Open a proposal for the requested change. Agent must call this instead of editing. |
voter_await_decision | Long-poll the team's verdict (APPROVED / REJECTED / EXPIRED / STILL_VOTING). |
voter_record_change | Record what shipped after applying an approved change. |
voter_report_failure | Mark an approved change as failed (e.g. build broke). |
voter_status | Show the current board: proposals in voting + recently resolved. |
Four tables in the plugin's isolated Postgres schema (shared-postgres storage): settings (vote window + thresholds), proposal, vote, feed_event.
Resolution rule: a proposal passes when approvals reach the threshold, fails when rejections reach the threshold, and at the deadline the majority wins (ties expire). Defaults: 600s window, 1 approval / 1 rejection — tune them in the panel.
manifest.yaml ──► WithVibe spawns one container per env (scope: env)
│ server.js (express) ├── /health platform health probe ├── /mcp agent's MCP endpoint ─► mcp.js (the gate) ├── /ui htmx voting panel ─► ui.js └── /ui/version cheap freshness check (live updates) │ db.js (pg) ─► shared-postgres, per-env schema
docker build -t local/voter:0.1 .
For the marketplace this is published multi-arch as ghcr.io/withvibe/voter: .
docker build -t local/voter:0.1 .
docker run --rm -p 8080:8080 \ -e DATABASE_URL="postgres://user:pass@host.docker.internal:5432/withvibe_plugins" \ -e PGSCHEMA="voter_dev" \ local/voter:0.1
manifest.yaml WithVibe plugin manifest (install input)
Dockerfile runtime image package.json deps (express, pg, @modelcontextprotocol/sdk, zod) server.js express entry — HTTP + MCP routes + vote handling db.js pg pool, schema, proposal/vote/resolution helpers mcp.js the gate: propose / await / record MCP tools ui.js htmx voting panel + dark theme
Apache License 2.0. See NOTICE for attribution.