Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者による説明(英語の原文)
Reverse-engineering evidence from a running Windows process, not the binary on disk.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
リンク先は作者自身のファイルです。私たちが置いたり再パッケージしたりしたものではありません。ファイルを開くと、Claude Desktopがインストールします。
ターミナルでこれを実行します
ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月7日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント r0ptik で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(0.1.1)がレジストリに届いたのは3 か月前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにMCPBも必要です。
同じカテゴリには:Spec Driven Development, Remote Desktop Commander, Rystic
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況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.
Start, seed, clock, inspect and diff Rystic API simulators from your agent.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
English · 繁體中文 · 简体中文 · 日本語 · 한국어
**An MCP server that gives AI agents evidence from a *running* process.**
Every reverse-engineering MCP server so far bridges a *static* analyzer — Ghidra, IDA, apktool. They hand your agent the file on disk. None of them can tell the agent what the program is actually doing right now: what got decrypted into that buffer, which address the vtable slot resolved to at runtime, which call site sent that packet.
Argus is the other half. It attaches to a live Windows process and returns runtime evidence: real bytes at real addresses, disassembly of the code that actually executed, resolved IAT thunks, caller chains walked from live memory, and a hypothesis ledger that tracks what has been proven versus what is still a guess.
It does not draw conclusions for the model. It returns addresses, module/RVA context, instructions, callers, callees, and local evidence, then gets out of the way.
Games die. The publisher shuts the servers down, the studio folds, the genre moves on. What survives is a client sitting on somebody's hard drive that can no longer connect to anything — no source, no protocol documentation, no server left to talk to. Just an executable that still remembers how to speak a language nobody is listening to anymore.
Argus was built to bring those back.
Reconstructing a server for a dead game means recovering its protocol: packet layouts, encryption, opcode dispatch, the state machine on the other side of the wire. The only surviving specification is the client binary itself. Nobody wrote the document you need, and the people who knew have long since moved on.
Static analysis gets you partway. But a twenty-year-old client is packed, its strings are encrypted, its handlers dispatch through tables that only exist once the process is up. So you run it, and you watch it work — which is where the next section comes in.
That is what this tool is for: not breaking into something alive, but getting something dead to speak again.
A CPU cannot execute ciphertext.
Whatever a program does to protect itself on disk — packing, string encryption, virtualized instructions, imports resolved at load time — all of it has to be undone before the processor can run the code. At the instant of execution, the real instructions and the real data are sitting in memory in the clear. They have to be. That is not a flaw in any particular protector; it is a consequence of how processors work, and no amount of obfuscation gets around it.
So the two approaches are reading different things:
When those two differ, the second one is the truth.
| Situation | Static analyzer | Argus |
|---|---|---|
| Packed / self-decrypting code | sees the packer | disassembles the unpacked bytes in memory |
| Indirect call through a vtable | sees call [rax+0x18] | resolves the slot to a concrete target |
| Import resolved at runtime | sees a thunk stub | resolves the thunk to the real API |
| Buffer contents after decryption | nothing | reads the plaintext |
| Which of 40 call sites actually fires | guesses | records the one that ran |
The trade runs the other way too, and it is worth being blunt about it: a static analyzer sees *every* path, including the ones that never execute. Argus only sees what actually ran. A branch that was never taken leaves no runtime evidence at all, and a function nobody called may as well not exist.
Neither view is complete on its own. That is what correlate_addr is for — map a runtime address back to a module and RVA, look it up in Ghidra or IDA, and work with both halves. Argus is built to sit alongside a static analyzer, not to replace one.
Process and memory processes_list · processes_find · mem_attach · mem_modules · memory_regions mem_read · mem_read_chain · mem_write
Scanning scan_bytes · scan_string · scan_regex · scan_pointers_to · scan_callers scan_x86_call_sites · value_scan_start · value_scan_refine · value_explain · real_rate
Disassembly and structure recovery disasm_at · analyze_function · find_vtable · extract_dispatch_tables analyze_send_call_sites · read_struct · diff_struct
Import and API resolution runtime_imports · runtime_exports · resolve_iat_thunks · resolve_api_targets
Tracing and correlation trace_call_chain · correlate_addr · locate
Evidence ledger record_hypothesis · verify_hypothesis · query_hypotheses · add_evidence
Attaching a 64-bit analyzer to a 32-bit (WOW64) target is a classic source of silently wrong pointer arithmetic and garbage PE parsing. Argus ships a thin front-end, argus-router, which inspects the target process, determines whether it is x86 or x64, and dispatches to the matching argus-rs build. You configure one binary; the correct engine is selected per target.
Agents are good at producing plausible explanations and bad at noticing when a plausible explanation is unsupported. record_hypothesis / verify_hypothesis / add_evidence force the distinction: a claim is stored as a hypothesis, and only becomes an established fact when evidence is attached and verification passes. query_hypotheses lets a later session pick up where the previous one stopped without re-deriving everything.
Download the latest release and unpack it anywhere:
[Releases](https://github.com/r0ptik/argus/releases)
The archive contains argus-router.exe plus both engine builds (argus-rs-x64.exe, argus-rs-x86.exe). Keep them in the same directory.
Requires a Rust toolchain with both Windows targets installed:
rustup target add x86_64-pc-windows-msvc i686-pc-windows-msvc
git clone https://github.com/r0ptik/argus cd argus cargo build --release --target x86_64-pc-windows-msvc cargo build --release --target i686-pc-windows-msvc
claude mcp add argus -- C:\path\to\argus-router.exe
{
"mcpServers": { "argus": { "command": "C:\\path\\to\\argus-router.exe" } } }
Argus is a reverse-engineering and program-analysis tool. It is built for work such as game and server preservation, network protocol analysis, interoperability and clean-room reimplementation, malware analysis, crash and corruption debugging, and security research.
It is explicitly not built for attacking live services. No cheat features are accepted into this repository — see CONTRIBUTING.md.
It requires the ability to open and read another process, so use it only against processes you own or are authorized to analyze. Attaching to software you do not have permission to analyze may violate that software's terms or your local law. That is your responsibility, not the tool's.
Windows only. The memory access layer (argus-winmem) is built on the Win32 process and memory APIs; there is no Linux or macOS backend today.
Both x86 and x64 targets are supported, including 32-bit processes running under WOW64.
| Crate | Role |
|---|---|
argus-router | front-end binary; architecture detection and dispatch |
argus-rs | MCP server; tool definitions and request handling |
argus-engine | analysis engine; disassembly, structure recovery, tracing |
argus-winmem | Win32 process and memory access |
argus-scan | pattern and value scanning primitives |
evidence-core | address, module, RVA and evidence data models |
MIT. See LICENSE.