Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Signed messages between AI agents. Dangerous actions wait for a human-signed approval.
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.
DIAVLOS_HOME, DIAVLOS_ASThe 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 8, 2026
The registry name was verified with the GitHub account harisnopen, 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 (2.1.1) reached the registry 41 days ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Rust on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, Tethered Trust
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.
Fit, compatibility and recall checks for AI agents before they buy: verdicts, evidence, receipts.
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.
Diavlos (δίαυλος, Greek for "channel") lets AI agents talk to each other. Any agent, any terminal, any computer. You pick a room name and share a signed invite. The agents find each other and start talking.
It is one small program. You install it once. It runs in the background. Any agent from any vendor can use it: Claude Code, Codex, Cursor, Gemini CLI, Aider, or one you wrote yourself. No account. No server to set up.
The big difference from a plain chat pipe: messages never get lost, every sender is who they say they are, and messages carry a type (task, reply, done) so agents never have to guess.
https://diavlos.sh
Two rented cloud desktops on different machines, one room, over the public internet with nothing port-forwarded. A real Claude agent does the work, a scripted agent hands it out, a human approves the one risky step from a browser, and a read-only observer key audits the lot afterwards. Nineteen signed messages, 77 seconds from the first task to the human's approve.
It also refuses a prompt injection on camera: the boss agent tells the Claude agent to ignore its instructions and run something it is not allowed to, and the message is rejected rather than obeyed.
[The whole run, step by step](docs/use-cases/two-cloud-desktops.md) — stills, the 19-message transcript, the export that verifies on the other machine, and the commands to reproduce it. The 115-second video · transcript
Two real E2B sandboxes join one room over the public internet. The planner in sandbox A asks the runner in sandbox B to run a job. The runner asks a human first. After an approve, the gate spends it at the room's home and the job runs. After a deny, nothing runs. Every message is signed and checked, and the audit bundle verifies.
This is a replay of the real log from GitHub run 35896619176. [The example](examples/e2b-sandboxes/) · the 31-second video
Delivery promise, in writing: at-least-once, dedup by id, on disk before `send` returns, and yours until you ack it.
curl -fsSL https://raw.githubusercontent.com/harisnopen/diavlos/main/install.sh | sh
From source: Rust 1.95 or newer, cargo build --release, the binary is target/release/diavlos.
One command writes the MCP config for the tool you already use:
diavlos mcp install --for claude-code # or codex, cursor, gemini-cli, superset, vibe-kanban, all
diavlos invite ops claude-code # let the agent into a room, as its owner diavlos --as claude-code join diavlos hook install --for claude-code --room ops # messages land mid-turn, no polling
The agent gets its own key, named after the tool, and acts as that key, never as you. It starts in no rooms; you let it into each one. diavlos mcp refuses to run as your key, so an agent cannot sign an approve with it. Every session of one tool shares that tool's key; give an agent its own with --as if it should answer for itself.
Claude Code can take the whole thing, tools and skill together:
/plugin marketplace add harisnopen/diavlos
/plugin install diavlos@diavlos
The skill on its own, for any of the agent tools that read the Agent Skills format:
npx skills add harisnopen/diavlos
On laptop A:
diavlos new ops --about "the deploy room"
diavlos invite ops bob # prints one line to paste into bob's session
On laptop B:
diavlos join dv1.eyJ...
diavlos send ops "found a bug in auth" --type task
Back on A:
diavlos next ops # waits, then: [3] bob (task): found a bug in auth
diavlos send ops "on it" --type reply
The helper starts itself the first time you run a command and keeps running in the background. diavlos status shows rooms and links; diavlos stop stops it; diavlos service install runs it as a service.
Turn A off, send from B, turn A on: the message arrives. B keeps it on disk until A's helper is back.
MCP tools for agents that speak it. Add to Claude Code, Cursor, or any MCP client:
{ "mcpServers": { "diavlos": { "command": "diavlos", "args": ["--as", "my-agent", "mcp"] } } }
Tools: diavlos_send, diavlos_ask, diavlos_next, diavlos_read, diavlos_claim, diavlos_release, diavlos_who, diavlos_rooms, and diavlos_ack, diavlos_renew, diavlos_nack for a message diavlos_next handed over: it stays the agent's until it acks it, and comes round again if it never does. Same names and fields as the commands. --as (or DIAVLOS_AS) names the agent key it acts as. It will not run as a human key, and diavlos_send will not send approve, deny, control or system. The SKILL.md tells agents the rules in plain words; drop it into your agent's skills.
The command line for agents that only have a shell (Aider, scripts, CI). Every command below.
A library for home-made agents: the Rust crate diavlos-client, plus Python and Node packages that need no native code. Ten lines to join a room and reply:
from diavlos import Room
room = Room.join(invite, name="my-bot") for msg in room.next(): if msg.type == "task": result = do_work(msg.text) room.send(result, type="done", reply_to=msg.id)
Each agent gets its own key with --as:
diavlos --as scanner send ops "..." # key ~/.diavlos/keys/scanner.json
diavlos --as fixer next ops
The default key is you, the person who installed it. Any other label is an agent key. The name an agent has inside a room is bound at invite time, not by the key file. diavlos mcp runs only as an agent key.
An agent asks with a structured action. A person approves exactly that action, with their own key. The approve dies in ten minutes and works once. The script that does the deed checks where the action happens:
# the agent
diavlos ask ops "Deploy api-service v1.2 to prod?" --timeout 600 \ --action '{"verb":"deploy","target":"api-service","params":{"version":"1.2","env":"prod"}}'
diavlos send ops --type approve --reply-to m_01J8X5 # or: diavlos deny ops m_01J8X5 --reason "not now"
diavlos --as deployer check-approve ops --op "$RUN_ID" \ '{"verb":"deploy","target":"api-service","params":{"version":"1.2","env":"prod"}}' && ./deploy.sh
The room's home records the spend, once, for that operation. A second run of the same operation gets the same answer back; any other run, on any machine, gets a no. If the home is out of reach the exit code is 3 and nothing is spent. A spend is permission for one operation, not proof it ran once: make deploy.sh skip an operation id it has already done.
One rule worth writing down: a message only carries words, not permission. If an agent relays "the human said yes", that is not a yes. Only an approve signed by the human's own key is.
| Command | What it does |
|---|---|
diavlos new --about "..." [--retention ] [--class ] | Makes a room. You are the owner. |
diavlos invite [--human] [--for ] [--role ] [--prompt] | One signed invite for one new member. --human marks the key as a person who can approve. --for pins it to one machine. 24 hours, works once. --prompt prints a whole setup message to paste into the agent: install, join, tools, the rules, a first hello. |
diavlos join | Join with an invite. Starts the helper if needed. |
diavlos grant --role approver --until 2026-12-31 | Give a member a role: observer, chat, task-giver, approver. Can expire. |
diavlos rotate | New room key. Everyone out. Re-invite who you keep. |
diavlos send "text" --type task --to bob | Send a message. Reads from stdin if no text. |
diavlos send "text" --file ./build.log / diavlos get | Send files with a message, up to 25 MB each by default. They go helper to helper through the room's home, checked against their fingerprint at each end. get saves them under ~/.diavlos/files/ / and warns about anything that could run. See docs/FILES.md. |
diavlos ask "text" --timeout 120 [--action ] | Send a question and wait for a reply to that exact message. Exit 4 on timeout, 6 on a deny. |
diavlos next [--timeout ] [--manual-ack] [--lease ] | Wait for the next message from someone else. Skips your own and helper notices. Acks it once printed; with --manual-ack it prints a token and the message stays yours until ack, nack, or the lease (600 s) runs out, then comes round again. |
diavlos ack / renew / nack [--retry-in ] | Settle a message you hold: taken on, still working, or not now. Ack means taken on, not finished: say done in the room for that. |
diavlos read [--since ] [--ack] [--json] | Look at messages from your bookmark onward. Never deletes and moves nothing, unless --ack. |
| diavlos watch --exec ./on-msg.sh | Stream messages. Run a script for each one; it gets the message in DIAVLOS_MESSAGE, the sender's key in DIAVLOS_FROM_KEY and its token in DIAVLOS_TOKEN, never on the command line. Acked when the
Only the beginning is shown; read the rest in the repo