ejentum-mcp

Arnés de razonamiento para IA agéntica: 4 modos cognitivos (razonamiento, código, anti-engaño, memoria), 679 habilidades diseñadas servidas como herramientas MCP, inyección de andamiaje en tiempo de ejecución.

GitHub

Prueba este MCPPatrocinado

Documentación

ejentum-mcp

Servidor MCP que mejora el razonamiento de LLM en tareas complejas, de múltiples pasos o con múltiples restricciones. Antes de que el agente genere, llama a una de ocho herramientas para recuperar una operación cognitiva: un procedimiento estructurado (pasos numerados con el patrón de fallo a rechazar y una prueba de falsación) junto con una topología de razonamiento ejecutable (un DAG de esos pasos con compuertas de decisión, ramas paralelas, bucles acotados, salidas meta-cognitivas y rutas de escape). El agente lee ambas capas antes de producir su respuesta.

Ocho herramientas divididas en dos modos de recuperación:

Dinámico (4 herramientas: reasoning, code, anti-deception, memory): la operación abstracta top-1 de una biblioteca de 679, seleccionada por coincidencia semántica con la cadena query. Disponible en todos los niveles, incluida la prueba gratuita de 30 días.
Adaptativo (4 herramientas: adaptive-reasoning, adaptive-code, adaptive-anti-deception, adaptive-memory): el mismo grupo de recuperación, pero un LLM adaptador reescribe cada paso y nodo del DAG en la operación coincidente con identificadores específicos de la tarea (p. ej., extract_duration_estimates se convierte en extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)). Añade ~2-3 s de latencia; requiere el nivel Go o Super.

Dos rutas de instalación usan el mismo EJENTUM_API_KEY:

Stdio vía npx -y ejentum-mcp para Claude Desktop, Cursor, Windsurf, Codex CLI, Claude Code, Cline, Continue y cualquier cliente que lance servidores MCP como subprocesos.
Streamable HTTP alojado en https://api.ejentum.com/mcp para n8n MCP Client y cualquier cliente HTTP-MCP. Envía Authorization: Bearer YOUR_EJENTUM_API_KEY.

Instalación

Necesitas:

Una clave API de Ejentum. Prueba gratuita de 30 días (sin tarjeta) en ejentum.com/pricing.
Node.js 18+.

Instalar desde npm

npm install ejentum-mcp

O salta la instalación y refiérelo con npx -y ejentum-mcp directamente en la configuración de tu cliente (se muestra abajo).

Instalación manual

Claude Desktop

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

Reinicia Claude Desktop. Las ocho herramientas aparecen en el selector de herramientas.

Cursor / Windsurf

Abre la configuración de MCP → Añadir nuevo servidor MCP → pega el mismo bloque ejentum de arriba.

Claude Code (CLI)

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

Nodo n8n MCP Client

Añade un nodo MCP Client, transporte stdio, comando npx, argumentos ["-y", "ejentum-mcp"], entorno { "EJENTUM_API_KEY": "ej_..." }.

Contrato de cable

El servidor MCP stdio y el endpoint alojado ambos hacen proxy al mismo upstream:

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" }

La respuesta es un array de longitud 1 con una única clave que coincide con la solicitud mode. Usa acceso por corchetes (result[0]["anti-deception"]) para las claves con guiones; el acceso por punto interpreta el guion como resta en JavaScript y acceso de atributo en Python.

La cadena de inyección es texto plano que contiene siete campos. Consulta Estructura de campos abajo.

Inventario de herramientas

Dinámico (recuperación única, todos los niveles incluida la prueba de 30 días)

Nombre de herramienta	Cadena de modo	Tamaño de biblioteca
`reasoning`	`reasoning`	311 operaciones en abstracción, tiempo, causalidad, simulación, espacial, metacognición
`code`	`code`	128 operaciones en la capa de ingeniería de software
`anti-deception`	`anti-deception`	139 operaciones en sicofanía, alucinación, engaño, encuadre adversarial, juicio, control ejecutivo
`memory`	`memory`	101 operaciones en la capa de percepción (orientada a filtros; no llamar para extracción de hechos)

Adaptativo (recuperación top-k + reescritura por LLM adaptador; requiere nivel Go o Super)

Nombre de herramienta	Cadena de modo	Comportamiento vs dinámico
`adaptive-reasoning`	`adaptive-reasoning`	Mismo grupo de recuperación, top-5 luego selector, luego el LLM adaptador reescribe los campos PROCEDURE y REASONING TOPOLOGY con identificadores específicos de la tarea. Añade ~2-3 s de latencia.
`adaptive-code`	`adaptive-code`	Igual que arriba para la biblioteca de código.
`adaptive-anti-deception`	`adaptive-anti-deception`	Igual que arriba para la biblioteca anti-engaño.
`adaptive-memory`	`adaptive-memory`	Igual que arriba para la biblioteca de memoria.

Cada herramienta toma un argumento, query (cadena, 1-2 frases que describen la tarea). Devuelve la cadena de inyección.

Estructura de campos de una inyección

Cada registro recuperado contiene siete bloques etiquetados más una carga cognitiva. El conjunto exacto de etiquetas varía según el modo:

Los campos aparecen en este orden fijo en cada respuesta. Cada modo usa su propia etiqueta para la misma ranura (p. ej., [PROCEDURE] en razonamiento corresponde a [ENGINEERING PROCEDURE] en código):

Orden	Ranura	Etiquetas por modo	Contenido
1	Procedimiento	`[PROCEDURE]` (razonamiento) · `[ENGINEERING PROCEDURE]` (código) · `[INTEGRITY PROCEDURE]` (anti-engaño) · `[SHARPENING PROCEDURE]` (memoria)	Pasos numerados que el modelo ejecuta.
2	Topología	`[REASONING TOPOLOGY]` (razonamiento) · `[REASONING TOPOLOGY]` (código) · `[DETECTION TOPOLOGY]` (anti-engaño) · `[PERCEPTION TOPOLOGY]` (memoria)	Especificación del DAG. Consulta Sintaxis del DAG.
3	Carga cognitiva	`Amplify:` / `Suppress:` / `Cognitive Style:` / `Elasticity:` (todos los modos)	Vectores de tendencia y sugerencias de estilo de ejecución.
4	Verificación	`[FALSIFICATION TEST]` (razonamiento) · `[VERIFICATION]` (código) · `[INTEGRITY CHECK]` (anti-engaño) · `[PERCEPTION CHECK]` (memoria)	Autocomprobación que el modelo ejecuta tras redactar.
5	Patrón de fallo	`[NEGATIVE GATE]` (razonamiento) · `[CODE FAILURE]` (código) · `[DECEPTION PATTERN]` (anti-engaño) · `[PERCEPTION FAILURE]` (memoria)	El patrón de fallo a rechazar.
6	Forma correcta	`[TARGET PATTERN]` (razonamiento) · `[CORRECT PATTERN]` (código) · `[HONEST BEHAVIOR]` (anti-engaño) · `[CLEAR SIGNAL]` (memoria)	Cómo se ve una respuesta correcta.

El mismo orden de seis ranuras se mantiene tanto para las variantes dinámicas como adaptativas de cada modo. En las respuestas adaptativas, el LLM adaptador reescribe las ranuras 1 y 2 (procedimiento y topología) con identificadores específicos de la tarea; las ranuras 3-6 se devuelven textualmente.

Sintaxis del DAG

El bloque de topología usa una notación de cadena plana:

Token	Significado
`Sn:label`	Nodo de paso. Numerado, secuencial por defecto.
`Gn{?}`	Compuerta de decisión. Ramifica `--yes->` / `--no->`.
`N{...}`	Ancla negativa. Activa en toda la rama; el patrón de fallo etiquetado se rechaza.
`M{...}`	Nodo meta-cognitivo. El modelo se pausa, evalúa el rastro, luego `RE-ENTER` en un paso nombrado.
`FREEFORM{...}`	Ruta de escape. El modelo sale del DAG prescrito cuando el plan deja de encajar; regresa a un paso o `OUT`.
`FIXED_POINT[...]`	Una cantidad mantenida estable en toda la rama.
`for_each:` / `LOOP[...]`	Iteración acotada.
`C{expr}`	Valor calculado usado aguas abajo.
`OUT:label`	Nodo terminal.

El DAG está pensado para ser leído por el LLM como un esquema estructurado de la ruta de razonamiento, no ejecutado por un runtime anfitrión. La estructura de pasos etiquetados persiste en ventanas de contexto largas donde las especificaciones de razonamiento solo en prosa pierden prominencia de recuperación.

Ejemplo canónico: dinámico vs adaptativo en la misma consulta

Consulta (usada para ambas llamadas):

Evalúa si un plan de migración de base de datos que añade una columna NOT NULL a una tabla de 50M filas es seguro bajo escrituras concurrentes, dado que la estrategia de relleno usa un valor por defecto basado en disparadores.

El selector coincidió con la misma operación en ambas llamadas ("estimación de duración realista" con el buffer de Hofstadter). Los campos [NEGATIVE GATE], [TARGET PATTERN], [FALSIFICATION TEST] y [COGNITIVE PAYLOAD] son idénticos entre las dos respuestas (el adaptador no los reescribe). Los campos [PROCEDURE] y [REASONING TOPOLOGY] difieren: la respuesta adaptativa reemplaza identificadores abstractos por específicos de la tarea.

Respuesta dinámica `reasoning` (truncada a los campos que difieren)

[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

Respuesta adaptativa `adaptive-reasoning` (misma consulta, misma operación seleccionada)

[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

Campos compartidos por ambas respuestas (ranuras 3-6, sin cambios por el adaptador)

Devueltos en el orden canónico: carga cognitiva, prueba de falsación, compuerta negativa, patrón objetivo.

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

Este es el contrato: dinámico devuelve la operación abstracta coincidente; adaptativo devuelve la misma operación con PROCEDURE y nodos de topología reescritos en términos de la tarea del llamante (DDL execution time, lock_blocking_app_queries, trigger-based backfill on a table this size) mientras preserva la identidad estructural de la operación, el lenguaje de seguridad y la carga cognitiva textualmente.

Configuración

Variable	Requerida	Propósito
`EJENTUM_API_KEY`	sí	Clave API de ejentum.com/pricing.
`EJENTUM_API_URL`	no	Sobrescribe la URL del upstream. Por defecto: `https://api.ejentum.com/harness/`.

El envoltorio MCP no tiene estado. Sin registro local, sin telemetría, sin llamadas a terceros. La API upstream cuenta las solicitudes contra la clave para facturación; el cuerpo de la solicitud (la cadena query) se consume para la recuperación y no se retiene más allá de la respuesta.

Errores

Estado	Causa
`401 Unauthorized`	`EJENTUM_API_KEY` no está configurado, es incorrecto o ha expirado.
`403 Forbidden`	Modo adaptativo solicitado en un nivel que no lo incluye (prueba o no reconocido).
`429 Rate limit exceeded`	Cuota del nivel agotada para el período.
Herramienta ausente del cliente	El cliente no recargó después del cambio de configuración. Sal y vuelve a abrir completamente; en Claude Desktop revisa Ayuda → Registros.
`EJENTUM_API_KEY is not set` del envoltorio	El cliente no pasó el bloque `env` al proceso MCP generado.

Desarrollo local

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

Prueba de humo contra la API en vivo:

npm run build && npm run test:smoke

Pruebas interactivas con MCP Inspector:

npx @modelcontextprotocol/inspector npm run dev

ejentum-mcp

Documentación

ejentum-mcp

Instalación

Instalar desde npm

Instalación manual

Claude Desktop

Cursor / Windsurf

Claude Code (CLI)

Nodo n8n MCP Client

Contrato de cable

Inventario de herramientas

Dinámico (recuperación única, todos los niveles incluida la prueba de 30 días)

Adaptativo (recuperación top-k + reescritura por LLM adaptador; requiere nivel Go o Super)

Estructura de campos de una inyección

Sintaxis del DAG

Ejemplo canónico: dinámico vs adaptativo en la misma consulta

Respuesta dinámica `reasoning` (truncada a los campos que difieren)

Respuesta adaptativa `adaptive-reasoning` (misma consulta, misma operación seleccionada)

Campos compartidos por ambas respuestas (ranuras 3-6, sin cambios por el adaptador)

Configuración

Errores

Desarrollo local

Listados

Enlaces

Licencia

ejentum-mcp

Documentación

ejentum-mcp

Instalación

Instalar desde npm

Instalación manual

Claude Desktop

Cursor / Windsurf

Claude Code (CLI)

Nodo n8n MCP Client

Contrato de cable

Inventario de herramientas

Dinámico (recuperación única, todos los niveles incluida la prueba de 30 días)

Adaptativo (recuperación top-k + reescritura por LLM adaptador; requiere nivel Go o Super)

Estructura de campos de una inyección

Sintaxis del DAG

Ejemplo canónico: dinámico vs adaptativo en la misma consulta

Respuesta dinámica reasoning (truncada a los campos que difieren)

Respuesta adaptativa adaptive-reasoning (misma consulta, misma operación seleccionada)

Campos compartidos por ambas respuestas (ranuras 3-6, sin cambios por el adaptador)

Configuración

Errores

Desarrollo local

Listados

Enlaces

Licencia

Respuesta dinámica `reasoning` (truncada a los campos que difieren)

Respuesta adaptativa `adaptive-reasoning` (misma consulta, misma operación seleccionada)