jshookmcp: A Search-First MCP Server for JavaScript Reverse Engineering
js hook toolkit that all you need
At a glance
- What is it?
- jshookmcp bundles browser hooking, network interception, WASM disassembly and native instrumentation behind one MCP server, with a search profile that loads about 3K tokens of tool metadata instead of all 723 schemas. The design is unusual and the licence is AGPL-3.0, which decides most adoption questions before the feature list does.
- Who is it for?
- Adopt jshookmcp if you are doing front-end reverse engineering, deobfuscation or traffic analysis and you already run an MCP-capable agent, and if AGPL-3.0 is compatible with how you distribute your own work. Do not adopt it if you need a published npm package (the README's npm badge is commented out), if you need a stable versioned release surface, or if you only need to drive a browser, where Playwright's smaller API is easier to reason about.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The schema flood problem jshookmcp is built around
An MCP server that exposes hundreds of tools has a cost problem before it has a capability problem. Every tool schema the client loads consumes context that the model needs for the actual task. jshookmcp states the numbers directly: the search profile loads about 3K tokens of tool metadata, while the full profile exposes all 723 tools at around 40K tokens. That gap is the project's central design claim. The README describes the intended progression as search, then workflow, then full, so an agent starts cheap and widens its own surface as the task demands. The audience is narrow and specific: someone using an MCP-capable agent to reverse engineer JavaScript, inspect network traffic, disassemble WASM, or instrument a native process. If you are not running an agent that speaks MCP, the 723 tools are just an unusually large API you have to call by hand.
How the search profile, domains and recovery layer fit together
The README describes 34 self-discovered domains, each contributing tools that the server registers at startup. On top of that registry sit schema-first meta tools: describe_tool, call_tool with argument validation, coverage_report and search_tools. The search profile exposes the meta tools plus a ranked index rather than the full registry, and the README says ranking uses BM25 with hybrid vector search. An agent that wants a capability calls search_tools, gets back matching tool names, calls describe_tool for the schema, then call_tool to execute. That is a two-step indirection compared with a client that already holds every schema. The payoff is the token difference above; the cost is an extra round trip per capability discovery. The README also documents a runtime recovery layer: Streamable HTTP sessions restore activated domains, browser attach state and coverage state after reconnects, and per-client browser-side state stays isolated so two agents cannot trample each other's CDP sessions. That isolation matters because CDP attach is stateful. Two agents sharing one browser target will fight over the same session unless the server partitions it, and the README claims jshookmcp does.
The capability surface is wider than the MCP framing suggests
The capability table lists browser automation (Chromium and Camoufox via CDP, anti-detection presets, an explicit-input CAPTCHA solver, popup, download, permission and protocol interceptors), network interception (HTTP/1.1 and HTTP/2 frame building, a MITM proxy with an auto-generated CA, WebSocket capture, GraphQL introspection helpers, a Burp Suite bridge), JS analysis (deobfuscation, crypto routine detection, AST comprehension, source-map reconstruction, script extraction and replay), WASM work via Binaryen, process and memory forensics (native FFI scanning, hardware breakpoints, PE introspection, memory read/write with region guards), binary instrumentation bridges to Frida, Ghidra and IDA, and encoding transforms. The breadth is the point and also the risk. Every one of those areas has its own failure modes, and the README does not document per-area maturity. A tool that wraps Binaryen and a tool that wraps a Ghidra bridge are not the same kind of commitment. Treat the table as a map of what exists, not as evidence that each entry is equally finished.
Getting it running from source
There is no published npm package. The README's npm badge is commented out with the note that it should be re-added once @jshookmcp/jshook is published, so installation is from source. The badges state Node.js 22.22.2+ or 24.15+ and pnpm 10.x. The README's build section is titled Build from source, and the repository layout implies the usual pnpm sequence: pnpm install, then pnpm build, then pnpm start. The README does not spell out the exact scripts in the material provided, so confirm them in package.json before relying on those names. Configuration is documented at the project's configuration guide, and the transport section covers deployment modes, including Streamable HTTP, which is the transport tied to the session recovery behaviour described above. TypeScript is compiled in strict mode, which matters if you intend to write plugins: the extension registry supports hot-reload plugins, declarative workflows and auto-discovered domains, so extending the server means writing code that satisfies the same strict compiler settings.
The AGPL-3.0 licence decides more than the feature list
The licence is AGPL-3.0, and that is the constraint most likely to end an evaluation early. AGPL obligations attach to network use, not just distribution, so if you run a modified jshookmcp as part of a service other people interact with, the licence's source-availability terms are the question your legal team will ask about. This is not legal advice, and the exact scope depends on how you deploy it. The practical point is that jshookmcp is a poor fit for embedding in a closed product, and a good fit for internal tooling, research and security work where publishing modifications is acceptable. The README also shows a sponsor placement for a residential proxy vendor with a discount code, which is a reminder that the project is maintained with commercial support around it rather than by a foundation. Budget for reading the licence text before you budget for integration work.
Where the search-first approach breaks down
The search profile is only as good as its ranking. The README states BM25 plus hybrid vector ranking but does not publish an evaluation, so whether search_tools surfaces the right tool for a vague query is something you have to check against your own targets. A second limitation is the indirection itself: an agent that already knows which tool it wants pays an extra discovery step on every call, and a task that touches twenty tools pays it twenty times. The full profile removes that cost at roughly 40K tokens of schema, which is a large fixed price for a single session. There is also no release history in the material provided. The repository shows no retrieved releases, and the npm package is unpublished, so there is no versioned artifact to pin and no changelog to read before upgrading. For a project whose surface includes a MITM CA, hardware breakpoints and native FFI scanning, that absence of a release trail is the thing I would weigh most heavily. It does not mean the code is unstable; it means you cannot tell stability from the outside.
What it replaces, and what that difference actually costs
The obvious alternative for the browser half is Playwright. Playwright gives you a documented, versioned API for navigation, network interception and page scripting, and it is designed for testing and automation rather than for reverse engineering. The difference in approach is the tool surface. Playwright exposes a small, stable set of primitives you compose yourself; jshookmcp exposes 723 pre-built tools across 34 domains and expects an agent to find them by search. If your task is driving a page through a known flow, Playwright's smaller API is easier to reason about and easier to pin to a version. If your task is figuring out what an obfuscated bundle does, or where a WASM module reads its key, jshookmcp's surface covers ground Playwright does not attempt. The honest comparison is not which is better but which failure mode you can tolerate: a missing primitive you have to build, or a tool registry you have to search.
Maintenance cost and who should actually install it
Because there is no published package and no retrieved release, upgrades mean pulling the master branch, running pnpm install and pnpm build again, and re-checking that your plugins still compile under strict TypeScript. The hot-reload plugin system softens that for extensions but not for the core. Node version requirements are tight (22.22.2+ or 24.15+), so your CI image needs to match. Adopt jshookmcp if you do front-end reverse engineering, deobfuscation or traffic analysis with an MCP-capable agent, and if AGPL-3.0 fits how you ship. Skip it if you need a versioned package, if you only need browser automation, or if you cannot accept AGPL network-use terms. Verify first that the build succeeds on your Node version, that search_tools returns sensible results for queries phrased the way your agent phrases them, and that the MITM CA and hardware breakpoint paths behave on your target platform, since the README describes those capabilities without documenting platform coverage.
Editorial conclusion
Adopt jshookmcp if you are doing front-end reverse engineering, deobfuscation or traffic analysis and you already run an MCP-capable agent, and if AGPL-3.0 is compatible with how you distribute your own work. Do not adopt it if you need a published npm package (the README's npm badge is commented out), if you need a stable versioned release surface, or if you only need to drive a browser, where Playwright's smaller API is easier to reason about. Verify first that pnpm build and pnpm start succeed on Node 22.22.2 or 24.15, and that the search profile returns usable rankings on your own target, because the README does not document evaluation results for that ranking.
Community notes