Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Read-only MCP server to inspect an Android device over ADB: hardware, packages, permissions, logs.
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 orhanbalci, 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, FlyDocs
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.
Spec-driven development workflow: your agent works issues, sessions and the status lifecycle.
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.
Modular Rust toolkit for inspecting an Android device over ADB (USB debugging). One shared core powers two front-ends: a terminal UI (droidprobe) and an MCP server (droidprobe-mcp) for agents.
See ARCHITECTURE.md for the full design and phased plan.
| Overview | Packages | Logs |
|---|---|---|
droidprobe/
├── Cargo.toml # workspace + shared dep versions ├── ARCHITECTURE.md └── crates/ ├── droidprobe-parser/ # raw text -> structured data (pure, no I/O) ├── droidprobe-command/ # Command trait, Transport, built-in catalog ├── droidprobe-core/ # Registry + Engine + Poller ├── droidprobe-tui/ # ratatui binary (bin: droidprobe) └── droidprobe-mcp/ # rmcp binary (bin: droidprobe-mcp)
rustup recommended)adb server (adb start-server) and a device with USB debugging enabled and authorized.cargo build --workspace
cargo test --workspace # parser + command tests run without a device
cargo run -p droidprobe-tui
cargo run -p droidprobe-mcp # speaks MCP over stdio
Register it with an MCP client (e.g. Claude Desktop / Claude Code) by pointing the client at the built binary as a stdio server. Tools are read-only.
cargo build -p droidprobe-mcp --release
claude mcp add droidprobe -- "$(pwd)/target/release/droidprobe-mcp" claude mcp get droidprobe # should show "Status: ✔ Connected"
This must run on the same machine as the adb server and the USB-attached device — the server has no way to reach a device it can't adb shell into, so there's no meaningful way to run it detached on remote infrastructure unless you tunnel adb back to it.
Add to claude_desktop_config.json:
{
"mcpServers": { "droidprobe": { "command": "/absolute/path/to/target/release/droidprobe-mcp" } } }
Path-dependent crates must publish in dependency order — each one needs its predecessors already live on crates.io before cargo publish will resolve:
cargo login # one-time, needs your crates.io API token
cargo publish -p droidprobe-parser cargo publish -p droidprobe-command # only after droidprobe-parser is live cargo publish -p droidprobe-core # only after droidprobe-command is live cargo publish -p droidprobe-mcp # only after droidprobe-core is live cargo publish -p droidprobe-tui # optional, same dependency floor as mcp
crates.io indexes new releases within a minute or two; cargo publish for a downstream crate will fail with "no matching package found" if you run it too soon after the one before it. Once droidprobe-mcp is published, anyone with Rust installed can run:
cargo install droidprobe-mcp
.github/workflows/release.yml cross-builds both droidprobe (TUI) and droidprobe-mcp for macOS (Intel + Apple Silicon), Linux x86_64, and Windows x86_64 whenever a v*.*.* tag is pushed, and attaches the archives to a GitHub Release:
git tag v0.1.0
git push origin v0.1.0
The official MCP registry publishes via a dedicated CLI and validates namespace ownership through GitHub OAuth. A starter server.json is included in this repo — update its version to match each crates.io release, then:
brew install mcp-publisher
mcp-publisher login github mcp-publisher publish # validates server.json and submits it
Implement Command, wrap it in TypedDyn, and register it:
let mut registry = droidprobe_core::registry::Registry::with_builtins();
registry.register(Box::new(droidprobe_command::TypedDyn(MyCommand)));
10 tested parsers, 10 built-in commands, the registry/engine/poller, a TUI with Overview/Packages/Logs tabs (package search, permissions, and activity/service/receiver/provider component tabs), and a 10-tool MCP server covering the same device/package/log surface. Phases 2–6 (parser breadth, TUI depth, ATK command parity, MCP polish, robustness) are described in ARCHITECTURE.md.
MIT