ejentum-mcp

Arnês de raciocínio para IA agentiva: 4 modos cognitivos (raciocínio, código, anti-engano, memória), 679 habilidades projetadas servidas como ferramentas MCP, injeção de scaffold em tempo de execução.

GitHub

Experimente este MCPPatrocinado

Documentação

ejentum-mcp

Servidor MCP que melhora o raciocínio de LLMs em tarefas complexas, de múltiplas etapas ou com múltiplas restrições. Antes de o agente gerar, ele chama uma das oito ferramentas para recuperar uma operação cognitiva: um procedimento estruturado (etapas numeradas com o padrão de falha a recusar e um teste de falsificação) emparelhado com uma topologia de raciocínio executável (um DAG dessas etapas com portas de decisão, ramificações paralelas, loops limitados, saídas metacognitivas e caminhos de escape). O agente lê ambas as camadas antes de produzir sua resposta.

Oito ferramentas divididas em dois modos de recuperação:

Dinâmico (4 ferramentas: reasoning, code, anti-deception, memory): a operação abstrata top-1 de uma biblioteca de 679, selecionada por correspondência semântica na string query. Disponível em todos os níveis, incluindo o teste gratuito de 30 dias.
Adaptativo (4 ferramentas: adaptive-reasoning, adaptive-code, adaptive-anti-deception, adaptive-memory): o mesmo pool de recuperação, mas um LLM adaptador reescreve cada etapa e nó do DAG na operação correspondente com identificadores específicos da tarefa (por exemplo, extract_duration_estimates torna-se extract_migration_duration_estimates(DDL_time|backfill_time|trigger_overhead|lock_hold_time)). Adiciona ~2-3 s de latência; requer o nível Go ou Super.

Dois caminhos de instalação usam o mesmo EJENTUM_API_KEY:

Stdio via npx -y ejentum-mcp para Claude Desktop, Cursor, Windsurf, Codex CLI, Claude Code, Cline, Continue e qualquer cliente que execute servidores MCP como subprocessos.
Hosted Streamable HTTP em https://api.ejentum.com/mcp para n8n MCP Client e qualquer cliente HTTP-MCP. Envie Authorization: Bearer YOUR_EJENTUM_API_KEY.

Instalação

Você precisa de:

Uma chave de API Ejentum. Teste gratuito de 30 dias (sem cartão) em ejentum.com/pricing.
Node.js 18+.

Instalar via npm

npm install ejentum-mcp

Ou pule a instalação e referencie com npx -y ejentum-mcp diretamente na configuração do seu cliente (mostrado abaixo).

Instalação manual

Claude Desktop

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

Reinicie o Claude Desktop. As oito ferramentas aparecem no seletor de ferramentas.

Cursor / Windsurf

Abra as configurações de MCP → Adicionar novo servidor MCP → cole o mesmo bloco ejentum acima.

Claude Code (CLI)

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

Nó MCP Client do n8n

Adicione um nó MCP Client, transporte stdio, comando npx, argumentos ["-y", "ejentum-mcp"], env { "EJENTUM_API_KEY": "ej_..." }.

Contrato de comunicação

O servidor MCP stdio e o endpoint hospedado ambos fazem proxy para o mesmo 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" }

A resposta é um array de comprimento 1 com uma única chave correspondente à solicitação mode. Use acesso por colchetes (result[0]["anti-deception"]) para chaves com hífen; acesso por ponto interpreta o hífen como subtração em JavaScript e acesso de atributo em Python.

A string de injeção é texto simples contendo sete campos. Veja Estrutura de campos abaixo.

Inventário de ferramentas

Dinâmico (recuperação única, todos os níveis incluindo o teste de 30 dias)

Nome da ferramenta	String de modo	Tamanho da biblioteca
`reasoning`	`reasoning`	311 operações em abstração, tempo, causalidade, simulação, espacial, metacognição
`code`	`code`	128 operações na camada de engenharia de software
`anti-deception`	`anti-deception`	139 operações em bajulação, alucinação, engano, enquadramento adversarial, julgamento, controle executivo
`memory`	`memory`	101 operações na camada de percepção (orientada a filtros; não chame para extração de fatos)

Adaptativo (recuperação top-k + reescrita por LLM adaptador; nível Go ou Super necessário)

Nome da ferramenta	String de modo	Comportamento vs dinâmico
`adaptive-reasoning`	`adaptive-reasoning`	Mesmo pool de recuperação, top-5 e seletor, depois o LLM adaptador reescreve os campos PROCEDURE e REASONING TOPOLOGY com identificadores específicos da tarefa. Adiciona ~2-3 s de latência.
`adaptive-code`	`adaptive-code`	O mesmo acima para a biblioteca de código.
`adaptive-anti-deception`	`adaptive-anti-deception`	O mesmo acima para a biblioteca anti-engano.
`adaptive-memory`	`adaptive-memory`	O mesmo acima para a biblioteca de memória.

Cada ferramenta recebe um argumento, query (string, 1-2 frases descrevendo a tarefa). Retorna a string de injeção.

Estrutura de campos de uma injeção

Cada registro recuperado contém sete blocos rotulados mais um payload cognitivo. O conjunto exato de rótulos varia por modo:

Os campos aparecem nesta ordem fixa em cada resposta. Cada modo usa seu próprio rótulo para o mesmo slot (por exemplo, [PROCEDURE] em raciocínio corresponde a [ENGINEERING PROCEDURE] em código):

Ordem	Slot	Rótulos por modo	Conteúdo
1	Procedimento	`[PROCEDURE]` (raciocínio) · `[ENGINEERING PROCEDURE]` (código) · `[INTEGRITY PROCEDURE]` (anti-engano) · `[SHARPENING PROCEDURE]` (memória)	Etapas numeradas que o modelo executa.
2	Topologia	`[REASONING TOPOLOGY]` (raciocínio) · `[REASONING TOPOLOGY]` (código) · `[DETECTION TOPOLOGY]` (anti-engano) · `[PERCEPTION TOPOLOGY]` (memória)	Especificação do DAG. Veja Sintaxe do DAG.
3	Payload cognitivo	`Amplify:` / `Suppress:` / `Cognitive Style:` / `Elasticity:` (todos os modos)	Vetores de tendência e dicas de estilo de execução.
4	Verificação	`[FALSIFICATION TEST]` (raciocínio) · `[VERIFICATION]` (código) · `[INTEGRITY CHECK]` (anti-engano) · `[PERCEPTION CHECK]` (memória)	Autoverificação que o modelo executa após o rascunho.
5	Padrão de falha	`[NEGATIVE GATE]` (raciocínio) · `[CODE FAILURE]` (código) · `[DECEPTION PATTERN]` (anti-engano) · `[PERCEPTION FAILURE]` (memória)	O padrão de falha a recusar.
6	Forma correta	`[TARGET PATTERN]` (raciocínio) · `[CORRECT PATTERN]` (código) · `[HONEST BEHAVIOR]` (anti-engano) · `[CLEAR SIGNAL]` (memória)	Como uma resposta correta se parece.

A mesma ordem de seis slots vale para variantes dinâmicas e adaptativas de cada modo. Em respostas adaptativas, o LLM adaptador reescreve os slots 1 e 2 (procedimento e topologia) com identificadores específicos da tarefa; os slots 3-6 são retornados verbatim.

Sintaxe do DAG

O bloco de topologia usa uma notação de string plana:

Token	Significado
`Sn:label`	Nó de etapa. Numerado, sequencial por padrão.
`Gn{?}`	Porta de decisão. Ramifica `--yes->` / `--no->`.
`N{...}`	Âncora negativa. Ativa em toda a ramificação; o padrão de falha rotulado é recusado.
`M{...}`	Nó metacognitivo. O modelo pausa, avalia o rastreamento, então `RE-ENTER` em uma etapa nomeada.
`FREEFORM{...}`	Caminho de escape. O modelo sai do DAG prescrito quando o plano deixa de se ajustar; retorna a uma etapa ou `OUT`.
`FIXED_POINT[...]`	Uma quantidade mantida estável em toda a ramificação.
`for_each:` / `LOOP[...]`	Iteração limitada.
`C{expr}`	Valor calculado usado downstream.
`OUT:label`	Nó terminal.

O DAG deve ser lido pelo LLM como um esboço estruturado do caminho de raciocínio, não executado por um runtime host. A estrutura de etapas rotuladas persiste em janelas de contexto longas onde especificações de raciocínio apenas em prosa perdem saliência de recuperação.

Exemplo canônico: dinâmico vs adaptativo na mesma consulta

Consulta (usada para ambas as chamadas):

Avalie se um plano de migração de banco de dados que adiciona uma coluna NOT NULL a uma tabela de 50M de linhas é seguro sob escritas concorrentes, dado que a estratégia de backfill usa um default baseado em trigger.

O seletor correspondeu à mesma operação em ambas as chamadas ("estimativa de duração realista" com o buffer de Hofstadter). Os campos [NEGATIVE GATE], [TARGET PATTERN], [FALSIFICATION TEST] e [COGNITIVE PAYLOAD] são idênticos entre as duas respostas (o adaptador não os reescreve). Os campos [PROCEDURE] e [REASONING TOPOLOGY] diferem: a resposta adaptativa substitui identificadores abstratos por específicos da tarefa.

Resposta dinâmica `reasoning` (truncada para os campos que diferem)

[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

Resposta adaptativa `adaptive-reasoning` (mesma consulta, mesma operação selecionada)

[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 compartilhados por ambas as respostas (slots 3-6, inalterados pelo adaptador)

Retornados na ordem canônica: payload cognitivo, teste de falsificação, porta negativa, padrão alvo.

[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 é o contrato: dinâmico retorna a operação abstrata correspondente; adaptativo retorna a mesma operação com PROCEDURE e nós de topologia reescritos em termos da tarefa do chamador (DDL execution time, lock_blocking_app_queries, trigger-based backfill on a table this size) preservando a identidade estrutural da operação, a linguagem de segurança e o payload cognitivo verbatim.

Configuração

Variável	Obrigatória	Propósito
`EJENTUM_API_KEY`	sim	Chave de API de ejentum.com/pricing.
`EJENTUM_API_URL`	não	Substitui a URL upstream. Padrão: `https://api.ejentum.com/harness/`.

O wrapper MCP é sem estado. Sem registro local, sem telemetria, sem chamadas de terceiros. A API upstream conta solicitações contra a chave para cobrança; o corpo da solicitação (a string query) é consumido para recuperação e não é retido além da resposta.

Erros

Status	Causa
`401 Unauthorized`	`EJENTUM_API_KEY` não definido, incorreto ou expirado.
`403 Forbidden`	Modo adaptativo solicitado em um nível que não o inclui (teste ou não reconhecido).
`429 Rate limit exceeded`	Cota do nível para o período esgotada.
Ferramenta ausente no cliente	O cliente não recarregou após a mudança de configuração. Saia e reabra completamente; no Claude Desktop verifique Ajuda → Logs.
`EJENTUM_API_KEY is not set` do wrapper	O cliente não passou o bloco `env` para o processo MCP gerado.

Desenvolvimento 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

Teste de fumaça contra a API ao vivo:

npm run build && npm run test:smoke

Teste interativo com MCP Inspector:

npx @modelcontextprotocol/inspector npm run dev

Listagens

Glama
mcp.so
npm: npm install -g ejentum-mcp

Licença

MIT. Veja LICENSE.

ejentum-mcp

Documentação

ejentum-mcp

Instalação

Instalar via npm

Instalação manual

Claude Desktop

Cursor / Windsurf

Claude Code (CLI)

Nó MCP Client do n8n

Contrato de comunicação

Inventário de ferramentas

Dinâmico (recuperação única, todos os níveis incluindo o teste de 30 dias)

Adaptativo (recuperação top-k + reescrita por LLM adaptador; nível Go ou Super necessário)

Estrutura de campos de uma injeção

Sintaxe do DAG

Exemplo canônico: dinâmico vs adaptativo na mesma consulta

Resposta dinâmica reasoning (truncada para os campos que diferem)

Resposta adaptativa adaptive-reasoning (mesma consulta, mesma operação selecionada)

Campos compartilhados por ambas as respostas (slots 3-6, inalterados pelo adaptador)

Configuração

Erros

Desenvolvimento local

Listagens

Links

Licença

Resposta dinâmica `reasoning` (truncada para os campos que diferem)

Resposta adaptativa `adaptive-reasoning` (mesma consulta, mesma operação selecionada)