kemdiCode MCP

Cognición Persistente, Cluster Bus & Magistrale, Orquestación Paralela Multi-Agente con Monitoreo en Vivo para Asistentes de Codificación con IA

kemdiCode MCP es un servidor de Model Context Protocol que extiende los asistentes de codificación con IA con cognición persistente, orquestación multi-agente, comunicación distribuida entre clústeres y compactación de contexto. 63 herramientas en 15 categorías, respaldadas por Redis para estado entre sesiones y 8 proveedores de LLM para ejecución de IA integrada.

Pipeline de compactación inspirado en Lorenz — Detección de Fases mediante secciones de Poincaré, Compresión de Órbitas mediante deduplicación de ciclos de atractores y puntuación de impacto de perturbación CTC — mantiene la continuidad del razonamiento a través de los límites de la ventana de contexto.

Cluster Bus & Magistrale — bus de dos capas (ClusterBus L3 para Redis Pub/Sub entre clústeres, GlobalEventBus L1 para eventos en proceso) con 18 tipos de señales, enrutamiento basado en etiquetas de MetaRouter, puentes anti-amplificación y LLM Magistrale para ejecución distribuida de prompts entre clústeres (4 estrategias: first-wins, best-of-n, consensus, fallback-chain).

The Nine Minds — nueve agentes cognitivos especializados (Socratic, Ontologist, Seed Architect, Evaluator, Contrarian, Hacker, Simplifier, Researcher, Architect), cada uno con un modo de pensamiento diferente. Inspirado en Ouroboros de Harry Munro. Se cargan bajo demanda, nunca se precargan.

741 pruebas en 33 archivos de prueba. Funciona con Claude Code, Cursor, Windsurf, VS Code, Zed y cualquier cliente compatible con MCP.

Instalación

bun install -g kemdicode-mcp

claude mcp add kemdicode-mcp -- kemdicode-mcp --stdio

{
  "mcpServers": {
    "kemdicode-mcp": {
      "command": "kemdicode-mcp",
      "args": ["--stdio"]
    }
  }
}

{
  "mcpServers": {
    "kemdicode-mcp": {
      "command": "kemdicode-mcp",
      "args": ["--stdio"]
    }
  }
}

{
  "mcp": {
    "servers": {
      "kemdicode-mcp": {
        "command": "kemdicode-mcp",
        "args": ["--stdio"]
      }
    }
  }
}

{
  "context_servers": {
    "kemdicode-mcp": {
      "command": {
        "path": "kemdicode-mcp",
        "args": ["--stdio"]
      }
    }
  }
}

{
  "mcpServers": {
    "kemdicode-mcp": {
      "command": "kemdicode-mcp",
      "args": ["--stdio"]
    }
  }
}

kemdicode-mcp --port 3100

# Docker (recommended)
docker run -d -p 6379:6379 redis:alpine

# macOS
brew install redis && brew services start redis

# Debian/Ubuntu
sudo apt install redis-server && sudo systemctl start redis

git clone https://github.com/kemdi-pl/kemdicode-mcp.git
cd kemdicode-mcp
bun install && bun run build && bun run start

Configuración

Proveedores de LLM

kemdiCode admite 8 proveedores de LLM con una sintaxis unificada provider:model:thinking.

Control de tokens de pensamiento:

o:o3:high                     # OpenAI reasoning effort (low/medium/high)
a:claude-sonnet-4-6:4k        # Anthropic thinking budget (4096 tokens)
g:gemini-2.5-flash:8k         # Gemini thinking budget (8192 tokens)

Endpoints personalizados (recarga en caliente en tiempo de ejecución):

ai-config --action add-custom --name minimax --baseURL https://api.minimax.io/v1 --apiKey sk-...
# Then use: custom:minimax:MiniMax-M2.5

Banderas de CLI

kemdicode-mcp [options]

  --stdio                 Stdio transport (subprocess mode for MCP clients)
  -m, --model <spec>      Primary AI model (provider:model:thinking)
  -f, --fallback <spec>   Fallback model on quota/error
  --port <n>              HTTP server port (default: 3100)
  --host <addr>           Bind address (default: 127.0.0.1)
  --redis-host <addr>     Redis host (default: 127.0.0.1)
  --redis-port <n>        Redis port (default: 6379)
  --no-context            Disable Redis context sharing
  --compact               Minimal output

Referencia de Herramientas

63 herramientas en 15 categorías. Las herramientas consolidadas usan un parámetro action (p. ej., task action=create|get|list|update|delete).

Arquitectura

Bus de Eventos (2 Capas)

L3  ClusterBus     Redis Pub/Sub cross-process signaling
                   18 signal types, 4 send modes (unicast/broadcast/routed/multicast)
                   HMAC auth, bloom filter dedup, backpressure, circuit breaker
    ----bridges--> hop limit 5, source prefix guard
L1  GlobalEventBus In-process async events, namespaced, max chain depth 8
                   Redis bridge for cross-session propagation

Compactación de Contexto Lorenz

Tres algoritmos para mantener la continuidad del razonamiento a través de los límites de compactación:

1. Detección de Fases — Análisis de secciones de Poincaré. La divergencia de Jensen-Shannon consecutiva identifica transiciones de tema. Los límites de fase contienen la máxima información sobre la trayectoria del razonamiento.

2. Compresión de Órbitas — Detección de ciclos de atractores de Lorenz. Matriz de similitud coseno TF-IDF NxN con búsqueda codiciosa de ciclos (longitud 2-10, mínimo 2 repeticiones). Conserva el primer ciclo, elimina duplicados.

3. Impacto de Perturbación — JSD(full_context, context_without_item) cuantifica la contribución de cada elemento. Los elementos de alto impacto son anclas causales que sobreviven a la compactación.

The Nine Minds

Nueve agentes cognitivos especializados, cada uno con un modo de pensamiento diferente. Inspirado en Ouroboros de Harry Munro:

Usa cualquier Mind como parámetro agent: ask-ai --agent socratic --prompt "...". Compónelos para análisis multi-perspectiva: Socratic → Ontologist → Seed Architect (progresión dialéctica).

Bucle Agéntico

Ejecución autónoma de agentes con generación de sub-agentes (profundidad máxima 2, presupuesto global 10), inyección de contexto de archivos mediante sintaxis @path y trazabilidad completa del ID de orquestación.

Agentes Paralelos — Lanza 2-10 agentes en paralelo mediante agent-orchestrate --parallel. Cada uno recibe un orchestrationId único, rastreado en tiempo real mediante Redis y caché en memoria. Resultados agregados mediante Promise.allSettled.

Monitoreo en Vivo — Consulta el estado de orquestación mientras los agentes se ejecutan (MCP bloquea durante las llamadas a herramientas, así que usa HTTP):

# List all active orchestrations
curl http://localhost:3100/orchestrations

# Get specific orchestration status
curl http://localhost:3100/orchestrations/<id>

# Or via MCP tool (when not blocked)
monitor --view orchestrations

Trazabilidad del ID de Orquestación — Cada bucle agéntico recibe un UUID. Los sub-agentes referencian al padre mediante parentOrchestrationId. Todos los registros de cognición (decisiones, confianza, intenciones, errores, críticas, traspasos) llevan orchestrationId para trazabilidad completa en jerarquías de agentes anidadas.

Acceso a Herramientas — Todas las herramientas de kemdiCode están disponibles para los agentes por defecto (solo lectura, kanban, cadenas de pensamiento — sin shell/escritura de archivos). Usa allowedTools o blockedTools para personalizar por agente.

Modelo de Concurrencia

• Aislamiento por sesión mediante AsyncLocalStorage (se propaga a través de cadenas asíncronas)
• Transacciones de Redis para mutaciones de estado de tareas (MULTI/EXEC, scripts Lua)
• Bloqueos distribuidos con SET NX PX, liberación Lua CAS, retroceso de 3 reintentos

Uso en el Mundo Real

Las herramientas de kemdiCode funcionan en tres niveles. Aquí hay escenarios prácticos que un desarrollador encuentra a diario.

Nivel 1: Herramientas sin Estado (sin agentes de IA)

Claude Code (o Cursor, etc.) llama a las herramientas de kemdiCode directamente — sin IA integrada, solo cognición estructurada e inteligencia de código.

Escenario: "Sigo encontrando el mismo error de timeout de Redis en varios proyectos"

# 1. Check if you've seen this before
error-pattern action=match errorType="redis-timeout"
# → Returns: "Pattern found: connection pool exhaustion under load.
#    Fix: set maxRetriesPerRequest=3, enable enableOfflineQueue=false"

# 2. It's a new variant — record it
error-pattern action=record \
  errorType="redis-timeout" \
  pattern="ETIMEDOUT after 200 concurrent writes in bull queue" \
  fix="Switch from ioredis default to pooled connection with family=6 on k8s"

# 3. Track the decision
decision-journal action=record \
  question="How to handle Redis under Bull queue load?" \
  options='["connection pool","Redis Cluster","separate Redis instance"]' \
  chosen="connection pool" \
  reasoning="Cluster adds ops complexity, separate instance adds cost"

Escenario: "Planificación de sprint — organiza 15 tareas entre 3 desarrolladores"

# Create workspace + board
workspace action=create name="Q1 Auth Rewrite"
board action=create name="Sprint 12" workspaceId=<ws-id>

# Batch create tasks
task action=create boardId=<board-id> title="Migrate session store to Redis" priority=high labels='["backend"]'
task action=create boardId=<board-id> title="Add PKCE flow to OAuth" priority=high labels='["security"]'
task action=create boardId=<board-id> title="Write E2E tests for login" priority=medium labels='["testing"]'
# ... more tasks

# Assign and track
task action=assign taskId=<id> assignee="alice"
task action=update taskId=<id> status="in-progress"
board action=status boardId=<board-id>
# → Shows kanban: 3 todo, 2 in-progress, 1 done

Escenario: "Navegar por un código base desconocido después de unirse a un equipo"

# Find where auth middleware is defined
find-definition --symbol "authMiddleware" --path "@src/"

# Find all places it's used
find-references --symbol "authMiddleware" --path "@src/"

# Search by concept, not just text
semantic-search --query "rate limiting per user" --path "@src/"

# Persist findings for next session
memory action=write name="auth-architecture" \
  content="authMiddleware in src/middleware/auth.ts, used in 14 routes. Rate limiting in src/middleware/rateLimit.ts uses sliding window with Redis MULTI."

Nivel 2: Agentes de IA (ejecución de LLM integrada)

kemdiCode llama a LLMs externos internamente para razonar, analizar y generar. La IA de tu IDE no hace este trabajo — los propios agentes de kemdiCode lo hacen.

Escenario: "Depurar por qué el tiempo de respuesta de la API pasó de 50ms a 3 segundos"

# Start structured reasoning with the plan agent
agent-orchestrate \
  --agent plan \
  --task "Analyze why GET /api/users went from 50ms to 3s. Check @src/routes/users.ts and @src/services/userService.ts for N+1 queries, missing indexes, or unnecessary joins." \
  --sessionId "debug-perf" \
  --maxIterations 10 \
  --enableCognition true

# The agent autonomously:
# 1. Reads the files via find-definition / find-references
# 2. Identifies: userService.getAll() does 3 sequential DB calls
# 3. Records in error-pattern: "N+1 query in user list endpoint"
# 4. Records in decision-journal: "Consolidate to single JOIN query"
# 5. Returns: "Root cause: 3 sequential queries per user (N+1). Fix: replace
#    with single LEFT JOIN on user_roles and user_preferences."

Escenario: "¿Es buena idea nuestra propuesta de dividir en microservicios?"

Usa mind-chain — traspaso secuencial Mind-to-Mind donde cada Mind se basa en el anterior:

# One call — 4 Minds analyze in sequence, each seeing previous outputs
mind-chain \
  --composition custom \
  --minds '["architect", "contrarian", "researcher", "simplifier"]' \
  --prompt "Evaluate splitting the monolith at @src/ into auth-service, user-service, and notification-service. We have 3 developers and 45 shared models."

# Or use a predefined composition:
mind-chain --composition adversarial \
  --prompt "Should we split the monolith into microservices? @src/"

# Full review with 6 Minds + synthesis:
mind-chain --composition full-review \
  --prompt "Architecture decision: monolith vs microservices for @src/"

La cadena se ejecuta: Architect propone → Contrarian desafía → Researcher verifica hechos → Simplifier encuentra el camino pragmático → Synthesis combina todas las perspectivas.

Escenario: "Haz que 3 LLMs revisen un cambio de seguridad crítico"

# Send to GPT-4o, Claude, and Gemini in parallel
multi-prompt \
  --prompt "Review this OAuth implementation for security vulnerabilities: @src/auth/oauth.ts" \
  --models '["o:gpt-4.1", "a:claude-sonnet-4-6", "g:gemini-2.5-pro"]' \
  --agent evaluator

# Or use CEO-and-Board consensus
consensus-prompt \
  --prompt "Is this PKCE implementation correct and secure? @src/auth/pkce.ts" \
  --boardModels '["o:gpt-4.1", "g:gemini-2.5-pro", "d:deepseek-v3"]' \
  --ceoModel "a:claude-sonnet-4-6"
# → Board votes + CEO synthesizes a final verdict with reasoning

Nivel 3: Cluster Bus & Magistrale (orquestación distribuida de LLM)

Múltiples nodos de LLM se comunican mediante Redis Pub/Sub. Usa esto cuando necesites un contexto más amplio — enviando la misma pregunta a múltiples modelos con diferentes especializaciones.

Escenario: "Diseñar un limitador de tasa — obtener la mejor respuesta de 3 modelos"

# Dispatch to all registered clusters, pick the best response
cluster-bus-magistrale \
  --prompt "Design a distributed rate limiter for a REST API with 10K req/s. Must handle multi-region, be Redis-backed, and support per-user and per-IP limits. Include TypeScript implementation." \
  --strategy "best-of-n"

# Magistrale:
# 1. Sends the prompt to Cluster A (GPT-4.1), Cluster B (Claude), Cluster C (Gemini)
# 2. Each cluster runs PassController (multi-pass refinement)
# 3. Scores responses: quality 0.45, detail 0.25, relevance 0.15, latency -0.15
# 4. Returns the highest-scoring implementation

Escenario: "Decisión de arquitectura — necesito consenso, no solo una opinión"

# Require agreement between models
cluster-bus-magistrale \
  --prompt "For a real-time collaboration feature (like Google Docs), should we use CRDTs, OT, or a simpler last-write-wins approach? Team has 2 backend devs, deadline is 6 weeks." \
  --strategy "consensus"

# Consensus strategy:
# 1. All clusters generate independent responses
# 2. TF-IDF cosine similarity scoring between responses (threshold 0.3)
# 3. If agreement: returns consensus answer
# 4. If disagreement: returns all positions with similarity scores

Escenario: "Incidente de producción — necesito la respuesta más rápida posible"

# First model to respond wins
cluster-bus-magistrale \
  --prompt "Our PostgreSQL replication lag jumped to 30s. WAL sender is active, network is fine. What should we check first?" \
  --strategy "first-wins"

# Returns in ~1s from whichever model responds fastest

Escenario: "Análisis profundo de código — deja que los clústeres generen sus propios agentes"

# Each cluster spawns an autonomous agent with tool access
cluster-bus-magistrale \
  --prompt "Find potential race conditions in the authentication module" \
  --strategy "first-wins" \
  --orchestrate true \
  --orchestrateAgent "plan" \
  --orchestrateMaxIterations 8 \
  --orchestrateAllowedTools '["find-definition", "find-references", "semantic-search"]'

# Orchestration:
# 1. Magistrale dispatches to clusters with orchestrate payload
# 2. Each cluster spawns a full agentic loop (not just an LLM call)
# 3. Agent reasons, calls tools (find-definition, semantic-search), iterates
# 4. Returns structured analysis with tool call evidence

Desarrollo

bun install                    # Install dependencies
bun run build                  # Compile TypeScript
bun run dev                    # Hot reload
bun run test                   # Run 741 tests
bun run typecheck              # Type check
bun run lint                   # ESLint
bun run format                 # Prettier

Añadir Herramientas

1. Crea un archivo en src/tools/<category>/
2. Define el esquema Zod con .describe() por campo
3. Implementa la interfaz UnifiedTool
4. Registra mediante registerLazyTool() en src/tools/index.ts
5. Añade la anotación en src/tools/annotations-map.ts

Documentación

• Technical Whitepaper (PDF) — Compactación de Lorenz, Nine Minds, detección de fases de Poincaré, compresión de órbitas, 39 referencias (fuente LaTeX)
• Resumen de Arquitectura
• Arquitectura del Bus
• Ejemplos — Patrones de integración y flujos de trabajo

Licencia

GNU General Public License v3.0

Autor

Dawid Irzyk — dawid@kemdi.pl — Kemdi Sp. z o.o.