Which integrations are available for this server?

Enables OpenAI Codex to perform JavaScript reverse engineering through automatic deobfuscation, knowledge management, and evolution monitoring.

How do I use js-reverse-evolver?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@js-reverse-evolver deobfuscate https://example.com/script.js" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

js-reverse-evolver

by JiangtaoQu

Overview Schema Related Servers Score Discussions

TypeScript

Local

js-reverse-evolver

自进化 JS 逆向工作流 · MCP Server 集成 MemOS / GitNexus / Stagehand / js-reverse-mcp / Evolver，可在 Claude Code、Codex 等平台直接调用。

架构总览

js-reverse-mcp → SeedAdapter（获取初始种子代码）
        ↓
   EvolverEngine（核心进化引擎）
      ↙        ↘
GitNexusAdapter  StagehandAdapter（分支管理 / 浏览器验证）
      ↘        ↙
   MemOSAdapter（历史记忆读写）
        ↓
SelfLearner / StrategyEvolver（自学习 / 自扩展）

Related MCP server: JS Reverse MCP

快速开始

1. 安装依赖

cd /path/to/js-reverse-evolver
npm install
npx playwright install chromium

2. 配置环境变量

cp .env.example .env
# 编辑 .env，填入 MemOS / js-reverse-mcp 等服务地址

3. 构建 & 启动

npm run build
npm start

接入 MCP 平台

Claude Code

将以下内容添加到 Claude Code 的 MCP 配置文件（~/.claude/mcp_settings.json）：

{
  "mcpServers": {
    "js-reverse-evolver": {
      "command": "node",
      "args": ["/path/to/js-reverse-evolver/dist/index.js"]
    }
  }
}

OpenAI Codex / 其他 MCP 平台

将 .mcp/config.json 内容复制到对应平台的 MCP Server 配置中即可。

四个工具接口

工具名	功能
`evolve_js`	输入目标 URL，自动进化输出反混淆代码
`query_knowledge`	查询知识库中积累的模式与策略
`inject_knowledge`	人工注入混淆模式，增强进化能力
`get_evolution_status`	查询引擎当前状态与统计信息

自学习机制

每次进化成功后系统会自动：

提取本次成功的混淆特征 → 写入 knowledge/patterns.json
高频模式（命中 ≥3 次）自动晋升为新策略 → 写入 knowledge/strategy_candidates.json
下次启动自动加载新策略，越用越聪明

项目结构

js-reverse-evolver/
├── src/
│   ├── index.ts              # MCP Server 入口
│   ├── utils/
│   │   ├── config.ts         # 环境变量配置
│   │   └── logger.ts         # 日志工具
│   ├── evolver/
│   │   ├── types.ts          # 全局类型定义
│   │   ├── EvolverEngine.ts  # 核心进化引擎
│   │   └── strategies/
│   │       ├── BaseStrategy.ts
│   │       ├── MutateStrategy.ts
│   │       └── CrossStrategy.ts
│   ├── adapters/
│   │   ├── MemOSAdapter.ts
│   │   ├── GitNexusAdapter.ts
│   │   ├── StagehandAdapter.ts
│   │   └── SeedAdapter.ts
│   └── learning/
│       ├── KnowledgeStore.ts
│       ├── SelfLearner.ts
│       └── StrategyEvolver.ts
├── knowledge/
│   ├── patterns.json            # 混淆模式库（自动维护）
│   ├── strategy_candidates.json # 策略候选库（自动维护）
│   ├── success_history.json     # 成功历史
│   └── failed_paths.json        # 失败路径
├── .mcp/
│   └── config.json              # MCP 平台接入配置
├── .env.example
├── package.json
└── tsconfig.json

License

MIT

Available Tools

4 tools

evolve_jsA

对目标 URL 启动自动进化逆向工作流，直到反混淆代码匹配率达到阈值（默认 100%）。内置自学习：每次调用都会积累经验，越用越快。

ParametersJSON Schema

Name	Required	Description
`sessionId`	No	自定义会话 ID（可选，不填自动生成）
`targetUrl`	Yes	目标页面 URL（必填）
`maxIterations`	No	最大进化迭代次数，默认 50
`enableSelfLearn`	No	是否开启自学习记忆，默认 true
`enableAutoExpand`	No	是否允许自动合成新策略，默认 true
`successThreshold`	No	成功阈值 0~1，默认 1.0（完全匹配）

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It discloses the iterative evolution process, the threshold termination condition, and a self-learning side effect (accumulates experience, faster over time). However, it does not mention potential failure modes, performance implications, or the nature of persisted state, leaving important behavioral traits undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action and outcome, and the second sentence efficiently adds the self-learning behavior. No redundant or vague wording; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with six parameters and no output schema. The description explains the high-level evolutionary process but omits what the tool returns (e.g., deobfuscated code, logs, status), potential side effects beyond self-learning, and any conditions for when to use it. The schema covers parameter meaning, but for a tool of this complexity, the description leaves notable gaps in overall completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter having a description. The tool description adds no extra parameter semantics beyond what the schema already provides, mentioning only 'matching rate threshold' which is already captured by successThreshold. The baseline of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: launching an automated evolutionary reverse engineering workflow on a target URL until deobfuscated code matching reaches a threshold. It uses a specific verb and resource, and the sibling tools (inject_knowledge, get_evolution_history, query_knowledge) are clearly about knowledge/history, so this tool's role as the main evolution operation is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is the primary evolution entry point but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The sibling tools are knowledge-related, so context helps, but no explicit usage guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_evolution_historyA

查看 GitNexus 沙箱仓库中所有进化分支的状态（开放中 / 已合并 / 已放弃）。

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	返回分支数量上限，默认 10

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of disclosing behavioral traits. The verb '查看' (view) indicates a read-only operation, which is a useful behavioral disclosure. However, it does not mention any potential side effects, authentication requirements, rate limits, or further details about how the branches are listed. It adds some context by specifying the scope ('all') and the status values, but leaves out other potential behavioral nuances.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that is directly front-loaded with the action and resource. Every word earns its place, and there is no redundant or vague language. It is appropriately sized for a simple read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and no output schema, the description covers the essential purpose and behavior. It clearly states what the tool does and what statuses are shown. It does not explain the return format or how 'limit' affects results, but for a status-viewing tool, this is adequate. The description is complete enough for an agent to understand the tool's role, though additional context about branching semantics could enhance usability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the only parameter (limit) with its description and default value. The tool description does not add any additional parameter semantics beyond what the schema already provides. Since schema coverage is 100%, the baseline of 3 applies, and there is no extra value from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: viewing the status of evolution branches in the GitNexus sandbox repository. It uses a specific verb (查看/view) and specifies the resource (evolution branches) and the three possible statuses (open, merged, abandoned). This distinguishes it from sibling tools like evolve_js and inject_knowledge, which clearly have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use the tool (when you need to check branch statuses) but does not provide explicit guidance on when not to use it or mention alternative tools. The purpose is clear, but there is no direct comparison to siblings or exclusions, so usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inject_knowledgeB

手动向知识库注入人工经验（混淆模式或自定义策略），干预进化方向，加速收敛。

ParametersJSON Schema

Name	Required	Description
`fix`	Yes	修复逻辑（JavaScript 代码字符串，接收 code 参数，返回修复后代码）
`name`	Yes	模式或策略名称（唯一标识）
`signature`	Yes	正则特征签名（用于匹配目标代码）
`injectType`	Yes	pattern=注入混淆模式 \| strategy=注入自定义策略
`description`	Yes	描述

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavior itself but only gives a high-level purpose ('intervene in evolution direction, accelerate convergence'). It does not mention side effects, whether existing knowledge is overwritten, reversal possibilities, or failure behavior if the signature doesn't match. For a mutation tool, this is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that communicates the action, input types, and purpose without redundant fluff. It is appropriately front-loaded with the core verb 'inject' and resource, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 5 required parameters, no annotations, and no output schema. The description lacks operational details: how the injection integrates with evolution history, what happens on invalid input, and the exact role of the 'fix' JavaScript code. It is incomplete for an agent to confidently use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description mentions 'obfuscation patterns or custom strategies' which maps to the injectType enum, but does not add detail about how signature and fix work together or affect behavior. It adds no parameter-specific value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('inject') and resource ('knowledge base'), clearly indicating it adds human experience (obfuscation patterns or custom strategies) to influence evolution. It is clearly distinct from sibling tools: query_knowledge reads, get_evolution_history reads history, evolve_js runs evolution, while this tool modifies the knowledge base.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context: to intervene in evolution direction and accelerate convergence. However, it does not explicitly state when to use this over alternatives (e.g., query_knowledge or evolve_js) or when not to use it. No exclusions or alternative guidance is provided beyond the inferred purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_knowledgeB

查询系统积累的知识库，包括混淆模式、成功历史、失败路径、策略候选及整体统计。

ParametersJSON Schema

Name	Required	Description
`type`	Yes	查询类型：patterns=混淆模式 \| successes=成功历史 \| failures=失败路径 \| stats=统计概览
`limit`	No	返回条数上限，默认 20
`keyword`	No	关键词过滤（仅 patterns 类型有效）

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of disclosing behavior. It merely states that the tool queries the knowledge base, without confirming read-only semantics, side effects, return format, or any operational constraints. The verb 'query' implies reading, but this is not made explicit, and no additional behavioral context is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the verb and resource. It is concise and contains no extraneous information, earning its place despite the minor semantic discrepancy noted above.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple schema with three parameters and no output schema. The description provides an overview of the knowledge base categories but omits any explanation of return values or result structure. The mismatch between the description and schema regarding 'strategy candidates' also detracts from completeness, leaving the agent with only partial context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides full coverage (100%) and detailed descriptions for all parameters, so the description adds limited value. However, it introduces a potential inconsistency by listing 'strategy candidates' (策略候选) as part of the knowledge base, which does not correspond to any enum value in the schema. This could mislead an agent into attempting an invalid query type, and the description does not clarify parameter-specific behavior beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (query) and the resource (the accumulated knowledge base), listing specific content categories. It distinguishes from sibling tools through the verb 'query' (查询) versus inject, evolve, and history retrieval. Even though the list includes 'strategy candidates' not present in the schema's enum, the primary purpose remains unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus the sibling tools. It does not mention alternatives or exclusions, leaving the agent to infer usage solely from the name. This is a significant gap given the availability of related tools like inject_knowledge and get_evolution_history.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Aug 10, 2026
- First observedevolve_js
- First observedget_evolution_history
- First observedinject_knowledge
- First observedquery_knowledge

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: injecting knowledge, querying knowledge, running the evolution workflow, and viewing history. There is no overlap in purpose, so an agent can easily select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores: inject_knowledge, get_evolution_history, evolve_js, query_knowledge. The naming is uniform and predictable.

Tool Count5/5

Four tools is well-suited for the specialized domain of JS reverse evolution. Each tool serves a necessary function without redundancy or bloat, making the set compact and focused.

Completeness5/5

The tool set covers the full workflow: evolving a target (evolve_js), injecting expert knowledge to guide evolution (inject_knowledge), retrieving learned knowledge (query_knowledge), and tracking evolution history (get_evolution_history). No obvious gaps exist for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Android Security Analyzer A
io.github.ako2345
MCP server for static security analysis of Android source code
Security Code Analysis Testing & QA Tools
422
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
meok-mcp-hardening-mcp
io.github.CSOAI-ORG
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Penetration Testing Security
1
PlanWrightOAuth
tools.planwright
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Project Management Autonomous Agents
27

Related MCP Servers

ghidraMCP
Code Analysis Autonomous Agents Developer Tools
LaurieWired
A
license
Not graded
quality
D
maintenance
An MCP server that allows LLMs to autonomously reverse engineer applications by exposing Ghidra functionality, enabling decompilation, analysis, and automatic renaming of methods and data.
Updated a year ago (2025-06-23 04:18 UTC)
9,897
Apache 2.0
JS Reverse MCP
Browser Automation Web Scraping Developer Tools
NoOne-hub
A
license
C
quality
B
maintenance
An MCP server for JavaScript reverse engineering that enables AI to perform browser debugging, script analysis, and automated hook injection. It streamlines complex workflows like deobfuscation, network tracing, and risk assessment through direct browser integration.
Updated 3 months ago (2026-05-31 14:48 UTC)
35
27
995
Apache 2.0
JS Reverse MCP
Code Analysis Penetration Testing
a0yark
A
license
Not graded
quality
C
maintenance
A JavaScript reverse engineering MCP server that enables AI coding assistants to debug and analyze JavaScript code in web pages.
Updated 3 months ago (2026-06-17 08:31 UTC)
1,291
7
Apache 2.0
WebTrace MCP Server
Code Analysis Security
kings0527
F
license
Not graded
quality
B
maintenance
Exposes reverse engineering capabilities via MCP protocol, enabling AI agents to automatically detect, analyze, trace, and deobfuscate JSVMP protected JavaScript code.
Updated 2 months ago (2026-07-10 03:56 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JiangtaoQu/js-reverse-evolver'

If you have feedback or need assistance with the MCP directory API, please join our Discord server