Ejentum MCP

ejentum-mcp

MCP server that improves LLM reasoning on complex, multi-step, or multi-constraint tasks. Before the agent generates, it calls one of eight tools to retrieve a *cognitive operation*: a structured procedure (numbered steps with the failure pattern to refuse and a falsification test) paired with an executable reasoning topology (a DAG of those steps with decision gates, parallel branches, bounded loops, meta-cognitive exits, and escape paths). The agent reads both layers before producing its response.

Eight tools split into two retrieval modes:

• Dynamic (4 tools: reasoning, code, anti-deception, memory): the top-1 abstract operation from a library of 679, selected by semantic match on the query string. Available on all tiers including the 30-day free trial.
• Adaptive (4 tools: adaptive-reasoning, adaptive-code, adaptive-anti-deception, adaptive-memory): the same retrieval pool, but an adapter LLM rewrites every step and DAG node in the matched operation with task-specific identifiers (e.g., extract_duration_estimates becomes extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)). Adds ~2-3 s of latency; requires the Go or Super tier.

Two install paths use the same EJENTUM_API_KEY:

1. Stdio via npx -y ejentum-mcp for Claude Desktop, Cursor, Windsurf, Codex CLI, Claude Code, Cline, Continue, and any client that spawns MCP servers as subprocesses.
2. Hosted Streamable HTTP at https://api.ejentum.com/mcp for n8n MCP Client and any HTTP-MCP client. Send Authorization: Bearer YOUR_EJENTUM_API_KEY.

Install

You need:

• An Ejentum API key. 30-day free trial (no card) at ejentum.com/pricing.
• Node.js 18+.

Install from npm

npm install ejentum-mcp

Or skip the install and reference it with npx -y ejentum-mcp directly in your client config (shown below).

Manual install

Claude Desktop

Open 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_..." } } } }

Restart Claude Desktop. The eight tools appear in the tool picker.

Cursor / Windsurf

Open MCP settings → Add new MCP server → paste the same ejentum block as above.

Claude Code (CLI)

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

n8n MCP Client node

Add an MCP Client node, transport stdio, command npx, args ["-y", "ejentum-mcp"], env { "EJENTUM_API_KEY": "ej_..." }.

Wire contract

The stdio MCP server and the hosted endpoint both proxy to the same upstream:

POST https://api.ejentum.com/harness/

Headers: Authorization: Bearer Content-Type: application/json Body: { "query": " ", "mode": "reasoning" | "code" | "anti-deception" | "memory" | "adaptive-reasoning" | "adaptive-code" | "adaptive-anti-deception" | "adaptive-memory" } Response (200): [ { " ": " " } ] 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" }

The response is an array of length 1 with a single key matching the request mode. Use bracket access (result0) for the hyphenated keys; dot access parses the hyphen as subtraction in JavaScript and Python attribute access.

The injection string is plain text containing seven fields. See Field structure below.

Tool inventory

Dynamic (single retrieval, all tiers including the 30-day trial)

Adaptive (top-k retrieval + adapter LLM rewrite; Go or Super tier required)

Each tool takes one argument, query (string, 1-2 sentences describing the task). Returns the injection string.

Field structure of an injection

Every retrieved record contains seven labelled blocks plus a cognitive payload. The exact set of labels varies by mode:

The fields appear in this fixed order in every response. Each mode uses its own label for the same slot (e.g., [PROCEDURE] in reasoning corresponds to [ENGINEERING PROCEDURE] in code):

The same six-slot order holds for both dynamic and adaptive variants of every mode. In adaptive responses, the adapter LLM rewrites slots 1 and 2 (procedure and topology) with task-specific identifiers; slots 3-6 are returned verbatim.

DAG syntax

The topology block uses a flat string notation:

The DAG is meant to be read by the LLM as a structured outline of the reasoning path, not executed by a host runtime. The labelled-step structure persists across long context windows where prose-only reasoning specifications lose retrieval salience.

Canonical example: dynamic vs adaptive on the same query

Query (used for both calls):

Evaluate whether a database migration plan that adds a NOT NULL column to a 50M-row table is safe under concurrent writes, given that the backfill strategy uses a trigger-based default.

The picker matched the same operation in both calls ("realistic duration estimation" with the Hofstadter buffer). The [NEGATIVE GATE], [TARGET PATTERN], [FALSIFICATION TEST], and [COGNITIVE PAYLOAD] fields are identical between the two responses (the adapter does not rewrite them). The [PROCEDURE] and [REASONING TOPOLOGY] fields differ: the adaptive response replaces abstract identifiers with task-specific ones.

Dynamic reasoning response (truncated to the differing fields)

[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 response (same query, same picked operation)

[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 plann