Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
제작자가 쓴 설명(영어 원문)
An AI agent reads your server over the one SSH session you are already watching.
이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.
이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.
쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.
제작자가 레지스트리에 설치 정보를 올리지 않았어요. 아래 제작자의 README를 확인하세요.
내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.
누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 6일 점검
레지스트리 이름이 GitHub 계정 meta-taro 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요
내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요
내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요
레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.
해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.
레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.
내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).
GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.1.39)은 오늘 레지스트리에 올라왔어요.
Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요.
같은 카테고리에는: Spec Driven Development, Remote Desktop Commander, HotCodePush
같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.
카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i
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.
Manage over-the-air (OTA) updates for React Native, Expo, Capacitor and Cordova apps.
제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.
*English / 日本語*
Your AI agent and you, looking at the same server, on the same screen, over one SSH connection.
You keep your own SFTP client and your own terminal. The agent works beside you — inside a fence you drew — and every single thing it does scrolls past in your window while it happens.
⚠️ This is alpha. It is in use on production servers (investigating a failed
certificate renewal, restarting pm2, and so on). Installers are published for Windows
(x64 / ARM64) and macOS.
Passing tests does not mean it works as a tool — we shipped a build whose terminal
displayed *not one byte* for three days (Issue #10).
[⬇ Download](https://github.com/meta-taro/sshboard/releases/latest) · Direction · Every decision, with its reasoning
You have a terminal open per host and you are copying the same command into each, watching for the one that fails. sshboard opens one console per connection — or two on the same host, side by side — and the agent can read *all* of them while you work. Not "the agent runs it for you": the agent watches what you are doing and tells you which pane went wrong.
You ask the agent. It reads /etc/postfix/main.cf, checks the service, tails the log — over the same SSH session you are already on, and you see each step as it happens. It cannot run an arbitrary command to do it: there is no `run_command(cmd)` tool.
[Human] $ cd /var/www
[AI] $ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 38G 10G 80% / [AI] read /etc/postfix/main.cf (4.1 KB)
The agent may write only inside directories you listed, one connection at a time. The list starts empty, so it cannot write a single byte until you say where. Delete, rename, move, chmod, restart, package installs, sudo — none of them exist for the agent. You are not restricted anywhere.
Install the app, then point your agent at it. There is nothing else to run — the MCP server lives inside the app.
# 1. a throwaway SSH server on your own machine (needs Docker)
sh tools/test-server/up.sh ssh-add tools/test-server/.key
pnpm install pnpm --filter desktop tauri dev
Register 127.0.0.1:2222, user probe, connect, then press Copy the MCP command in the window's title bar and paste it into your agent:
claude mcp add --scope user --transport http sshboard http://127.0.0.1:22022/mcp \
--header "Authorization: Bearer "
Prebuilt installers are on the releases page (Windows x64 / ARM64, macOS Apple Silicon). They are not code-signed, so SmartScreen and Gatekeeper will both stop you the first time.
Every operation, yours and the agent's, lands in one band. You do not have to ask what it did.
![The activity band: one line per operation, with [AI] marking the agent's](site/shots/en/band.png)
When something fails, the same log the agent reads over MCP is on your screen — which stage it reached, why it stopped, and what to do next. It carries no hostnames, no usernames and no secrets.
There are services still running on ordinary shared hosting and VPSes. Maintain one of those *with* an AI agent and this happens every single time:
you : I want to fix this service's config
AI : I can't see the server, so please tell me its state you : (open a terminal, look, paste) AI : now show me that config file too you : (open SFTP, download, paste)
This tool exists to delete that round trip. The agent does not need to *operate* your server. Letting it see is enough.
This is not a tool you drive by clicking buttons. You talk to an AI agent in your terminal, and the agent calls sshboard's built-in MCP server.
you → the AI agent in your terminal: "mail isn't arriving. look into it"
│ │ MCP (inside the app — no extra process) ▼ sshboard ── one SSH ──▶ server │ (sftp / exec) ▼ an [AI] line scrolls past in sshboard's window ── you are just watching. what it read and what it typed is visible as it happens
[Human] $ cd /var/www [AI] $ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 38G 10G 80% / [AI] read /etc/postfix/main.cf (4.1 KB)
You are not restricted. The two-pane file browser and the terminal tab work like any other SFTP client and terminal. Only the agent's side is fenced.
list_connections / list_directory / stat / read_file / search / download / disk_usage / process_list / service_status / runtime_versions / read_log / network_listen / run_readonly (allowlist) / list_checks / run_check / propose_check (health checks)
There is no `run_command(cmd)`. One such tool does everything, and once you have it the only thing standing between an agent and a destructive command is a promise not to use it. A promise is a runbook, not a gate.
With run_readonly the agent may pass only an id that a person wrote into `readonly.toml`. There is no argument slot. The list ships empty — until you write it, nothing runs at all. Refusals show up in the window's activity band and are recorded in readonly-refused.log. Adding entries is a person's job.
The agent stops saying "please tell me the state of the server."
Not downloads, not stars. Whether the round trip disappeared during real maintenance.
┌──────────┬──────────┐ ┌──────────┐
│ files │ terminal │ │ MCP │ │ two-pane │ tab │ │ │ └────┬─────┴────┬─────┘ └────┬─────┘ └──────────┴───────┬───────────┘ ▼ ┌────────────────────────┐ │ Operation Engine │ ← exactly one implementation lives here └───────────┬────────────┘ ▼ one SSH connection (sftp / exec)
We do not keep two SFTP implementations, and we never open an SSH session you cannot see. Being invisible is the single biggest danger here.
Whoever touched what flows into the same band. Different surfaces, one record.
[Human] $ cd /var/www
[AI] $ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 38G 10G 80% / [AI] read /etc/postfix/main.cf (4.1 KB)
No writes at all. Every intended use — incident triage, mail-config investigation, writing up a proposal — is reading. That makes the risk close to zero, which means you can point it at a live production server on day one.
run_command(cmd)Put one arbitrary-command tool in place and it can do everything. That is exactly why it does not exist.
readonly.toml looks like (a person writes it)version = 1
[[command]] id = "uptime" # the only value the agent may pass run = "uptime" # what actually runs. exactly what a person wrote description = "how long it has been up"
The product ships with zero entries. Nobody has the list of what real maintenance needs, and filling it in by guesswork gets it wrong. Refused calls pile up in readonly-refused.log — read that, and add only what was genuinely needed.
What this cannot verify: whether the run you wrote is truly read-only. The product cannot know. No machine can tell uptime from rm -rf / by inspection. What this prevents is exactly one thing: the agent composing a command string.
The human side (the GUI) is not restricted. Use it as an ordinary SFTP client and terminal. Only the agent's side is fenced.
checks.toml)Group the things you look at in the same order every time — disk, memory, a service, a listening port — into one check. Write it once; a person runs it from the menu (Checks → Run) and an agent runs the same check with run_check.
contains) / absent (absent), a number below / above a limitpropose_check. Every step and criterion appears on screen, and only the person can save it (saving runs nothing)A template lives in docs/checks.example.toml.
operations.toml)The list ships empty. Until you write this file, the agent can run nothing.
This is a separate file from the read allowlist (readonly.toml), so that write operations never live in a file called readonly. Telling them apart by name is the point. Put it next to connections.toml.
version = 1
[[operation]] id = "restart-httpd" run = "sudo systemctl restart httpd" description = "restart Apache" max_per_hour = 3
| field | what to write |
|---|---|
id | the only thing the agent may pass. Short, readable |
run | what actually gets typed. The agent cannot compose it |
description | shown on the approval dialog. Words you will understand in six months |
max_per_hour | hourly ceiling. `0` is rejected (there has to be a place it stops) |
become = "ask", the password is dropped here tooA person at the screen does not pass 3–5. They are looking at it. The one exception is the `become = "ask"` password — that is not approval, it is a credential, and the product cannot invent it.
No setting enables these. They are rejected even when present in operations.toml.
sudoers / visudo / authorized_keys.ssh / `id_rs앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요