Kemdicode Mcp

永続的な認知、クラスター バスとマジストラーレ、AI コーディングアシスタント向けのライブモニタリングを備えた並列マルチエージェントオーケストレーション

kemdiCode MCP は、AI コーディングアシスタントに永続的な認知、マルチエージェントオーケストレーション、分散クラスター通信、コンテキスト圧縮を提供する Model Context Protocol サーバーです。Redis によるセッションをまたいだ状態管理と、組み込み AI 実行用の 8 種類の LLM プロバイダーを備え、15 カテゴリーにわたる 63 個のツールを提供します。

ローレンツに着想を得た圧縮パイプライン — ポアンカレ断面によるフェーズ検出、アトラクターサイクルの重複排除による軌道圧縮、CTC 摂動影響スコアリングによって、コンテキストウィンドウの境界を越えて推論の連続性を維持します。

クラスター バスとマジストラーレ — 18 種類のシグナル、タグベースの MetaRouter ルーティング、増幅防止ブリッジ、クラスター間でプロンプトを分散実行する LLM Magistrale（4 つの戦略：first-wins、best-of-n、consensus、fallback-chain）を備えた 2 層バス（クラスター間 Redis Pub/Sub 用の ClusterBus L3、プロセス内イベント用の GlobalEventBus L1）です。

The Nine Minds — それぞれ異なる思考モードを持つ、9 つの専門認知エージェント（Socratic、Ontologist、Seed Architect、Evaluator、Contrarian、Hacker、Simplifier、Researcher、Architect）です。Harry Munro による Ouroboros に着想を得ています。必要に応じて読み込まれ、事前には読み込まれません。

33 個のテストファイルにわたる 741 件のテストがあります。Claude Code、Cursor、Windsurf、VS Code、Zed、および MCP 対応のあらゆるクライアントで動作します。

インストール

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

設定

LLM プロバイダー

kemdiCode は、統一された provider:model:thinking 構文で 8 つの LLM プロバイダーをサポートしています。

思考トークンの制御：

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)

カスタムエンドポイント（実行時にホットリロード）：

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

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

ツールリファレンス

15 カテゴリにわたる 63 個のツールがあります。統合ツールでは action パラメーターを使用します（例：task action=create|get|list|update|delete）。

アーキテクチャ

イベントバス（2 層）

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

ローレンツ・コンテキスト圧縮

圧縮境界をまたいで推論の連続性を保つための 3 つのアルゴリズム：

1. フェーズ検出 — ポアンカレ断面解析。連続する Jensen-Shannon ダイバージェンスによってトピックの移行を識別します。フェーズ境界には、推論の軌跡に関する最大限の情報が含まれます。

2. 軌道圧縮 — ローレンツアトラクターのサイクル検出。貪欲なサイクル探索（長さ 2～10、最小 2 回の反復）を用いた NxN TF-IDF コサイン類似度行列です。最初のサイクルを保持し、重複を削除します。

3. 摂動の影響 — JSD(full_context, context_without_item) により、各項目の寄与を定量化します。影響度の高い項目は因果的なアンカーとなり、圧縮後も保持されます。

9 つのマインド

それぞれ異なる思考モードを持つ、専門化された 9 つの認知エージェントです。Harry Munro による Ouroboros に着想を得ています：

任意のマインドを agent パラメーターとして使用できます：ask-ai --agent socratic --prompt "..."。複数の視点から分析するために組み合わせることもできます：Socratic → Ontologist → Seed Architect（弁証法的な展開）。

エージェント型ループ

サブエージェントの起動（最大深度 2、グローバル予算 10）、@path 構文によるファイルコンテキストの注入、オーケストレーション ID の完全な追跡に対応した自律型エージェントの実行です。

並列エージェント — agent-orchestrate --parallel を使って、2〜10 個のエージェントを並列に起動します。それぞれに一意の orchestrationId が割り当てられ、Redis とインメモリーキャッシュによってリアルタイムで追跡されます。結果は Promise.allSettled によって集約されます。

ライブモニタリング — エージェントの実行中にオーケストレーションの状態を照会します（MCP はツール呼び出し中にブロックされるため、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

オーケストレーション ID の追跡 — すべてのエージェント型ループに UUID が割り当てられます。サブエージェントは parentOrchestrationId を使って親を参照します。すべての認知レコード（判断、信頼度、意図、エラー、批評、引き継ぎ）に orchestrationId が含まれ、ネストされたエージェント階層全体を完全に追跡できます。

ツールへのアクセス — すべての kemdiCode ツールは、デフォルトでエージェントから利用できます（読み取り専用、カンバン、思考チェーン — シェルやファイルへの書き込みは不可）。エージェントごとにカスタマイズするには、allowedTools または blockedTools を使用してください。

並行処理モデル

• AsyncLocalStorage によるセッション単位の分離（非同期チェーン全体に伝播）
• タスク状態の変更には Redis トランザクションを使用（MULTI/EXEC、Lua スクリプト）
• SET NX PX、Lua CAS 解放、3 回の再試行バックオフによる分散ロック

実際の使用例

kemdiCode ツールは 3 つのレベルで動作します。開発者が日常的に遭遇する実践的なシナリオを紹介します。

レベル 1：ステートレスツール（AI エージェントなし）

Claude Code（または Cursor など）が kemdiCode ツールを直接呼び出します。組み込み AI は使わず、構造化された認知機能とコードインテリジェンスのみを利用します。

シナリオ：「プロジェクトをまたいで、同じ Redis タイムアウトのバグに何度も遭遇する」

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

シナリオ：「スプリント計画 — 3 人の開発者で 15 個のタスクを整理する」

# 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

シナリオ：「チームに加わった後、なじみのないコードベースを把握する」

# 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."

レベル 2：AI エージェント（LLM の組み込み実行）

kemdiCode は外部 LLM を内部で呼び出し、推論、分析、生成を行います。この作業を IDE の AI が行うのではなく、kemdiCode 自身のエージェントが行います。

シナリオ：「API の応答時間が 50ms から 3 秒に延びた原因をデバッグする」

# 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."

シナリオ：「提案しているマイクロサービスへの分割は良いアイデアか？」

mind-chain を使用します。各 Mind が前の Mind の内容を踏まえて進める、順次的な Mind 間の引き継ぎです。

# 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/"

チェーンの流れ：アーキテクトが提案 → 反対派が異議を唱える → リサーチャーが事実確認 → シンプリファイアーが現実的な道筋を見つける → 統合役がすべての視点をまとめる。

シナリオ：「3 つの LLM に重要なセキュリティ変更をレビューさせる」

# 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

レベル 3：クラスターバスと Magistrale（分散 LLM オーケストレーション）

複数の LLM ノードが Redis Pub/Sub を介して通信します。より広いコンテキストが必要な場合に使用します。同じ質問を、それぞれ異なる専門分野を持つ複数のモデルに送信できます。

シナリオ：「レートリミッターを設計する — 3 つのモデルから最良の回答を得る」

# 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

シナリオ：「アーキテクチャの決定 — 1 つの意見ではなく、合意が必要」

# 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

シナリオ：「本番環境のインシデント — できるだけ早く回答が必要」

# 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

シナリオ：「コードを深く分析する — クラスター自身にエージェントを起動させる」

# 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

開発

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

ツールの追加

1. src/tools/<category>/ にファイルを作成します
2. 各フィールドに .describe() を指定して Zod スキーマを定義します
3. UnifiedTool インターフェースを実装します
4. src/tools/index.ts で registerLazyTool() を使って登録します
5. src/tools/annotations-map.ts にアノテーションを追加します

ドキュメント

• 技術ホワイトペーパー（PDF） — ローレンツ圧縮、Nine Minds、ポアンカレ位相検出、軌道圧縮、39 件の参考文献（LaTeX ソース）
• アーキテクチャ概要
• バスアーキテクチャ
• 例 — 統合パターンとワークフロー

ライセンス

GNU General Public License v3.0

作者

Dawid Irzyk — [email protected] — Kemdi Sp. z o.o.