Ejentum MCP

ejentum-mcp

可提升大模型在复杂、多步骤或多约束任务中推理能力的 MCP 服务。在 Agent 生成内容前，它会调用八种工具之一，检索一种认知操作：一种结构化流程（包含编号步骤、需要拒绝的失败模式以及证伪测试），并配有可执行的推理拓扑（由这些步骤构成的 DAG，包含决策门、并行分支、有界循环、元认知退出点和逃生路径）。Agent 会在生成回复前阅读这两个层次的内容。

八种工具分为两种检索模式：

• 动态（4 种工具：reasoning、code、anti-deception、memory）：从包含 679 种操作的库中，基于 query 字符串进行语义匹配，选出排名第一的抽象操作。所有套餐均可使用，包括 30 天免费试用。
• 自适应（4 种工具：adaptive-reasoning、adaptive-code、adaptive-anti-deception、adaptive-memory）：使用相同的检索池，但适配器大模型会根据具体任务改写匹配操作中的每个步骤和 DAG 节点标识符（例如，将 extract_duration_estimates 改为 extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)）。延迟增加约 2–3 秒；需要 Go 或 Super 套餐。

两种安装方式均使用相同的 EJENTUM_API_KEY：

1. Stdio：通过 npx -y ejentum-mcp，适用于 Claude Desktop、Cursor、Windsurf、Codex CLI、Claude Code、Cline、Continue，以及任何将 MCP 服务作为子进程启动的客户端。
2. 托管式 Streamable HTTP：地址为 https://api.ejentum.com/mcp，适用于 n8n MCP Client 和任何 HTTP-MCP 客户端。发送 Authorization: Bearer YOUR_EJENTUM_API_KEY。

---

安装

你需要：

• Ejentum API 密钥。可在 ejentum.com/pricing 申请 30 天免费试用（无需银行卡）。
• Node.js 18+。

从 npm 安装

npm install ejentum-mcp

也可以跳过安装，直接在客户端配置中使用 npx -y ejentum-mcp（如下所示）。

手动安装

Claude Desktop

打开 claude_desktop_config.json：

• macOS：~/Library/Application Support/Claude/claude_desktop_config.json
• Windows：%APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "ejentum": {
      "command": "npx",
      "args": ["-y", "ejentum-mcp"],
      "env": { "EJENTUM_API_KEY": "ej_..." }
    }
  }
}

重启 Claude Desktop。工具选择器中会显示八种工具。

Cursor / Windsurf

打开 MCP 设置 → 添加新的 MCP 服务 → 粘贴上文中的相同 ejentum 配置块。

Claude Code（CLI）

claude mcp add ejentum -e EJENTUM_API_KEY=ej_... -- npx -y ejentum-mcp

n8n MCP Client 节点

添加一个 MCP Client 节点，传输方式设为 stdio，命令设为 npx，args 设为 ["-y", "ejentum-mcp"]，env 设为 { "EJENTUM_API_KEY": "ej_..." }。

---

线协议

stdio MCP 服务和托管端点都会代理到同一个上游服务：

POST https://api.ejentum.com/harness/
Headers:
  Authorization: Bearer <EJENTUM_API_KEY>
  Content-Type: application/json
Body:
  {
    "query": "<string, 1-2 sentences describing the task>",
    "mode":  "reasoning" | "code" | "anti-deception" | "memory"
           | "adaptive-reasoning" | "adaptive-code"
           | "adaptive-anti-deception" | "adaptive-memory"
  }
Response (200):
  [ { "<mode>": "<injection string, ~2-4 KB>" } ]
Response (401): { "error": "Unauthorized; check EJENTUM_API_KEY" }
Response (403): { "error": "Adaptive modes require Go or Super tier" }
Response (429): { "error": "Rate limit exceeded for tier" }

响应是一个长度为 1 的数组，其中只有一个键与请求的 mode 相匹配。对于带连字符的键，请使用方括号访问（result[0]["anti-deception"]）；点号访问会将连字符解析为 JavaScript 中的减号，也无法用于 Python 属性访问。

注入字符串是纯文本，包含七个字段。请参阅下文的字段结构。

---

工具一览

动态（单次检索，适用于所有层级，包括 30 天试用期）

工具名称	模式字符串	库大小
reasoning	reasoning	311 个操作，涵盖抽象、时间、因果关系、模拟、空间、元认知
code	code	128 个操作，涵盖软件工程层
anti-deception	anti-deception	139 个操作，涵盖谄媚、幻觉、欺骗、对抗性框架、判断、执行控制
memory	memory	感知层中的 101 个操作（以筛选为导向；请勿用于事实提取）

自适应（top-k 检索 + 适配器 LLM 改写；需要 Go 或 Super 层级）

工具名称	模式字符串	相较于动态模式的行为
adaptive-reasoning	adaptive-reasoning	使用相同的检索池，先取 top-5，再由选择器筛选，然后由适配器 LLM 使用特定于任务的标识符改写 PROCEDURE 和 REASONING TOPOLOGY 字段。会增加约 2-3 秒延迟。
adaptive-code	adaptive-code	与上述相同，适用于 code 库。
adaptive-anti-deception	adaptive-anti-deception	与上述相同，适用于 anti-deception 库。
adaptive-memory	adaptive-memory	与上述相同，适用于 memory 库。

每个工具都接受一个参数 query（字符串，用 1-2 句话描述任务）。返回注入字符串。

---

注入内容的字段结构

每条检索到的记录都包含七个带标签的区块，以及一个认知负载。具体标签因模式而异：

每个响应中的字段都按此固定顺序排列。每种模式对同一位置使用自己的标签（例如，reasoning 中的 [PROCEDURE] 对应 code 中的 [ENGINEERING PROCEDURE]）：

顺序	位置	各模式标签	内容
1	步骤	[PROCEDURE]（reasoning） · [ENGINEERING PROCEDURE]（code） · [INTEGRITY PROCEDURE]（anti-deception） · [SHARPENING PROCEDURE]（memory）	模型执行的编号步骤。
2	拓扑结构	[REASONING TOPOLOGY]（reasoning） · [REASONING TOPOLOGY]（code） · [DETECTION TOPOLOGY]（anti-deception） · [PERCEPTION TOPOLOGY]（memory）	DAG 规范。参见 DAG 语法。
3	认知负载	Amplify: / Suppress: / Cognitive Style: / Elasticity:（所有模式）	倾向向量和执行风格提示。
4	验证	[FALSIFICATION TEST]（reasoning） · [VERIFICATION]（code） · [INTEGRITY CHECK]（anti-deception） · [PERCEPTION CHECK]（memory）	模型在起草后运行的自检。
5	失败模式	[NEGATIVE GATE]（reasoning） · [CODE FAILURE]（code） · [DECEPTION PATTERN]（anti-deception） · [PERCEPTION FAILURE]（memory）	应当拒绝的失败模式。
6	正确形式	[TARGET PATTERN]（reasoning） · [CORRECT PATTERN]（code） · [HONEST BEHAVIOR]（anti-deception） · [CLEAR SIGNAL]（memory）	正确响应的样子。

所有模式的动态和自适应变体都遵循相同的六个位置顺序。在自适应响应中，适配器 LLM 会使用特定于任务的标识符改写第 1 和第 2 个位置（步骤和拓扑结构）；第 3-6 个位置则原样返回。

DAG 语法

拓扑块使用扁平字符串表示法：

标记	含义
Sn:label	步骤节点。默认按顺序编号。
Gn{?}	决策门。分支为 --yes-> / --no->。
N{...}	负面锚点。在整个分支中生效；拒绝带标签的失败模式。
M{...}	元认知节点。模型暂停并评估轨迹，然后在指定步骤 RE-ENTER。
FREEFORM{...}	逃逸路径。当计划不再适用时，模型退出预设的 DAG；返回某个步骤或 OUT。
FIXED_POINT[...]	在整个分支中保持稳定的量。
for_each: / LOOP[...]	有界迭代。
C{expr}	下游使用的计算值。
OUT:label	终止节点。

此 DAG 旨在供 LLM 作为推理路径的结构化大纲阅读，而不是由宿主运行时执行。在纯文本推理规范失去检索显著性的长上下文窗口中，带标签的步骤结构仍能保持有效。

---

标准示例：同一查询下的动态模式与自适应模式

查询（两次调用使用相同查询）：

评估数据库迁移计划是否能在并发写入期间安全执行：该计划要向一个有 5000 万行的表添加 NOT NULL 列，且回填策略使用基于触发器的默认值。

两次调用中，匹配器都选中了同一操作（使用 Hofstadter 缓冲的“实际耗时估算”）。两种响应中的 [NEGATIVE GATE]、[TARGET PATTERN]、[FALSIFICATION TEST] 和 [COGNITIVE PAYLOAD] 字段完全相同（适配器不会重写这些字段）。[PROCEDURE] 和 [REASONING TOPOLOGY] 字段有所不同：自适应响应会将抽象标识符替换为特定任务的标识符。

动态 reasoning 响应（截断，仅显示差异字段）

[PROCEDURE]
Step 1: Extract every duration estimate and identify its basis: historical data,
expert judgment, or optimistic assumption. Step 2: Compare each estimate against
historical base rates or p90 benchmarks for similar tasks. Step 3: Flag estimates
below the historical median as likely optimistic. Step 4: Never accept best-case
estimates as planning targets. Do not anchor to initial optimistic numbers.
Step 5: If an estimate lacks historical basis, simulate impact with a 1.5x-2.0x
buffer. If data exists, compute the variance-adjusted range. Verify the final
timeline accounts for cascading delay propagation across dependent tasks.

[REASONING TOPOLOGY]
S1:extract_duration_estimates -> N{accept_best_case_estimates_planning_targets}
-> S2:identify_basis(historical|expert|assumption)
-> FIXED_POINT[historical_base_rates]
-> S3:compare(estimate_vs_p90_benchmark)
-> G1{below_median?} --yes-> FLAG:likely_optimistic -> S4:apply_buffer(1.5x_to_2x) -> S3[LOOP]
                       --no-> G2{lacks_historical_basis?} --yes-> S4b:simulate_with_buffer -> S3
                                                          --no-> C{adjusted_range = base_rate_estimate +/- sqrt(variance) * z}
                                                              -> S5:apply_adjusted_range
                                                              -> S6:verify_cascade_delay
                                                              -> OUT:realistic_timeline

自适应 adaptive-reasoning 响应（相同查询、相同选定操作）

[PROCEDURE]
Step 1: Extract every duration estimate in the migration plan (DDL execution time
for adding NOT NULL column on 50M rows, backfill duration, trigger overhead per
concurrent write, total migration window) and identify its basis: historical
migration data on similar table sizes, DBA expert judgment, or optimistic
assumption assuming zero contention. Step 2: Compare each estimate against
historical base rates or p90 benchmarks for similar DDL operations on large tables
(e.g., ALTER TABLE duration per million rows, trigger-induced latency under
concurrent write load). Step 3: Flag estimates below the historical median as
likely optimistic, e.g., assuming sub-second column addition without considering
lock escalation on a 50M-row table, or assuming trigger-based backfill adds
negligible overhead under concurrent write traffic. Step 4: Never accept best-case
estimates as planning targets. Do not anchor to initial optimistic numbers such
as "the NOT NULL addition will complete instantly" or "the trigger will not slow
down concurrent writes." Step 5: If an estimate lacks historical basis (e.g., no
prior trigger-based backfill on a table this size), simulate impact with a
1.5x-2.0x buffer for lock duration and write throughput degradation. If data
exists (e.g., past ALTER TABLE timings on this table), compute the
variance-adjusted range. Verify the final timeline accounts for cascading delay
propagation across dependent tasks (e.g., extended lock hold times blocking
application queries, backfill slowdown under write contention propagating to
downstream replication lag).

[REASONING TOPOLOGY]
S1:extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)
-> N{accept_best_case_estimates_planning_targets}
-> S2:identify_basis(historical_migration_data|DBA_expert_judgment|optimistic_assumption)
-> FIXED_POINT[historical_base_rates_for_DDL_on_large_tables]
-> S3:compare(estimate_vs_p90_benchmark_for_ALTER_TABLE_and_trigger_overhead)
-> G1{below_median_for_similar_migrations?} --yes-> FLAG:likely_optimistic(e.g.,assumes_zero_lock_contention)
                                                 -> S4:apply_buffer(1.5x_to_2x_for_lock_duration_and_write_throughput)
                                                 -> S3[LOOP]
                                              --no-> G2{lacks_historical_basis_for_trigger_backfill_on_50M_table?}
                                                       --yes-> S4b:simulate_with_buffer_for_concurrent_write_impact_and_lock_escalation
                                                       --no--> C{adjusted_range = base_rate_migration_estimate +/- sqrt(variance) * z}
                                                              -> S5:apply_adjusted_range_for_migration_window
                                                              -> S6:verify_cascade_delay(lock_blocking_app_queries -> replication_lag -> downstream_consumers)
                                                              -> OUT:realistic_migration_timeline

两种响应的共有字段（第 3–6 个槽位，由适配器保持不变）

按标准顺序返回：认知负载、证伪测试、负面门、目标模式。

[COGNITIVE PAYLOAD]
Amplify: hofstadter buffer application; p90 baseline comparison; variance
         multiplier scaling
Suppress: best case anchoring; optimism bias
Cognitive Style: realistic duration estimation
Elasticity: coherence=risk adjusted timeline, expansion=conservative

[FALSIFICATION TEST]
If time estimates reflect only the best-case scenario without verifying applying
any buffer multiplier, duration calibration has defaulted to optimism.

[NEGATIVE GATE]
The database migration will take two weeks: that's our best-case estimate and the
team is experienced, so there's no reason to add buffer. We'll hit the deadline
if everything goes according to plan.

[TARGET PATTERN]
Challenge the two-week estimate: what do similar migrations actually take? If past
projects averaged four weeks at p90, the best-case anchor is dangerously optimistic.
Apply a variance multiplier for schema complexity, data volume, and rollback
testing: build buffer from the full distribution, not the happy path.

这就是约定：动态模式返回匹配到的抽象操作；自适应模式返回同一操作，但会根据调用方的任务重写 PROCEDURE 和拓扑节点（DDL execution time、lock_blocking_app_queries、trigger-based backfill on a table this size），同时保留该操作的结构特征、安全措辞和认知负载原文。

---

配置

变量	必需	用途
EJENTUM_API_KEY	是	从 ejentum.com/pricing 获取的 API 密钥。
EJENTUM_API_URL	否	覆盖上游 URL。默认值：https://api.ejentum.com/harness/。

MCP 包装器是无状态的。不会进行本地日志记录、遥测或第三方调用。上游 API 会将请求计入该密钥的计费额度；请求正文（query 字符串）仅用于检索，不会在响应后保留。

---

错误

状态	原因
401 Unauthorized	EJENTUM_API_KEY 未设置、错误或已过期。
403 Forbidden	在不包含自适应模式的套餐（试用版或无法识别的套餐）中请求了自适应模式。
429 Rate limit exceeded	当前周期的套餐配额已用尽。
客户端中未显示工具	配置更改后，客户端未重新加载。请完全退出并重新打开；在 Claude Desktop 中，请检查“帮助” → “日志”。
包装器返回 EJENTUM_API_KEY is not set	客户端未将 env 块传递给启动的 MCP 进程。

---

本地开发

git clone https://github.com/ejentum/ejentum-mcp.git
cd ejentum-mcp
npm install
cp .env.example .env       # paste your EJENTUM_API_KEY
npm run dev

针对线上 API 运行冒烟测试：

npm run build && npm run test:smoke

使用 MCP Inspector 进行交互式测试：

npx @modelcontextprotocol/inspector npm run dev

---

Listings

• Glama
• mcp.so
• npm: npm install -g ejentum-mcp

Links

• Ejentum documentation
• Method
• n8n integration
• Claude Code integration
• Pricing
• [email protected]

License

MIT. See LICENSE.