Ejentum MCP

ejentum-mcp

複雑なタスク、複数ステップのタスク、または複数の制約があるタスクにおけるLLMの推論を改善するMCPサーバーです。エージェントは生成する前に、8つのツールのうち1つを呼び出して、認知操作を取得します。これは、拒否すべき失敗パターンと反証テストを含む構造化された手順（番号付きステップ）に、実行可能な推論トポロジー（決定ゲート、並列分岐、上限付きループ、メタ認知的な終了条件、エスケープ経路を備えた、それらのステップのDAG）を組み合わせたものです。エージェントは応答を生成する前に、両方の層を読み取ります。

8つのツールは、2つの取得モードに分かれています。

• 動的（4つのツール：reasoning、code、anti-deception、memory）：679件のライブラリから、query文字列との意味的な一致に基づいて選ばれた、最上位の抽象操作を取得します。30日間の無料トライアルを含む、すべてのプランで利用できます。
• 適応型（4つのツール：adaptive-reasoning、adaptive-code、adaptive-anti-deception、adaptive-memory）：同じ取得対象から選びますが、アダプターLLMが、マッチした操作の各ステップとDAGノードをタスク固有の識別子に書き換えます（例：extract_duration_estimatesがextract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)になります）。レイテンシーが約2～3秒増加します。GoまたはSuperプランが必要です。

2つのインストール方法で、同じEJENTUM_API_KEYを使用します。

1. Stdio：Claude Desktop、Cursor、Windsurf、Codex CLI、Claude Code、Cline、Continue、およびMCPサーバーをサブプロセスとして起動するすべてのクライアント向けのnpx -y ejentum-mcp。
2. ホスト型Streamable HTTP：n8n MCP ClientおよびHTTP-MCPクライアント向けのhttps://api.ejentum.com/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を再起動します。ツールピッカーに8つのツールが表示されます。

Cursor / Windsurf

MCP設定を開き、「Add new MCP server」を選択して、上記と同じejentumブロックを貼り付けます。

Claude Code（CLI）

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

n8n MCP Clientノード

MCP Clientノードを追加し、トランスポートをstdio、コマンドをnpx、引数を["-y", "ejentum-mcp"]、環境変数を{ "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に一致するキーを1つだけ含みます。ハイフンを含むキーにはブラケット記法（result[0]["anti-deception"]）を使用してください。ドット記法では、JavaScriptでハイフンが減算として解釈され、Pythonでは属性アクセスとして扱われます。

インジェクション文字列は、7つのフィールドを含むプレーンテキストです。以下のフィールドの構造を参照してください。

---

ツール一覧

動的（単一検索、30 日間のトライアルを含むすべてのティア）

ツール名	モード文字列	ライブラリの規模
reasoning	reasoning	抽象化、時間、因果関係、シミュレーション、空間、メタ認知にわたる 311 の操作
code	code	ソフトウェアエンジニアリング層にわたる 128 の操作
anti-deception	anti-deception	迎合、幻覚、欺瞞、敵対的な枠組み、判断、エグゼクティブコントロールにわたる 139 の操作
memory	memory	知覚層の 101 の操作（フィルター指向。事実抽出には呼び出さないでください）

適応型（top-k 検索＋アダプター LLM による書き換え。Go または Super ティアが必要）

ツール名	モード文字列	動的モードとの動作の違い
adaptive-reasoning	adaptive-reasoning	同じ検索プールから上位 5 件を取得して選択した後、アダプター LLM が PROCEDURE フィールドと REASONING TOPOLOGY フィールドをタスク固有の識別子で書き換えます。レイテンシが約 2～3 秒増加します。
adaptive-code	adaptive-code	コードライブラリに対して上記と同様に動作します。
adaptive-anti-deception	adaptive-anti-deception	anti-deception ライブラリに対して上記と同様に動作します。
adaptive-memory	adaptive-memory	memory ライブラリに対して上記と同様に動作します。

各ツールは query（文字列、タスクを説明する 1～2 文）という引数を 1 つ受け取ります。インジェクション文字列を返します。

---

インジェクションのフィールド構造

取得される各レコードには、7 つのラベル付きブロックと認知ペイロードが含まれます。ラベルの正確な組み合わせはモードによって異なります。

すべての応答で、フィールドはこの固定順序で表示されます。各モードは同じスロットに独自のラベルを使用します（たとえば、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）	正しい応答の形式です。

すべてのモードの動的版と適応型版で、同じ 6 スロットの順序が保たれます。適応型の応答では、アダプター 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 が推論経路の構造化されたアウトラインとして読み取ることを意図しています。ラベル付きステップ構造により、文章のみの推論仕様では検索時の顕著性が失われるような長いコンテキストウィンドウでも、構造が維持されます。

---

標準的な例：同じクエリに対する dynamic と adaptive

クエリ（両方の呼び出しで使用）：

トリガーベースのデフォルトを使用するバックフィル戦略について、50M 行のテーブルに NOT NULL 列を追加するデータベース移行計画が、同時書き込みのもとで安全かどうかを評価してください。

ピッカーは、両方の呼び出しで同じ操作（Hofstadter バッファーを使用した「現実的な所要時間の見積もり」）を一致させました。[NEGATIVE GATE]、[TARGET PATTERN]、[FALSIFICATION TEST]、[COGNITIVE PAYLOAD] の各フィールドは、2 つの応答で同一です（アダプターはこれらを書き換えません）。[PROCEDURE] と [REASONING TOPOLOGY] のフィールドは異なります。adaptive の応答では、抽象的な識別子がタスク固有のものに置き換えられます。

Dynamic 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 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.

これが仕様です。dynamic は一致した抽象操作を返します。adaptive は、操作の構造的な同一性、安全性に関する文言、認知ペイロードをそのまま維持しながら、呼び出し元のタスク（DDL execution time、lock_blocking_app_queries、trigger-based backfill on a table this size）に合わせて書き換えられた PROCEDURE とトポロジーノードを含む、同じ操作を返します。

---

設定

変数	必須	用途
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	adaptive モードが含まれていないプラン（トライアルまたは未認識のプラン）で、adaptive モードが要求されました。
429 Rate limit exceeded	期間内のプランのクォータを使い切りました。
クライアントにツールが表示されない	設定変更後にクライアントが再読み込みされていません。完全に終了してから再度開いてください。Claude Desktop では、Help → Logs を確認してください。
ラッパーから EJENTUM_API_KEY is not set が返される	クライアントが、起動された MCP プロセスに env ブロックを渡しませんでした。

---

ローカル開発

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.