
1. JADX MCP 是什么为什么要把 endpoint 改到 TaoTokenJADX MCP 是一套把 JADX 反编译能力包装成 MCP 工具的开源方案全称 JADX-AI-MCP。它由两部分组成装在 JADX-GUI 里的 Java 插件负责在 GUI 进程内起一个 HTTP 服务把当前打开工程的类、方法、资源、AndroidManifest 暴露成 REST 接口以及一个独立的 Python MCP Server用 FastMCP 把这些 HTTP 接口再包装成标准 MCP 工具供 Cursor、Claude Desktop 这类支持 MCP 的客户端调用。简单说它让你能在对话里直接“问”当前 JADX 里打开的 APK这个类干什么、Manifest 里注册了哪些组件、某个方法被谁引用。它适合谁做 Android 逆向、加固识别、漏洞分析、代码解读的开发者尤其是已经在用 AI 辅助审计、希望把反编译结果直接喂给模型的人。传统做法是手动导出代码再贴进对话上下文一长就乱JADX MCP 把“当前工程”变成可调用的工具集AI 能按需拉取不用你复制粘贴。那为什么要把 MCP endpoint 改到 TaoToken因为 MCP 客户端本身只负责“调用工具”真正做推理、生成分析结论的是背后的模型服务。默认情况下很多客户端会走各自的模型通道配置分散、切换麻烦、额度也各管各的。把模型请求统一指向 TaoToken 的 API 端点后你只需要维护一份 Base URL 和 KeyJADX MCP 负责取数据TaoToken 负责模型推理两边职责清晰。对于需要长期跑逆向分析、频繁调用工具的开发者这种统一通道能省掉大量重复配置。这里要区分两个“endpoint”别搞混一个是 JADX 插件和 Python MCP Server 之间的本地 HTTP 地址默认http://127.0.0.1:8650这个不动另一个是 MCP 客户端背后调用的模型 API 地址也就是我们要改到 TaoToken 的那个。本文重点讲后者同时把前者的部署和验证一并说清楚因为模型通道通了、本地桥接没通一样报错。我试过在 Cursor 里配 JADX MCP最开始的坑就是以为配好 MCP Server 就完事结果模型侧还在走默认通道工具能列出但一调用就超时。后来把模型 endpoint 统一到 TaoToken本地插件端口对齐整条链路才稳定。下面按“原理 → 前置 → 配置 → 验证 → 排错 → 分流”的顺序展开每一步都给可复制的片段。2. TaoToken 前置准备Key、Base URL 与模型 ID 三件套在动 JADX MCP 之前先把 TaoToken 侧的东西备齐。任何 MCP 客户端要调用模型本质上都需要三样Base URL、API Key、Model ID。这三件套缺一不可而且要和客户端配置里的字段一一对应写错一个就是 401 或 model not found。Base URL 用https://taotoken.net/api注意这里不加任何查询参数就是纯 API 根路径。API Key 在控制台的 API Keys 页面创建建议按用途分开建比如给 JADX 分析单独建一个方便后面按 Key 排查额度。Model ID 按你实际要用的模型填客户端里通常叫model或modelId填错会直接报模型不存在。创建 Key 的入口在控制台登录后进 API Keys 页面新建即可。拿到 Key 后先别急着往 JADX 配置里塞建议先用一条最简请求验证 Key 本身可用避免后面把“Key 无效”误判成“MCP 配置错”。验证方式可以用 curl也可以用模型对话页面直接发一句话看是否返回。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: 你的模型ID, messages: [{role: user, content: ping}] }如果这条返回正常说明 Key 和 Base URL 没问题问题就锁定在 MCP 客户端或 JADX 本地桥接上。这一步很关键排错时能帮你快速二分定位。关于模型选择逆向分析场景通常需要较强的代码理解和长上下文能力因为一个类的反编译结果加上引用链可能很长。你可以先在模型对话页面里试几个模型看哪个在代码问答上更稳再把它写进 MCP 客户端配置。Coding Plan 更适合长期、高频的编码与 Agent 场景如果你打算把 JADX MCP 当成日常审计工具可以考虑走这条通道额度管理更省心。还有一点TaoToken 是统一的模型接入通道不是替代 JADX 或编辑器的工具。JADX 负责反编译MCP Server 负责协议转换TaoToken 负责模型推理三者各司其职。别指望配了 TaoToken 就能自动分析 APK工具调用链还是得靠 MCP 串起来。准备好这三件套后再往下走部署。顺序建议是先装 JADX 插件 → 再跑 Python MCP Server → 最后配客户端并把模型 endpoint 指向 TaoToken。这样每步都能单独验证出问题好定位。3. 可复制配置JADX 插件、MCP Server 与客户端 settings 片段这一节给可直接复制的配置。先明确目录结构以 JADX 安装根目录为例插件 jar 和 Python 服务端分开放jadx-1.5.3/ ├── bin/ │ ├── jadx │ └── jadx-gui ├── lib/ │ └── jadx-*-all.jar ├── jadx-ai-mcp-6.2.0.jar ├── jadx-mcp-server/ │ ├── jadx_mcp_server.py │ ├── requirements.txt │ └── src/ │ └── server/ │ ├── config.py │ └── tools/ └── .mcp.json第一步安装 JADX 插件。下载jadx-ai-mcp-version.jar后在 JADX 安装目录执行./bin/jadx plugins --install-jar /path/to/jadx-ai-mcp-6.2.0.jar成功会提示Plugin installed: jadx-ai-mcp:null。也可以走 JADX-GUI 的插件管理界面安装。装完启动 JADX-GUI 并打开 APK插件会在 GUI 内起 HTTP 服务默认端口 8650可在插件设置里改。第二步部署 Python MCP Server。解压jadx-mcp-server-version.zip进入目录用 uv 运行cd jadx-mcp-server uv run jadx_mcp_server.py如果插件端口不是 8650加参数对齐uv run jadx_mcp_server.py --jadx-port 8652第三步配置 MCP 客户端。以 Cursor 为例编辑~/.cursor/mcp.json加入 server 条目。这里的关键是把模型 endpoint 指向 TaoToken同时保留 JADX MCP Server 的 stdio 启动方式{ mcpServers: { jadx-mcp-server: { command: /path/to/uv, args: [ --directory, /path/to/jadx-mcp-server, run, jadx_mcp_server.py ], env: { OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: 你的TaoTokenKey, OPENAI_MODEL: 你的模型ID } } } }command填本机 uv 可执行文件的绝对路径--directory必须是 jadx-mcp-server 所在目录的绝对路径。env里的三个变量就是前面说的三件套Base URL 用https://taotoken.net/apiKey 和 Model ID 按实际填。如果你的客户端用的是别的环境变量名比如ANTHROPIC_BASE_URL或OPENAI_API_BASE按客户端文档替换键名值不变。如果客户端支持 TOML 配置等价写法如下[mcp_servers.jadx-mcp-server] command /path/to/uv args [--directory, /path/to/jadx-mcp-server, run, jadx_mcp_server.py] [mcp_servers.jadx-mcp-server.env] OPENAI_BASE_URL https://taotoken.net/api OPENAI_API_KEY 你的TaoTokenKey OPENAI_MODEL 你的模型ID对于 Claude Code 这类走settings.json的客户端把模型通道配置写进对应字段Base URL 同样指向 TaoTokenKey 用同一个。如果你用的是 Codex 的auth.json结构不同但三件套一致Base URL、Key、Model ID 都要写全缺一个就会在调用时报认证或模型错误。保存后重启客户端或重新加载 MCP让配置生效。此时客户端会启动 jadx-mcp-server 进程并通过 stdio 交换 MCP 消息模型请求则走 TaoToken 的 API 端点。两条链路独立排错时分开看。4. 验证请求与成功结果从工具列表到 Manifest 拉取配置写完必须验证否则你不知道是模型通道没通还是 JADX 本地桥接没通。验证分三层模型通道、MCP Server 启动、工具实际调用。第一层验证 TaoToken 模型通道。用第 2 节的 curl 再跑一次确认返回正常。这一步过了说明 Base URL 和 Key 没问题。第二层验证 MCP Server 能启动。在终端手动跑cd jadx-mcp-server uv run jadx_mcp_server.py --jadx-port 8650如果依赖缺失uv 会自动拉取 fastmcp、httpx 等。启动后应该看到服务在 stdio 模式等待客户端连接。此时如果 JADX-GUI 没开或没打开工程后面工具调用会报连接失败所以先确保 JADX-GUI 已启动并加载了目标 APK。第三层在客户端里实际调用工具。重启 Cursor 后在对话里请求“用 JADX MCP 获取当前工程的 AndroidManifest”。如果一切正常AI 会调用get_android_manifest工具返回 Manifest 内容。你也可以显式让它“列出所有类”对应get_all_classes。成功结果长这样工具调用有明确的返回Manifest 里能看到 package、activity、permission 等节点类列表能列出反编译后的类名。如果返回的是超时或连接拒绝说明 Python MCP Server 没连上 JADX 插件的 HTTP 端口检查端口是否对齐、JADX-GUI 是否真的打开了工程。再验证一个搜索类工具比如“搜索名字里带 Network 的类”对应search_classes_by_keyword。返回结果里应该有匹配的类名和路径。这一步能确认插件到 JADX API 的链路是通的不只是 Manifest 这种静态资源。如果客户端里工具列表压根没出现 jadx-mcp-server说明 MCP 配置没被加载。检查mcp.json的 JSON 语法、路径是否正确、客户端是否重启。工具列表出现但调用报错则多半是本地桥接问题回到第二层排查。验证通过后你就有了一个可用的链路在对话里让 AI 拉取当前 JADX 工程的类、方法、Manifest、引用关系模型推理走 TaoToken。接下来是排错把常见报错对照清楚。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth排错的核心是分清报错属于哪条链路。模型链路报错通常是 401、模型不存在、额度问题本地桥接链路报错通常是连接拒绝、超时、端口不对客户端链路报错则是工具不出现、OAuth 失败。401 Unauthorized 最常见。原因一般是 Key 写错、Key 前后有空格、或者 Base URL 写成了带路径的形式。检查env里的OPENAI_API_KEY是否和 TaoToken 控制台里的一致Base URL 是否是https://taotoken.net/api不要多加/v1之外的路径。如果客户端默认会拼/v1/chat/completionsBase URL 就填到/api为止。local proxy failed 这类报错通常出现在客户端尝试走本地代理或本地模型服务时。如果你没配本地代理检查客户端里是否有残留的代理设置或者环境变量里有没有指向本地端口的配置。把模型通道统一到 TaoToken 后这类报错应该消失如果还在说明客户端某处仍在走旧配置逐项核对env和客户端全局设置。reading choices 报错一般发生在解析模型返回时返回结构不符合预期。常见原因是 Model ID 填错或者 Base URL 指向了一个不兼容 OpenAI 格式的端点。确认 Model ID 是 TaoToken 支持的模型Base URL 用标准 API 根路径。如果返回体里没有choices字段多半是端点或模型不对。OAuth 相关报错出现在 Claude Code 这类走 OAuth 流程的客户端。如果你用的是 API Key 模式确保没有同时启用 OAuth 登录两者会冲突。检查settings.json里模型通道配置是否覆盖了默认的 OAuth 端点Base URL 指向 TaoTokenKey 用 API Key。如果客户端强制走 OAuth需要在配置里显式指定 API Key 模式。还有一类是工具调用超时但模型通道正常。这通常是 JADX 插件端口和 MCP Server 的--jadx-port不一致或者 JADX-GUI 没打开工程。检查插件设置里的端口和启动命令里的参数对齐。另外JADX-GUI 重启后插件服务有时需要重新加载工程才恢复这也是为什么有人反馈“服务重启后很难连上”。遇到这种情况先确认 JADX-GUI 里工程是打开状态再重启 MCP Server。如果排查半天还是不稳一个务实的替代方案是用 JADX 把工程导出到磁盘再把导出目录交给客户端做静态分析。这样绕开本地 HTTP 桥接链路更简单适合对实时性要求不高的场景。等本地桥接稳定了再切回 MCP 工具调用。6. 把通道固定下来长期使用与 CTA 分流链路跑通后建议把配置固定成一份可复用的模板避免每次换项目重配。核心就是三件套加本地端口Base URL 固定https://taotoken.net/apiKey 按用途分Model ID 按场景选JADX 插件端口和 MCP Server 参数保持一致。把这份模板存进版本管理或团队文档新人接手直接改路径和 Key 就能用。长期跑逆向分析、频繁调用 MCP 工具的可以走 Coding Plan额度管理更集中适合把 JADX MCP 当日常审计工具的场景。只是偶尔验证模型效果的用模型对话页面先试模型确认代码理解能力后再写进配置。需要创建和管理 Key 的进 API Keys 页面按用途分开建方便按 Key 排查。接入文档里有各客户端的配置示例遇到字段名不一致时对照着改。排错和接入相关的问题优先看 API Keys 和接入文档验证模型能力用模型对话长期编码和 Agent 场景走 Coding Plan。把这几条分流记住后面换客户端或换项目时改的只是路径和 Key通道本身不用动。最后留一个实用习惯每次改完配置先用 curl 验证模型通道再手动启动一次 MCP Server 看日志最后在客户端里调一个get_android_manifest确认端到端通。三步都过再开始正式分析。这样能把问题挡在分析之前省掉大量来回折腾。