What it takes off you is the context cost of breadth. Eight definitions stay resident on the search profile and everything else is pulled in when a task calls for it, then dropped — and the router answers is there something for this instead of leaving the model to guess.
A dynamic tool layer for JavaScript analysis and security research — browser automation and CDP debugging, network interception, JS hooks, WASM and binary work, process and memory inspection. The catalog spans dozens of capability domains, none of them resident: you search or route to what a task needs, activate it, and remove it again afterwards.
- The catalog searched by query, with the option to activate what matches
- A task described in words routed to recommended tools, in activation order, with example arguments
- One tool's full input schema read before you call it
- Tools registered by name, or a whole domain at once with a time limit on it
- Activated tools removed again to free context
- An already-active tool called by name, for clients that did not refresh their tool list
- A report of which tools have been called this run and which have not
- Domains covering browser and debugger work, network, proxy and GraphQL capture, memory, process and syscall inspection, WASM, WebGPU, sourcemaps, encoding and AST transforms
- A resident set you choose: MCP_TOOL_PROFILE=search keeps only these eight meta tools loaded, and the workflow and full profiles start with progressively more
Node.js 22.12 or newer and npx on your PATH. The published quick start sets MCP_TOOL_PROFILE=search and npm_config_omit=optional, which skips the optional ONNX, Z3, Binaryen, Camoufox and Playwright packages — drop npm_config_omit when you need the browser and analysis runtimes those provide. The catalog is not resident, so a tool has to be found and activated before it can be called; call_tool does not activate anything by itself.
One command — npx -y @jshookmcp/jshook@latest