jshookmcp
Reverse-engineering workbench for web pages, JavaScript bundles, WASM, native processes and APKs
Debug and reverse-engineer a web page's JavaScript in a visible Chrome, with breakpoints and network capture
By Chen Shuai (individual) TypeScript Local · stdio Browser automationDeveloper tools
77 popularity score ★ 3.1k ↓ 1.2k/wk
Opens the app, which asks before it adds the server.
claude mcp add js-reverse -- npx js-reverse-mcp{
"mcpServers": {
"js-reverse": {
"command": "npx",
"args": [
"js-reverse-mcp"
]
}
}
}{
"mcpServers": {
"js-reverse": {
"command": "npx",
"args": [
"js-reverse-mcp"
]
}
}
}{
"servers": {
"js-reverse": {
"type": "stdio",
"command": "npx",
"args": [
"js-reverse-mcp"
]
}
}
}[mcp_servers.js-reverse]
command = "npx"
args = ["js-reverse-mcp"]gemini mcp add --scope user js-reverse npx -- js-reverse-mcpOpens the app, which asks before it adds the server. Then replace each <NAME> in its settings with your value.
git clone https://github.com/zhizhuodemao/js-reverse-mcp.git
cd js-reverse-mcp
npm install
npm run buildclaude mcp add js-reverse -- node '<ABSOLUTE_PATH_TO_CLONE>/build/src/index.js'{
"mcpServers": {
"js-reverse": {
"command": "node",
"args": [
"<ABSOLUTE_PATH_TO_CLONE>/build/src/index.js"
]
}
}
}{
"mcpServers": {
"js-reverse": {
"command": "node",
"args": [
"<ABSOLUTE_PATH_TO_CLONE>/build/src/index.js"
]
}
}
}{
"servers": {
"js-reverse": {
"type": "stdio",
"command": "node",
"args": [
"<ABSOLUTE_PATH_TO_CLONE>/build/src/index.js"
]
}
}
}[mcp_servers.js-reverse]
command = "node"
args = ["<ABSOLUTE_PATH_TO_CLONE>/build/src/index.js"]gemini mcp add --scope user js-reverse node -- '<ABSOLUTE_PATH_TO_CLONE>/build/src/index.js'JS Reverse MCP opens a visible Chrome window and hands an assistant the pieces of a JavaScript reverse-engineering session: list and search the scripts a page loaded, pull or save their source, set breakpoints by matching code text or by XHR/fetch URL, step through paused code and read scope variables, and evaluate expressions inside the paused call frame. It also records network requests with their JavaScript call stacks, groups WebSocket messages, and can wipe one site's cookies and storage so a cookie or bot-check flow can be replayed from a clean state.
Large material is meant to go to local files rather than into the chat: scripts, request bodies and headers can be exported, and evaluate_script can read one local file as input. By default it drives your installed Chrome through the maker's own Patchright fork, which avoids common automation tells at the protocol level; the --cloak flag swaps in the CloakBrowser Chromium build with fingerprint patches for sites that still block it. The profile persists logins between runs unless --isolated is given, and --browserUrl attaches to a Chrome you already started with a debugging port.
Version 4.0.5 registers 24 tools, matching the README. In the CLI source, --cloak is declared as conflicting with --browserUrl, so the stealth binary cannot be combined with attaching to an existing browser (src/cli.ts at v4.0.5); the CloakBrowser identity is kept per profile in a .cloak-seed file.
| Runtime | Node.js 20+ |
|---|
Node.js 20.19 or newer and the stable Google Chrome on your machine. The --cloak mode downloads a CloakBrowser binary of about 200 MB on first use (the docs suggest running npx cloakbrowser install beforehand); on macOS that ad-hoc-signed binary may be stopped by Gatekeeper at first launch. No account or API key is needed.
The maker states the anti-detection work reduces known automation signals but does not promise the browser is undetectable. Network and debugger capture stay off during the first page load, so the docs advise calling list_network_requests and then reloading to see every request. --cloak cannot be used together with --browserUrl. In --cloak mode on Linux and Windows the browser presents a Windows desktop fingerprint. --browserUrl takes only a CDP HTTP endpoint, not the private local APIs of fingerprint browsers such as AdsPower or BitBrowser.
Suits developers and security researchers who need to find how a site builds signed parameters, tokens or cookies and want the assistant to set breakpoints and inspect runtime state, not just script clicks. It runs entirely on your own machine with a visible browser. For plain page automation or testing without debugging, a general browser server is a lighter fit; set --allowedRoots before using it anywhere shared, since file access is otherwise unrestricted. Using its stealth features against a site may conflict with that site's terms.
select_pagenew_pagenavigate_pageselect_frameclick_elementtake_screenshotlist_scriptsget_script_sourcesave_script_sourcesearch_in_sourcesset_breakpoint_on_textbreak_on_xhrremove_breakpointlist_breakpointsget_paused_infopause_or_resumesteplist_network_requestsclear_network_requestsget_request_initiatorget_websocket_messagesclear_site_dataevaluate_scriptlist_console_messages