npm install ejentum-mcp

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

claude mcp add ejentum -e EJENTUM_API_KEY=ej_... -- npx -y ejentum-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" }

[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

[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

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

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

npm run build && npm run test:smoke

npx @modelcontextprotocol/inspector npm run dev