{
  "markdown": "# ejentum-mcp\n\n[![npm version](https://img.shields.io/npm/v/ejentum-mcp.svg)](https://www.npmjs.com/package/ejentum-mcp)\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![Node](https://img.shields.io/node/v/ejentum-mcp.svg)](https://nodejs.org)\n[![MCP Registry](https://img.shields.io/badge/MCP%20Registry-io.github.ejentum%2Fejentum--mcp-blue)](https://registry.modelcontextprotocol.io/v0/servers?search=io.github.ejentum/ejentum-mcp)\n[![Glama score](https://glama.ai/mcp/servers/ejentum/ejentum-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ejentum/ejentum-mcp)\n[![Last commit](https://img.shields.io/github/last-commit/ejentum/ejentum-mcp.svg)](https://github.com/ejentum/ejentum-mcp/commits/main)\n\nMCP 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.\n\nEight tools split into two retrieval modes:\n\n- **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.\n- **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.\n\nTwo install paths use the same `EJENTUM_API_KEY`:\n\n1. **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.\n2. **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`.\n\n---\n\n## Install\n\nYou need:\n- An Ejentum API key. 30-day free trial (no card) at [ejentum.com/pricing](https://ejentum.com/pricing).\n- Node.js 18+.\n\n### Install from npm\n\n```bash\nnpm install ejentum-mcp\n```\n\nOr skip the install and reference it with `npx -y ejentum-mcp` directly in your client config (shown below).\n\n### Manual install\n\n#### Claude Desktop\n\nOpen `claude_desktop_config.json`:\n- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`\n- Windows: `%APPDATA%\\Claude\\claude_desktop_config.json`\n\n```json\n{\n  \"mcpServers\": {\n    \"ejentum\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"ejentum-mcp\"],\n      \"env\": { \"EJENTUM_API_KEY\": \"ej_...\" }\n    }\n  }\n}\n```\n\nRestart Claude Desktop. The eight tools appear in the tool picker.\n\n#### Cursor / Windsurf\n\nOpen MCP settings → Add new MCP server → paste the same `ejentum` block as above.\n\n#### Claude Code (CLI)\n\n```bash\nclaude mcp add ejentum -e EJENTUM_API_KEY=ej_... -- npx -y ejentum-mcp\n```\n\n#### n8n MCP Client node\n\nAdd an MCP Client node, transport `stdio`, command `npx`, args `[\"-y\", \"ejentum-mcp\"]`, env `{ \"EJENTUM_API_KEY\": \"ej_...\" }`.\n\n---\n\n## Wire contract\n\nThe stdio MCP server and the hosted endpoint both proxy to the same upstream:\n\n```\nPOST https://api.ejentum.com/harness/\nHeaders:\n  Authorization: Bearer <EJENTUM_API_KEY>\n  Content-Type: application/json\nBody:\n  {\n    \"query\": \"<string, 1-2 sentences describing the task>\",\n    \"mode\":  \"reasoning\" | \"code\" | \"anti-deception\" | \"memory\"\n           | \"adaptive-reasoning\" | \"adaptive-code\"\n           | \"adaptive-anti-deception\" | \"adaptive-memory\"\n  }\nResponse (200):\n  [ { \"<mode>\": \"<injection string, ~2-4 KB>\" } ]\nResponse (401): { \"error\": \"Unauthorized; check EJENTUM_API_KEY\" }\nResponse (403): { \"error\": \"Adaptive modes require Go or Super tier\" }\nResponse (429): { \"error\": \"Rate limit exceeded for tier\" }\n```\n\nThe response is an array of length 1 with a single key matching the request `mode`. Use bracket access (`result[0][\"anti-deception\"]`) for the hyphenated keys; dot access parses the hyphen as subtraction in JavaScript and Python attribute access.\n\nThe injection string is plain text containing seven fields. See [Field structure](#field-structure-of-an-injection) below.\n\n---\n\n## Tool inventory\n\n### Dynamic (single retrieval, all tiers including the 30-day trial)\n\n| Tool name | Mode string | Library size |\n|---|---|---:|\n| `reasoning` | `reasoning` | 311 operations across abstraction, time, causality, simulation, spatial, metacognition |\n| `code` | `code` | 128 operations across the software-engineering layer |\n| `anti-deception` | `anti-deception` | 139 operations across sycophancy, hallucination, deception, adversarial framing, judgment, executive control |\n| `memory` | `memory` | 101 operations in the perception layer (filter-oriented; do not call for fact extraction) |\n\n### Adaptive (top-k retrieval + adapter LLM rewrite; Go or Super tier required)\n\n| Tool name | Mode string | Behavior vs dynamic |\n|---|---|---|\n| `adaptive-reasoning` | `adaptive-reasoning` | Same retrieval pool, top-5 then picker, then adapter LLM rewrites PROCEDURE and REASONING TOPOLOGY fields with task-specific identifiers. Adds ~2-3 s of latency. |\n| `adaptive-code` | `adaptive-code` | Same as above for the code library. |\n| `adaptive-anti-deception` | `adaptive-anti-deception` | Same as above for the anti-deception library. |\n| `adaptive-memory` | `adaptive-memory` | Same as above for the memory library. |\n\nEach tool takes one argument, `query` (string, 1-2 sentences describing the task). Returns the injection string.\n\n---\n\n## Field structure of an injection\n\nEvery retrieved record contains seven labelled blocks plus a cognitive payload. The exact set of labels varies by mode:\n\nThe 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):\n\n| Order | Slot | Per-mode labels | Content |\n|--:|---|---|---|\n| 1 | Procedure | `[PROCEDURE]` (reasoning) · `[ENGINEERING PROCEDURE]` (code) · `[INTEGRITY PROCEDURE]` (anti-deception) · `[SHARPENING PROCEDURE]` (memory) | Numbered steps the model executes. |\n| 2 | Topology | `[REASONING TOPOLOGY]` (reasoning) · `[REASONING TOPOLOGY]` (code) · `[DETECTION TOPOLOGY]` (anti-deception) · `[PERCEPTION TOPOLOGY]` (memory) | DAG specification. See [DAG syntax](#dag-syntax). |\n| 3 | Cognitive payload | `Amplify:` / `Suppress:` / `Cognitive Style:` / `Elasticity:` (all modes) | Tendency vectors and execution-style hints. |\n| 4 | Verification | `[FALSIFICATION TEST]` (reasoning) · `[VERIFICATION]` (code) · `[INTEGRITY CHECK]` (anti-deception) · `[PERCEPTION CHECK]` (memory) | Self-check the model runs after drafting. |\n| 5 | Failure pattern | `[NEGATIVE GATE]` (reasoning) · `[CODE FAILURE]` (code) · `[DECEPTION PATTERN]` (anti-deception) · `[PERCEPTION FAILURE]` (memory) | The failure pattern to refuse. |\n| 6 | Correct shape | `[TARGET PATTERN]` (reasoning) · `[CORRECT PATTERN]` (code) · `[HONEST BEHAVIOR]` (anti-deception) · `[CLEAR SIGNAL]` (memory) | What a correct response looks like. |\n\nThe 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.\n\n### DAG syntax\n\nThe topology block uses a flat string notation:\n\n| Token | Meaning |\n|---|---|\n| `Sn:label` | Step node. Numbered, sequential by default. |\n| `Gn{?}` | Decision gate. Branches `--yes->` / `--no->`. |\n| `N{...}` | Negative anchor. Active across the whole branch; the labelled failure pattern is refused. |\n| `M{...}` | Meta-cognitive node. Model pauses, evaluates the trace, then `RE-ENTER`s at a named step. |\n| `FREEFORM{...}` | Escape path. Model exits the prescribed DAG when the plan stops fitting; returns to a step or `OUT`. |\n| `FIXED_POINT[...]` | A quantity held stable across the branch. |\n| `for_each:` / `LOOP[...]` | Bounded iteration. |\n| `C{expr}` | Computed value used downstream. |\n| `OUT:label` | Terminal node. |\n\nThe 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.\n\n---\n\n## Canonical example: dynamic vs adaptive on the same query\n\nQuery (used for both calls):\n\n> 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.\n\nThe 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.\n\n### Dynamic `reasoning` response (truncated to the differing fields)\n\n```\n[PROCEDURE]\nStep 1: Extract every duration estimate and identify its basis: historical data,\nexpert judgment, or optimistic assumption. Step 2: Compare each estimate against\nhistorical base rates or p90 benchmarks for similar tasks. Step 3: Flag estimates\nbelow the historical median as likely optimistic. Step 4: Never accept best-case\nestimates as planning targets. Do not anchor to initial optimistic numbers.\nStep 5: If an estimate lacks historical basis, simulate impact with a 1.5x-2.0x\nbuffer. If data exists, compute the variance-adjusted range. Verify the final\ntimeline accounts for cascading delay propagation across dependent tasks.\n\n[REASONING TOPOLOGY]\nS1:extract_duration_estimates -> N{accept_best_case_estimates_planning_targets}\n-> S2:identify_basis(historical|expert|assumption)\n-> FIXED_POINT[historical_base_rates]\n-> S3:compare(estimate_vs_p90_benchmark)\n-> G1{below_median?} --yes-> FLAG:likely_optimistic -> S4:apply_buffer(1.5x_to_2x) -> S3[LOOP]\n                       --no-> G2{lacks_historical_basis?} --yes-> S4b:simulate_with_buffer -> S3\n                                                          --no-> C{adjusted_range = base_rate_estimate +/- sqrt(variance) * z}\n                                                              -> S5:apply_adjusted_range\n                                                              -> S6:verify_cascade_delay\n                                                              -> OUT:realistic_timeline\n```\n\n### Adaptive `adaptive-reasoning` response (same query, same picked operation)\n\n```\n[PROCEDURE]\nStep 1: Extract every duration estimate in the migration plan (DDL execution time\nfor adding NOT NULL column on 50M rows, backfill duration, trigger overhead per\nconcurrent write, total migration window) and identify its basis: historical\nmigration data on similar table sizes, DBA expert judgment, or optimistic\nassumption assuming zero contention. Step 2: Compare each estimate against\nhistorical base rates or p90 benchmarks for similar DDL operations on large tables\n(e.g., ALTER TABLE duration per million rows, trigger-induced latency under\nconcurrent write load). Step 3: Flag estimates below the historical median as\nlikely optimistic, e.g., assuming sub-second column addition without considering\nlock escalation on a 50M-row table, or assuming trigger-based backfill adds\nnegligible overhead under concurrent write traffic. Step 4: Never accept best-case\nestimates as planning targets. Do not anchor to initial optimistic numbers such\nas \"the NOT NULL addition will complete instantly\" or \"the trigger will not slow\ndown concurrent writes.\" Step 5: If an estimate lacks historical basis (e.g., no\nprior trigger-based backfill on a table this size), simulate impact with a\n1.5x-2.0x buffer for lock duration and write throughput degradation. If data\nexists (e.g., past ALTER TABLE timings on this table), compute the\nvariance-adjusted range. Verify the final timeline accounts for cascading delay\npropagation across dependent tasks (e.g., extended lock hold times blocking\napplication queries, backfill slowdown under write contention propagating to\ndownstream replication lag).\n\n[REASONING TOPOLOGY]\nS1:extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)\n-> N{accept_best_case_estimates_planning_targets}\n-> S2:identify_basis(historical_migration_data|DBA_expert_judgment|optimistic_assumption)\n-> FIXED_POINT[historical_base_rates_for_DDL_on_large_tables]\n-> S3:compare(estimate_vs_p90_benchmark_for_ALTER_TABLE_and_trigger_overhead)\n-> G1{below_median_for_similar_migrations?} --yes-> FLAG:likely_optimistic(e.g.,assumes_zero_lock_contention)\n                                                 -> S4:apply_buffer(1.5x_to_2x_for_lock_duration_and_write_throughput)\n                                                 -> S3[LOOP]\n                                              --no-> G2{lacks_historical_basis_for_trigger_backfill_on_50M_table?}\n                                                       --yes-> S4b:simulate_with_buffer_for_concurrent_write_impact_and_lock_escalation\n                                                       --no--> C{adjusted_range = base_rate_migration_estimate +/- sqrt(variance) * z}\n                                                              -> S5:apply_adjusted_range_for_migration_window\n                                                              -> S6:verify_cascade_delay(lock_blocking_app_queries -> replication_lag -> downstream_consumers)\n                                                              -> OUT:realistic_migration_timeline\n```\n\n### Fields shared by both responses (slots 3-6, unchanged by the adapter)\n\nReturned in the canonical order: cognitive payload, falsification test, negative gate, target pattern.\n\n```\n[COGNITIVE PAYLOAD]\nAmplify: hofstadter buffer application; p90 baseline comparison; variance\n         multiplier scaling\nSuppress: best case anchoring; optimism bias\nCognitive Style: realistic duration estimation\nElasticity: coherence=risk adjusted timeline, expansion=conservative\n\n[FALSIFICATION TEST]\nIf time estimates reflect only the best-case scenario without verifying applying\nany buffer multiplier, duration calibration has defaulted to optimism.\n\n[NEGATIVE GATE]\nThe database migration will take two weeks: that's our best-case estimate and the\nteam is experienced, so there's no reason to add buffer. We'll hit the deadline\nif everything goes according to plan.\n\n[TARGET PATTERN]\nChallenge the two-week estimate: what do similar migrations actually take? If past\nprojects averaged four weeks at p90, the best-case anchor is dangerously optimistic.\nApply a variance multiplier for schema complexity, data volume, and rollback\ntesting: build buffer from the full distribution, not the happy path.\n```\n\nThis is the contract: dynamic returns the matched abstract operation; adaptive returns the same operation with `PROCEDURE` and topology nodes rewritten in terms of the caller's task (`DDL execution time`, `lock_blocking_app_queries`, `trigger-based backfill on a table this size`) while preserving the operation's structural identity, the safety language, and the cognitive payload verbatim.\n\n---\n\n## Configuration\n\n| Variable | Required | Purpose |\n|---|---|---|\n| `EJENTUM_API_KEY` | yes | API key from [ejentum.com/pricing](https://ejentum.com/pricing). |\n| `EJENTUM_API_URL` | no | Override the upstream URL. Default: `https://api.ejentum.com/harness/`. |\n\nThe MCP wrapper is stateless. No local logging, no telemetry, no third-party calls. The upstream API counts requests against the key for billing; the request body (the `query` string) is consumed for retrieval and not retained beyond the response.\n\n---\n\n## Errors\n\n| Status | Cause |\n|---|---|\n| `401 Unauthorized` | `EJENTUM_API_KEY` is unset, wrong, or expired. |\n| `403 Forbidden` | Adaptive mode requested on a tier that does not include it (trial or unrecognised). |\n| `429 Rate limit exceeded` | Tier quota for the period exhausted. |\n| Tool absent from client | Client did not reload after config change. Fully quit and reopen; on Claude Desktop check Help → Logs. |\n| `EJENTUM_API_KEY is not set` from the wrapper | Client did not pass the `env` block to the spawned MCP process. |\n\n---\n\n## Local development\n\n```bash\ngit clone https://github.com/ejentum/ejentum-mcp.git\ncd ejentum-mcp\nnpm install\ncp .env.example .env       # paste your EJENTUM_API_KEY\nnpm run dev\n```\n\nSmoke test against the live API:\n\n```bash\nnpm run build && npm run test:smoke\n```\n\nInteractive testing with MCP Inspector:\n\n```bash\nnpx @modelcontextprotocol/inspector npm run dev\n```\n\n---\n\n## Listings\n\n- [Glama](https://glama.ai/mcp/servers/ejentum/ejentum-mcp)\n- [mcp.so](https://mcp.so/server/ejentum-mcp/Ejentum)\n- [npm](https://www.npmjs.com/package/ejentum-mcp): `npm install -g ejentum-mcp`\n\n[![ejentum-mcp MCP server](https://glama.ai/mcp/servers/ejentum/ejentum-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ejentum/ejentum-mcp)\n\n## Links\n\n- [Ejentum documentation](https://ejentum.com/docs)\n- [Method](https://ejentum.com/docs/method)\n- [n8n integration](https://ejentum.com/docs/n8n_guide)\n- [Claude Code integration](https://ejentum.com/docs/claude_code_guide)\n- [Pricing](https://ejentum.com/pricing)\n- [info@ejentum.com](mailto:info@ejentum.com)\n\n## License\n\nMIT. See [LICENSE](./LICENSE).\n",
  "bytes": 17895,
  "sha": "03e54f9a0ee3a4f348b13687a7926d851b9dddfe3f70240d3a1dff3e82946250",
  "repo_slug": "ejentum/ejentum-mcp",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_ejentum_ejentum_mcp_246825c0/readme"
}