jadx-ai-mcp：把 JADX 的靜態分析結果接進 MCP 的橋接插件

它解決的是反編譯結果搬運的問題，不是反編譯本身

JADX 本身已經能把 DEX 轉成可讀的 Java 原始碼，這件事不需要 LLM。真正耗時的是下一步：分析者要在數千個類別之間跳轉，找出可疑的加密常數、硬編碼憑證、不安全的 WebView 設定，然後把相關片段一段一段貼進對話視窗。貼上的過程會遺失上下文，模型看不到呼叫端，也看不到同一個類別裡其他方法。

jadx-ai-mcp 的定位就在這個缺口。README 把它描述為「a plugin for the JADX decompiler that integrates directly with Model Context Protocol (MCP)」，並以「live reverse engineering support with LLMs like Claude」說明用途。關鍵字是 live：模型查詢的是 JADX 當前已載入的專案狀態，而不是一份靜態快照。

目標使用者相當明確，是做 Android APK 靜態分析的人：行動應用滲透測試、VAPT 委外案件、以及把 SAST 工具結果做二次確認的安全工程師。這些人本來就開著 JADX，插件降低的是他們在工具與模型之間來回搬運的成本。若你只是偶爾解一個 APK 看 manifest，這個整合帶來的效益有限。

MCP 伺服器與 JADX 插件是兩個要分別處理的元件

從 repository 名稱與 README 的徽章可以讀出一個容易誤解的架構：這個 repo 是插件端，另外還有一個 jadx-mcp-server 專案負責 MCP 伺服器。README 的徽章同時連到 jadx-ai-mcp 與 jadx-mcp-server 兩個 repository 的貢獻者統計，說明兩者是分開發佈的。

資料流大致是：JADX 載入 APK 並完成反編譯，插件在 JADX 內暴露查詢能力，MCP 伺服器把這些能力包成 MCP 工具，LLM 客戶端再透過 MCP 協定呼叫。模型不會自己去解析 DEX，它拿到的是 JADX 已經算好的結果。

這個分層有實際後果。插件與伺服器版本必須對得上，否則工具呼叫會失敗；而 README 的徽章標示 Java 11+ 與 Python 3.10+，暗示插件端是 Java、伺服器端是 Python。當你排查問題時，要先確定故障發生在 JADX 插件、MCP 伺服器，還是模型客戶端這一層。把三者當成單一黑箱會讓除錯變得沒有方向。

v6.3.0 的遠端主機支援改變了部署拓撲

release 記錄裡有三個版本值得注意。v6.3.0 標題是 Remote Host Support，v6.4.0 標題是 Search Infrastructure Overhauled，最新的 V6.4.1 則沒有附上說明。這三筆資訊本身就是判斷依據。

遠端主機支援意味著 JADX 不必和 MCP 伺服器跑在同一台機器上。這在實務上有兩種用法：一是把反編譯環境放在隔離的 VM 或容器裡，模型客戶端留在工作機；二是多人共用一台分析主機。兩種用法都改變了威脅模型，因為反編譯內容會跨網路傳輸。

v6.4.0 對搜尋基礎設施做了整體翻修，這通常代表工具呼叫的查詢介面有變動。如果你的流程依賴特定搜尋行為，升級前應該先確認工具名稱與參數是否沿用。

至於 V6.4.1，release 記錄沒有提供變更說明，我無法從現有材料判斷它修了什麼。這種情況下最保守的做法是把它當成未記載的變更，先在非正式環境驗證再推到正式流程。

安裝路徑與版本前提

README 的徽章給出兩個硬性前提：Java 11+ 與 Python 3.10+。這兩個數字應該當成最低門檻，而不是建議值。

關於安裝方式，README 有一段被註解掉的說明，提到這是「Standalone Plugin for JADX (Started as Fork)」。這句話有兩層意思：它曾經是 JADX 的分支，後來成為獨立插件；而 repository 的預設分支是 jadx-ai，不是常見的 main 或 master。從原始碼建置或取用時要留意分支名稱，直接假設 main 會拿不到東西。

README 也指向一份獨立文件：https://jadx-ai-mcp.readthedocs.io/en/latest/。具體的安裝指令、MCP 客戶端設定檔內容與工具清單並沒有寫在 README 本文裡，需要以 Read the Docs 為準。我沒有實際安裝或執行這個專案，因此不在這裡編造指令或設定鍵；請以官方文件為唯一依據。

有一點可以從 README 的註解確認：專案自己標註「It is a still in early stage of development, so expects bugs, crashes and logical erros.」。這句話出現在 README 原始碼的註解中，不是給一般讀者看的段落，但它反映了維護者對穩定性的自我評估。

把反編譯內容交給外部模型的代價

這個插件最大的限制不在技術，而在資料流向。使用它意味著 APK 的反編譯結果會經過 MCP 伺服器送到 LLM 端點。對於受託分析第三方應用、或處理客戶交付 APK 的團隊，這是一個必須先過的合規關卡，而不是安裝後再想的問題。

v6.3.0 的遠端主機支援讓這個問題更明顯。當 JADX 與 MCP 伺服器分處不同主機，反編譯內容會多經過一段網路路徑。這在內部網路可能無所謂，但若分析環境與模型端點之間跨越信任邊界，就需要額外設計。

第二個限制是它綁定 JADX。JADX 對混淆過的程式碼、特別是控制流程平坦化或字串加密的樣本，輸出品質會下降。模型看到的是 JADX 的輸出，JADX 看不懂的地方，模型也看不懂。插件不會改善反編譯品質，它只是搬運。

第三個限制是它不適合當成自動化掃描器。README 把它定位在互動式的 reverse engineering support，這與 CI 裡跑批次掃描是兩種不同的工作模式。若你需要的是可重複、可回歸的掃描管線，這個工具的互動性質反而是阻礙。

與 Ghidra 加 LLM 腳本這條路線的差異

一個合理的替代方向是不用 MCP，改成在反編譯器裡寫腳本，把選定的函式或類別匯出成文字，再手動餵給模型。Ghidra 的 Python 或 Java script 就是這種做法，JADX 自己也有 API 可以寫插件。

兩者的差別在互動模式。腳本路線是批次、單向的：你決定要匯出什麼，跑一次，拿到檔案，貼給模型。模型無法追問「這個方法的呼叫端在哪裡」，除非你再跑一次腳本。MCP 路線是雙向的：模型可以依需求發起查詢，逐步縮小範圍。

代價是複雜度。腳本路線只需要一個反編譯器和一個文字編輯器，沒有伺服器要啟動，沒有版本要對齊，也沒有網路連線要維護。MCP 路線多了插件、伺服器、客戶端三層，任何一層版本不合就停擺。

如果你的分析是「先鎖定幾個可疑類別，再深挖」，腳本路線通常夠用且更輕。如果你的分析需要在數百個類別之間反覆跳轉、讓模型自己決定下一步看哪裡，MCP 的互動性才值得那三層複雜度。這不是哪個比較好的問題，是工作模式匹不匹配的問題。

授權與後續維護的實際考量

專案採用 Apache-2.0。這是一個寬鬆授權，允許修改與再散布，也包含專利授權條款。對企業內部使用而言，這個授權通常不會構成障礙。但要注意的是，這個插件依賴 JADX，而 JADX 本身的授權條款需要另外確認；把兩者打包進產品時，要分別檢視各自的條款。這裡不構成法律意見，涉及商業散布請洽法務。

維護成本主要來自版本對齊。從 release 節奏看，2026 年 3 月到 8 月之間出了 v6.3.0、v6.4.0、V6.4.1 三個版本，其中 v6.4.0 是搜尋基礎設施的整體翻修。這代表工具介面仍在變動，跟著升級需要重新驗證既有流程。

另一個變數是 MCP 協定本身。這個插件建立在 Model Context Protocol 之上，協定若有變更，插件與伺服器兩端都要跟。這部分不在這個專案的控制範圍內。

README 提到這是 Zin MCP Suite 的一部分。若你的環境還要用同系列其他工具，版本對齊的範圍會更大。

編輯結論

如果你已經在用 JADX 做 Android APK 的靜態分析，而且希望 LLM 直接讀取反編譯後的類別、方法與字串，而不是反覆複製貼上，這個插件值得在隔離環境試跑一次。若你的流程只依賴上游 skylot/jadx 的官方發行版、或團隊政策不允許把反編譯內容送往外部模型端點，它就不適合。導入前先確認三件事：你安裝的是插件版還是 README 所述的 JADX 分支，Java 版本是否達到 11 以上，以及 v6.3.0 引入的遠端主機支援是否符合你的網路隔離要求。

官方來源

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zinja-coder/jadx-ai-mcp on GitHub