js-reverse-mcp: an MCP server that turns Claude, Cursor or Copilot into a JS debugging analyst

The problem: an agent cannot debug what it cannot pause

A coding assistant can read a JavaScript file you paste into it. It cannot stop a page mid-request, inspect a call frame, pull the raw response body out of a binary WebSocket frame, and then decide what to do next. That gap is what js-reverse-mcp targets. The project describes itself as an AI-first JavaScript reverse engineering MCP server, and the README states the goal plainly: let an assistant open a page, get past bot checks, locate a script, save its source, set a breakpoint, trigger the behaviour, inspect the runtime, export network material, replay the state, and keep reasoning.

The audience is narrow and specific. You need an MCP client (Claude Code, Codex, Cursor or VS Code Copilot are the four the README configures), a local Chrome stable install, and a task where the interesting logic lives in code the page does not want you to read. If your job is writing application code, this is the wrong tool. If your job is understanding why a login flow produces a particular cookie, it is aimed at you.

Tool design: agent primitives instead of a DevTools menu

The README is explicit that the project does not hand the model a mirror of the Chrome DevTools API. Tools are described as agent primitives. Concretely, the README says list_network_requests can list indices, look up a single request by reqid, or write the exact material to disk via outputFile. evaluate_script runs in the page, runs inside a breakpoint call frame, and accepts a localFilePath input so the agent can feed a file back in rather than pasting it into the conversation.

That last point is the real architectural choice. Local files act as the analysis workbench. save_script_source, list_network_requests with outputFile, and evaluate_script with localFilePath let the agent move between browser, network and disk without pushing large source files or binary payloads through the chat context. The README also describes output shaping: list output stays short and scannable, detail output is bounded, long results suggest an export, and a pending request tells the agent to resume execution first instead of waiting for a response that will never arrive. That last detail is the kind of thing you only add after watching a model hang.

The README lists 24 tools, grouped under page and navigation, script analysis, breakpoints, network and WebSocket, and browser state. The truncated README does not enumerate all of them, so treat the tool surface as something to verify against your installed version rather than against this article.

Installing js-reverse-mcp and running a first breakpoint session

The README requires Node.js v20.19 or newer and Chrome stable. There is no install step for the npx path: you add the server to your MCP client config. This JSON block is the generic form the README gives for any MCP client.

{
  "mcpServers": {
    "js-reverse": {
      "command": "npx",
      "args": ["js-reverse-mcp"]
    }
  }
}

For Claude Code the README gives a single command instead of hand-editing config. Run it and the server is registered under the name js-reverse.

claude mcp add js-reverse npx js-reverse-mcp

Codex uses the same shape with a different binary, and VS Code Copilot takes the config inline. Cursor is configured through Cursor Settings, then MCP, then New MCP Server, using the JSON above.

codex mcp add js-reverse -- npx js-reverse-mcp

If you would rather run from source, the README's local install is a clone, npm install, npm run build, then pointing the MCP config at the built entry file with node. Note the path is build/src/index.js, not src/index.js, because the build script runs tsc into build/.

git clone https://github.com/zhizhuodemao/js-reverse-mcp.git
cd js-reverse-mcp
npm install
npm run build

Once the server is connected, the first useful session is a state replay. Ask the assistant to open the target page, list the loaded scripts, save the interesting one to disk with save_script_source, set a breakpoint, and then use clear_site_data followed by a reload. The README describes clear_site_data as clearing cookies, cache, storage and sessionStorage for the current site only, which is what makes cookie generation and risk-control flows repeatable. The browser opens headful by default, so you watch the page while the agent works, and the default profile keeps cookies and localStorage across sessions. The README does not document a rollback command for a session that goes wrong; --isolated gives you a throwaway clean environment instead.

Anti-detection is two layers, and only one of them is on by default

This is where the README is more careful than its own topic list suggests. The wrapper claims zero JS injection: no Object.defineProperty hacks, on the stated grounds that those are themselves a detection signal. Everything sits in two non-overlapping layers.

The protocol layer is on by default and comes from @zhizhuodemao/patchright, a fork the project maintains separately rather than depending on the public Patchright release. The README says the fork avoids calling Runtime.enable and Console.enable, evaluates in an isolated world, removes automation launch flags, and rebuilds against confirmed shared implementation fingerprints. The source layer is off by default: you run system Google Chrome. With --cloak you get the CloakBrowser binary, a custom Chromium build with source-level fingerprint patches covering navigator.webdriver, canvas, WebGL, audio, GPU, fonts, screen, WebRTC and TLS. The two modes also use physically separate profile directories, and the cloak profile has no Google services and no Web Store.

There are navigation-level measures in both modes: CDP silent navigation, where Network.enable and Debugger.enable are not activated during page load and collection goes through Playwright listeners until a tool explicitly needs CDP; a default referer of https://www.google.com/ on new_page; and a real viewport instead of Playwright's default 1280x720. The README is honest about the ceiling. It says the fork aims to reduce confirmed shared implementation fingerprints, not to promise that browser automation is undetectable. It also states that public documentation describes design boundaries only and does not publish internal detection samples. That is a reasonable stance, but it means you cannot audit the stealth claims from the repository alone, and the README does not document which sites have been tested.

Where it stops being the right tool

The README frames anti-detection as a supporting capability for the debugging loop, not as a general scraping framework, and that framing is the honest boundary. Three cases fall outside it.

First, headless pipelines. The default is headful Chrome with a persistent profile, and the README presents seeing the browser as a feature. If you need thousands of concurrent headless sessions, this is not the architecture you want. Second, pure HTTP work. If the target logic can be reproduced by replaying requests with a cookie jar, an MCP server driving a real Chrome is a heavy way to do it. Third, anything that depends on documented stealth guarantees. The README explicitly declines to promise undetectability and does not publish the detection samples, so you cannot derive a supported-site list from it.

There is also a maintenance surface to weigh. The default browser is your own Chrome stable install, so a Chrome update can change behaviour under the server without any change in js-reverse-mcp itself. The project ships its own Patchright fork, which means two repositories to track, and the README does not document a compatibility matrix between fork versions and Chrome versions.

How it differs from Chrome DevTools MCP

The closest comparison is Chrome DevTools MCP, which also exposes CDP-driven browser control to a model. The difference is in what gets shaped. A DevTools-derived server tends to surface the protocol's own surface: domains, events, commands. js-reverse-mcp reorganizes the same underlying capability around a reverse-engineering loop, and the README's own example is the telling one. list_network_requests is not a request lister; it is a lister, a by-reqid detail lookup and an exporter in one tool, because the agent needs all three in sequence. evaluate_script is not a page evaluator; it is a page evaluator, a call-frame evaluator and a file reader.

The second difference is the stealth layer. A stock DevTools bridge drives whatever browser you point it at with whatever flags you pass. js-reverse-mcp ships a maintained fork for the protocol layer and an optional binary for the source layer, and it separates the two profile directories so a cloak session does not contaminate your persistent login state. Whether that matters depends entirely on your targets. If your pages do not fingerprint, you are paying for a dependency you will not use.

The third difference is scope discipline. The README states that the anti-detection work exists so the agent can reach the page and keep analysing, not so the project becomes a crawler. That is a narrower promise than it sounds, and it is the right one for a debugging tool.

Licence, versioning and what upgrades cost

The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant; it also requires that you preserve notices and state changes. That is a summary of the identifier, not legal advice. Two practical points follow from it. Because the project depends on @zhizhuodemao/patchright and optionally on the CloakBrowser binary, your dependency review has to cover those too, and the README does not state their licences. CloakBrowser is a separate project under a different organisation.

On versioning, the releases given are v4.0.2 and v4.0.3 on 2026-08-20 and v4.0.5 on 2026-09-03. The last push to the repository was on 2026-09-03. The 4.0.x line moved three times in two weeks, which is a normal cadence for an actively developed project but a real cost if you pin loosely: the tool surface is the interface your prompts depend on, and the README's 24-tool list is the only published reference. The repository has a docs:check script that regenerates documentation and verifies it, which suggests tool documentation is generated from the build rather than hand-maintained, but the README does not say the published list is always current. Upgrade cost is mostly prompt churn and re-verifying which tools exist, plus re-testing your stealth assumptions after any Patchright fork bump.

Editorial conclusion

Adopt it if you already drive an MCP-capable coding assistant and your work is reading minified JavaScript, setting breakpoints and exporting raw request bodies from a headful Chrome you can watch. Skip it if you want a scraping framework, a headless pipeline or a server with a published tool reference beyond the two dozen entries in the README. Before you commit, read docs/cloak.md and confirm that --cloak is only meant for sites where the default protocol-layer stealth fails, then pin the version you install: v4.0.5 shipped on 2026-09-03 and the tool surface has moved across the 4.0.x line.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zhizhuodemao/js-reverse-mcp on GitHub