Coordinate AI coding agents with a shared knowledge graph.
Other ways to install · All download options
brew install this-rs/tap/project-orchestrator # macOS / Linux
curl -fsSL https://raw.githubusercontent.com/this-rs/project-orchestrator/main/install.sh | sh # macOS / Linux
irm https://raw.githubusercontent.com/this-rs/project-orchestrator/main/install.ps1 | iex # Windows (PowerShell)
💬 Join our Discord — Get help, share feedback, and connect with the community.
Project Orchestrator gives your AI agents a shared brain. Instead of each agent starting from scratch, they share code understanding, plans, decisions, and progress through a central knowledge base.
- Shared Knowledge Base — Code structure stored in Neo4j graph database, accessible to all agents
- Semantic Code Search — Find code by meaning, not just keywords, powered by Meilisearch
- Plan & Task Management — Structured workflows with dependencies, steps, and progress tracking
- Protocol FSM Engine — Define and run hierarchical finite state machines for repeatable workflows
- RFC Lifecycle — Propose, review, accept, and track architectural decisions through a formal protocol
- Knowledge Fabric — Bio-inspired neural network connecting notes, decisions, and code via synapses
- Multi-Language Parsing — Tree-sitter support for Rust, TypeScript, Python, Go, and 12 more languages
- Multi-Project Workspaces — Group related projects with shared context, contracts, and milestones
- MCP Integration — 22 mega-tools available for Claude Code, OpenAI Agents, and Cursor
- Autonomous Runner — Execute plans automatically with parallel wave dispatch and agent personas
- Auto-Sync — File watcher keeps the knowledge base updated as you code
- Authentication — Google OAuth2, OIDC, and Password login (JWT required once an
authsection is configured; with noauthsection the API is open/anonymous) - Chat WebSocket — Real-time conversational AI via Claude integration with smart context injection
- Event System — Live CRUD notifications via WebSocket + streaming activation events
- NATS Integration — Inter-process event sync for multi-instance deployments
- Skill Federation — Export, publish, and import neural skills across projects and instances
Download the desktop app for your platform. Every link below goes through project-orchestrator.fr/install, which looks up the latest release and downloads the right file, so these links do not change from one version to the next.
| Platform | Download | Type |
|---|---|---|
| macOS (Apple Silicon) | Download .dmg | M1/M2/M3/M4 — macOS 11 or later |
| macOS (Intel) | Download .dmg | Intel Mac — macOS 13.4 or later |
| macOS (Intel, older) | Download .dmg | Intel Mac on macOS 10.15 to 13.3 — no local embeddings, no built-in browser (see below) |
| Windows (64-bit) | Download .exe | Installer |
| Windows (64-bit MSI) | Download .msi | MSI |
| Linux (x86_64 AppImage) | Download .AppImage | Intel/AMD |
| Linux (Debian/Ubuntu x86_64) | Download .deb | apt/dpkg |
| Linux (Debian/Ubuntu arm64) | Download .deb | apt/dpkg — ARM64 (DGX Spark, Ampere, RPi…) |
| Linux (Fedora/RHEL x86_64) | Download .rpm | dnf/rpm |
| Linux (Fedora/RHEL arm64) | Download .rpm | dnf/rpm |
All releases are available on the Releases page.
Linux. The binaries and packages are built on Ubuntu 22.04 and need glibc 2.35 or later: Ubuntu 22.04+, Debian 12+, Fedora 36+, RHEL 10+. RHEL 9 (glibc 2.34), Ubuntu 20.04 and Debian 11 are older and refuse to start them (GLIBC_2.35 not found). The desktop app also needs WebKitGTK 4.1 (present on those systems). The release build fails if this requirement ever rises without the promise being updated (scripts/check-os-floor.sh). Windows: built for Windows 10 or later (Rust's own minimum); the executable headers carry no usable floor, so it is not measured by the build.
Which Mac do I have? Apple menu → About This Mac: a chip named Apple M1… is Apple Silicon, a processor named Intel is Intel. The same window gives your macOS version.
Intel Mac on macOS 10.15 to 13.3 (older Intel build). The standard Intel build bundles ONNX Runtime, which needs macOS 13.4; on an older macOS it stops at launch with Symbol not found … basic_stringbuf. The older-Intel build is compiled without it, so it runs from macOS 10.15, but it has no local embeddings and no built-in browser (its V8 library does not run that far back): semantic search needs an HTTP embedding provider such as Ollama (embeddings.provider: http), and the agents' browser_* tools are not available. The standard Intel build, from macOS 13.4, has both. It updates from its own feed, so it is never offered the standard build. The install script (install.sh) and /install/ pick between the two from your macOS version.
brew install this-rs/tap/project-orchestratorThis installs orchestrator, orch (CLI shorthand), and mcp_server.
curl -fsSL https://raw.githubusercontent.com/this-rs/project-orchestrator/main/install.sh | shOptions:
# Install a specific version
curl -fsSL https://…/install.sh | sh -s -- --version <version>
# Install without the embedded frontend (lighter)
curl -fsSL https://…/install.sh | sh -s -- --no-frontend
# Custom install directory
curl -fsSL https://…/install.sh | sh -s -- --install-dir /usr/local/binirm https://raw.githubusercontent.com/this-rs/project-orchestrator/main/install.ps1 | iex# Full (with embedded frontend)
docker pull ghcr.io/this-rs/project-orchestrator:latest
# API-only (lighter, no frontend)
docker pull ghcr.io/this-rs/project-orchestrator:latest-apiOr use Docker Compose with all services (Neo4j, Meilisearch, NATS):
git clone https://github.com/this-rs/project-orchestrator.git
cd project-orchestrator
docker compose up -d# Download the .deb of the latest release (the file name carries the version, so it is looked up)
curl -s https://api.github.com/repos/this-rs/project-orchestrator/releases/latest \
| grep -o 'https://[^"]*/project-orchestrator_[^"/]*_amd64\.deb' \
| xargs curl -LO
sudo dpkg -i project-orchestrator_*_amd64.deb
# Start the service
sudo systemctl enable --now project-orchestrator# Download the .rpm of the latest release (the file name carries the version, so it is looked up)
curl -s https://api.github.com/repos/this-rs/project-orchestrator/releases/latest \
| grep -o 'https://[^"]*/project-orchestrator-[^"/]*\.x86_64\.rpm' \
| xargs curl -LO
sudo rpm -i project-orchestrator-*.x86_64.rpmgit clone https://github.com/this-rs/project-orchestrator.git
cd project-orchestrator
cargo build --release
# Binaries in target/release/:
# orchestrator — main server
# orch — CLI shorthand
# mcp_server — MCP server for AI toolsThe server requires Neo4j and Meilisearch. The easiest way is Docker Compose:
docker compose up -dThen start the orchestrator:
orchestrator serveAdd to your MCP configuration (e.g., ~/.claude/mcp.json):
{
"mcpServers": {
"project-orchestrator": {
"command": "mcp_server",
"env": {
"NEO4J_URI": "bolt://localhost:7687",
"NEO4J_USER": "neo4j",
"NEO4J_PASSWORD": "orchestrator123",
"MEILISEARCH_URL": "http://localhost:7700",
"MEILISEARCH_KEY": "orchestrator-meili-key-change-me",
"NATS_URL": "nats://localhost:4222"
}
}
}
}Note:
NATS_URLenables real-time event sync between the MCP server and other instances (desktop app, other agents). Without it, CRUD events from MCP tools won't propagate to the rest of the system. If some env vars are not forwarded by your AI tool, the MCP server also readsconfig.yamlas a fallback (see Configuration).
# Your AI agent can now use MCP tools to:
# - create_project: Register your codebase
# - sync_project: Parse and index your code
# - create_plan: Start a development plan
# - create_workspace: Group related projects
# - And 15 more mega-tools...That's it! Your AI agents now have shared context.
| Platform | Status | Documentation |
|---|---|---|
| Claude Code | Full Support | Setup Guide |
| OpenAI Agents | Full Support | Setup Guide |
| Cursor | Full Support | Setup Guide |
"Find all functions that handle authentication"
"Show me what imports this file"
"What's the impact of changing UserService?"
"Create a plan to add OAuth support"
"What's the next task I should work on?"
"Record that we chose JWT over sessions"
"What decisions were made about caching?"
"Show me the project roadmap"
"What tasks are blocking the release?"
"Create a workspace for our microservices"
"Add the API contract shared by all services"
"What's the cross-project milestone progress?"
Protocols are reusable finite state machines stored in the knowledge graph. They model repeatable workflows — from code review to release pipelines — and can be composed hierarchically.
| Concept | Description |
|---|---|
| Protocol | FSM definition with states, transitions, and optional relevance vector |
| ProtocolState | A node in the FSM (start, intermediate, terminal, or generator) |
| ProtocolTransition | An edge between states, fired by a trigger with an optional guard condition |
| ProtocolRun | A live execution instance tracking current state, visit history, and status |
The compose action creates a complete protocol — skill, states, transitions, and note bindings — in a single call:
protocol(action: "compose", project_id: "...",
name: "code-review",
category: "business",
states: [
{ name: "analyze", state_type: "start", description: "Analyze code changes" },
{ name: "review", state_type: "intermediate", description: "Review findings" },
{ name: "approved", state_type: "terminal", description: "Review passed" },
{ name: "rejected", state_type: "terminal", description: "Review failed" }
],
transitions: [
{ from_state: "analyze", to_state: "review", trigger: "analysis_complete" },
{ from_state: "review", to_state: "approved", trigger: "approve" },
{ from_state: "review", to_state: "rejected", trigger: "reject" }
],
relevance_vector: { phase: 0.75, structure: 0.6, domain: 0.5, resource: 0.5, lifecycle: 0.5 }
)
# Start a run (enters the start state automatically)
protocol(action: "start_run", protocol_id: "...")
# Fire transitions to advance through the FSM
protocol(action: "transition", run_id: "...", trigger: "analysis_complete")
protocol(action: "transition", run_id: "...", trigger: "approve")
# Check current state
protocol(action: "get_run", run_id: "...")
# → { status: "completed", current_state: "approved", states_visited: [...] }
A state can delegate to a child protocol (macro-state). The parent pauses until the child completes:
states: [
{ name: "plan", state_type: "start" },
{ name: "implement", state_type: "intermediate", sub_protocol_id: "<review-protocol-id>" },
{ name: "done", state_type: "terminal" }
],
transitions: [
{ from_state: "plan", to_state: "implement", trigger: "plan_approved" },
{ from_state: "implement", to_state: "done", trigger: "child_completed" }
]
Completion strategies: all_complete (default), any_complete, manual.
Failure strategies: abort (default), skip, retry(N).
Each protocol has a 5-dimension relevance vector. Use route to find the best protocol for your current context:
protocol(action: "route", project_id: "...", plan_id: "...")
# → wave-execution: 95% (phase match + high structure)
# → code-review: 60% (phase mismatch)
A protocol that ensures every non-trivial code change goes through proper impact analysis, topology checks, and documentation — using the full knowledge fabric:
protocol(action: "compose", project_id: "...",
name: "safe-modification",
category: "business",
states: [
{ name: "gather-context", state_type: "start",
description: "Load notes, decisions, propagated context, active RFCs" },
{ name: "analyze-impact", state_type: "intermediate",
description: "Run analyze_impact + get_file_co_changers on target files" },
{ name: "check-topology", state_type: "intermediate",
description: "Verify new imports don't violate architectural rules" },
{ name: "check-risks", state_type: "intermediate",
description: "Evaluate risk via get_node_importance — PageRank, betweenness, churn" },
{ name: "implement", state_type: "intermediate",
description: "Make changes with full awareness of impact and constraints" },
{ name: "verify", state_type: "intermediate",
description: "Run tests + re-check topology for new violations" },
{ name: "document", state_type: "intermediate",
description: "Create notes, record decisions, link AFFECTS to changed files" },
{ name: "done", state_type: "terminal",
description: "Changes are safe, tested, and documented" }
],
transitions: [
{ from_state: "gather-context", to_state: "analyze-impact", trigger: "context_loaded" },
{ from_state: "analyze-impact", to_state: "check-topology", trigger: "impact_assessed" },
{ from_state: "check-topology", to_state: "check-risks", trigger: "topology_ok" },
{ from_state: "check-topology", to_state: "gather-context", trigger: "topology_violation",
guard: "New imports violate architectural rules — rethink the approach" },
{ from_state: "check-risks", to_state: "implement", trigger: "risks_acceptable" },
{ from_state: "check-risks", to_state: "gather-context", trigger: "high_risk",
guard: "Critical risk score — need a different approach" },
{ from_state: "implement", to_state: "verify", trigger: "changes_made" },
{ from_state: "verify", to_state: "document", trigger: "verification_passed" },
{ from_state: "verify", to_state: "implement", trigger: "verification_failed" },
{ from_state: "document", to_state: "done", trigger: "documented" }
],
relevance_vector: { phase: 0.5, structure: 0.7, domain: 0.5, resource: 0.5, lifecycle: 0.5 }
)
A system protocol that runs weekly to keep the knowledge fabric healthy:
protocol(action: "compose", project_id: "...",
name: "knowledge-maintenance",
category: "system",
states: [
{ name: "audit", state_type: "start",
description: "audit_gaps — find orphan notes, decisions without AFFECTS, unlinked commits" },
{ name: "health-check", state_type: "intermediate",
description: "get_health — hotspots, risks, homeostasis, neural metrics" },
{ name: "decay-synapses", state_type: "intermediate",
description: "Gentle decay (0.03) to prune dead connections — NEVER > 0.1 per pass" },
{ name: "update-scores", state_type: "intermediate",
description: "Recalculate staleness, energy, and fabric fusion scores" },
{ name: "review-stale", state_type: "intermediate",
description: "Find stale notes — confirm, invalidate, or supersede" },
{ name: "report", state_type: "terminal",
description: "persist_health_report — saves as note with delta vs. previous report" }
],
transitions: [
{ from_state: "audit", to_state: "health-check", trigger: "audit_done" },
{ from_state: "health-check", to_state: "decay-synapses", trigger: "health_assessed" },
{ from_state: "decay-synapses", to_state: "update-scores", trigger: "decay_applied" },
{ from_state: "update-scores", to_state: "review-stale", trigger: "scores_updated" },
{ from_state: "review-stale", to_state: "report", trigger: "review_done" }
],
relevance_vector: { phase: 0.75, structure: 0.3, domain: 0.5, resource: 0.3, lifecycle: 0.8 }
)
Full protocol guide: See Protocols — Building a Safe, Self-Aware Setup for detailed step-by-step instructions on what the agent should do at each state, how to set up hierarchical protocols, auto-triggers, and a recommended production suite.
RFCs are special knowledge notes (note_type: "rfc") with a formal lifecycle managed by the Protocol FSM engine. Use them for architectural decisions that need review before implementation.
- Architectural changes affecting multiple components
- New patterns or conventions that change how the team works
- API redesigns, data model migrations, breaking changes
- Any decision that benefits from structured review
note(action: "create",
project_id: "...",
note_type: "rfc",
content: "## Problem\nOur API returns inconsistent error formats...\n\n## Proposed Solution\nStandardize on RFC 7807 Problem Details...\n\n## Alternatives\n1. Custom error envelope...\n2. GraphQL errors...\n\n## Impact\n- All HTTP handlers in src/api/\n- Client SDK needs update\n- Migration guide required",
importance: "high",
tags: ["rfc", "api", "error-handling"]
)
draft ──propose──> proposed ──accept──> accepted ──implement──> implemented
│
└──reject──> rejected
# Advance an RFC through its lifecycle
note(action: "advance_rfc", note_id: "...", trigger: "propose") # draft → proposed
note(action: "advance_rfc", note_id: "...", trigger: "accept") # proposed → accepted
note(action: "advance_rfc", note_id: "...", trigger: "implement") # accepted → implemented
# Check current status
note(action: "get_rfc_status", note_id: "...")
# → { state: "accepted", protocol_run: { ... } }
# List all RFCs for a project
note(action: "list_rfcs", project_id: "...")
- Always check existing RFCs before starting work:
note(action: "list_rfcs", project_id) - Link accepted RFCs to plans:
note(action: "link_to_entity", note_id, "plan", plan_id) - Link to affected code:
note(action: "link_to_entity", note_id, "file", "src/api/handlers.rs") - Advance to
implementedwhen done, and link the final commit
The most powerful feature of Project Orchestrator is its knowledge accumulation. Follow these practices to maximize value:
Before any work, load existing knowledge to avoid redoing documented work:
note(action: "search_semantic", query: "authentication flow")
decision(action: "search_semantic", query: "JWT vs sessions")
note(action: "get_context", entity_type: "file", entity_id: "src/auth/mod.rs")
note(action: "list_rfcs", project_id: "...")
After every meaningful discovery, create a note:
| Situation | Note Type | Example |
|---|---|---|
| Found a bug root cause | gotcha |
"Neo4j returns null for optional rels — always use OPTIONAL MATCH" |
| Discovered a pattern | pattern |
"All handlers follow extract→validate→execute→respond" |
| Identified a convention | guideline |
"Use ULID for all entity IDs, never UUIDv4" |
| Found a useful trick | tip |
"Use code(action: 'get_communities') before refactoring to understand module boundaries" |
| Observed behavior | observation |
"Sync takes ~3min for repos > 50k LOC" |
Always link notes to the relevant code:
note(action: "create", project_id: "...", note_type: "gotcha",
content: "neo4rs returns BoltNull for missing optional relationships — always check with .is_null() before unwrapping",
importance: "high", tags: ["neo4j", "null-safety"])
# → note_id
note(action: "link_to_entity", note_id: "...", entity_type: "file", entity_id: "src/neo4j/client.rs")
For every non-trivial choice, document the alternatives and rationale:
decision(action: "add", task_id: "...",
description: "Use Axum over Actix-web for HTTP framework",
rationale: "Better tokio integration, simpler middleware, growing ecosystem",
alternatives: ["actix-web: mature but actor model adds complexity", "warp: filter-based API is harder to read"],
chosen_option: "axum"
)
Always check impact before changing code:
code(action: "analyze_impact", target: "src/api/handlers.rs")
code(action: "get_file_co_changers", file_path: "src/api/handlers.rs")
note(action: "get_propagated", file_path: "src/api/handlers.rs", slug: "my-project")
The Knowledge Fabric connects all entities via semantic relations. Leverage it:
# Bootstrap on a new project
admin(action: "bootstrap_knowledge_fabric", project_id: "...")
# Check codebase health (hotspots, risks, knowledge gaps)
code(action: "get_health", project_slug: "my-project")
# Understand module boundaries before refactoring
code(action: "get_communities", project_slug: "my-project")
# Evaluate risk before touching a critical file
code(action: "get_node_importance", project_slug: "my-project",
node_path: "src/neo4j/client.rs", node_type: "File")
| Version | Date | Highlights |
|---|---|---|
| v0.0.16 | 2026-10-02 | Cross-workspace attention API for the Today cockpit, plan-task retry route, per-workspace topology derived from the code, secrets handed to agents without leaking (vault), entity neighborhood endpoint and richer code entities (file path, docstring, signature), XLSX/PPTX extraction and work-profile projects (optional root_path), self-update split into version/deployment/service, security hardening (signed tombstones, WS ticket/cookie auth, Cypher/Meilisearch injection fixes, MCP token purge), in-repo living diagrams and bug registry |
| v0.0.15 | 2026-07-04 | Remote MCP over Streamable HTTP with an OAuth 2.1 authorization server (opt-in), resume existing sessions via REST/MCP, live Claude model catalog from the Anthropic Models API, session-lifecycle navigation ritual seeded on project creation, note-embedding backfill admin action, semantic anchoring fallback, Witness schema for epistemic discipline |
| v0.0.14 | 2026-06-02 | Configurable cap on wave concurrency, Claude Code Dynamic Workflow progress events surfaced in the chat |
| v0.0.13 | 2026-05-03 | Task cancellation (V2 cancel_task with PID discovery and targeted subprocess kill), background-task tracking with granular control, user-initiated tool-subprocess cancellation, out-of-band SDK event listener |
| v0.0.12 | 2026-04-16 | MCP Federation (external MCP servers), Streamable HTTP spec compliance, chat ↔ plan/task/RFC bidirectional linking, Claude Opus 4.7 support, chat-session rename, Dart/Flutter language support |
| v0.0.11 | 2026-03-20 | Neural Routing ML Pipeline, Plan Runner with Protocol-Driven Lifecycle (FSM + adaptive feedback), Protocol FSM enhancements (CAS, timeouts, episodes), Event Reactor & Pipeline Quality Gates, 28 mega-tools meta-prompt sync |
| v0.0.9 | 2026-03-12 | Episodic Memory, M4 MVP P2P Knowledge Exchange, Intent-Adaptive Retrieval (biomimetic memory routing), RFC REST endpoints with lifecycle FSM, auto-roadmap endpoint, transitive knowledge propagation (FeatureGraph, Protocol, Skill) |
| v0.0.8 | 2026-03-10 | Protocol v2 (hierarchical FSM, generator states, RFC lifecycle), Runner v2+v3 (parallel waves, agent personas), Knowledge Scars & biomimicry, streaming WebSocket events, intelligent hooks |
| v0.0.7 | 2026-03-06 | Pattern Federation (skill registry, cross-instance discovery), compose & simulate, context-aware routing, wave execution, analytics statistical rigor |
| v0.0.6 | 2026-02-28 | Conversational intelligence, reasoning trees, VizBlock, smart system prompt, knowledge reconstruction |
| v0.0.5 | 2026-02-20 | Knowledge Fabric, synapses, co-change detection, community analysis, GDS integration |
| v0.0.4 | 2026-02-12 | Multi-project workspaces, components, resources, topology |
| v0.0.3 | 2026-02-05 | Authentication (OIDC + Password), NATS event sync, chat WebSocket |
| v0.0.2 | 2026-01-28 | Semantic search, decisions, constraints, milestones, releases |
| v0.0.1 | 2026-01-20 | Initial release: projects, plans, tasks, steps, Tree-sitter sync |
All releases with full changelogs are available on the Releases page.
| Guide | Description |
|---|---|
| Installation | Full setup instructions and configuration |
| Getting Started | Step-by-step tutorial for new users |
| Foundation Kit | Start here after setup — seed knowledge for a self-aware instance |
| Protocols & FSM | Building a safe, self-aware setup with protocol guardrails |
| API Reference | Complete REST API documentation |
| MCP Tools | All 22 MCP mega-tools with examples |
| Knowledge Fabric | Bio-inspired knowledge graph: scars, homeostasis, scaffolding |
| Workspaces | Multi-project coordination |
| Multi-Agent Workflows | Coordinating multiple agents |
| Authentication | JWT + OAuth/OIDC + Password auth setup |
| Chat & WebSocket | Real-time chat and events |
| Knowledge Notes | Contextual knowledge capture |
| Classifier Bench | Offline bench of the five backend classifiers vs the majority baseline |
| Operations: after-merge checks | cargo xtask in-service (is what runs main?) and cargo xtask pins (did a nexus merge reach the pin?) |
The server uses a layered configuration system: env vars > config.yaml > defaults.
Copy and edit config.yaml at the project root:
server:
port: 8080 # SERVER_PORT
neo4j:
uri: "bolt://localhost:7687" # NEO4J_URI
user: "neo4j" # NEO4J_USER
password: "orchestrator123" # NEO4J_PASSWORD
meilisearch:
url: "http://localhost:7700" # MEILISEARCH_URL
key: "orchestrator-meili-key-change-me" # MEILISEARCH_KEY
nats:
url: "nats://localhost:4222" # NATS_URL — inter-process event sync
chat:
default_model: "claude-opus-4-6" # CHAT_DEFAULT_MODEL| Variable | Description | Default |
|---|---|---|
NEO4J_URI |
Neo4j Bolt connection URI | bolt://localhost:7687 |
NEO4J_USER |
Neo4j username | neo4j |
NEO4J_PASSWORD |
Neo4j password | orchestrator123 |
MEILISEARCH_URL |
Meilisearch HTTP URL | http://localhost:7700 |
MEILISEARCH_KEY |
Meilisearch API key | orchestrator-meili-key-change-me |
NATS_URL |
NATS server URL for event sync | (optional) |
CHAT_DEFAULT_MODEL |
Default Claude model for chat | claude-opus-4-6 |
RUST_LOG |
Log level filter | info |
Why NATS? The MCP server runs as a separate process (spawned by Claude Code). NATS is the pub/sub bridge that propagates CRUD events and chat messages between the MCP server, the HTTP backend, and the desktop app. Without NATS, each instance works in isolation.
┌─────────────────────────────────────────────────────────────┐
│ YOUR AI AGENTS │
│ (Claude Code / OpenAI / Cursor) │
└──────────┬──────────────────┬───────────────────┬───────────┘
│ MCP Protocol │ WebSocket │ REST API
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ PROJECT ORCHESTRATOR │
│ (22 MCP Mega-Tools) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ Auth │ │ Chat │ │ Events │ │ Config │ │
│ │OIDC+Pass │ │ Claude │ │ Live WS │ │ YAML + │ │
│ │ + JWT │ │ Streams │ │ + NATS │ │ env vars │ │
│ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │
└─────────────────────────────┬───────────────────────────────┘
│
┌──────────────────────────┼──────────────────────────┐
▼ ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐
│ NEO4J │ │MEILISEARCH│ │ NATS │ │ TREE-SITTER │
│ │ │ │ │ │ │ │
│• Code │ │• Code │ │• Event │ │• 16 languages│
│ graph │ │ search │ │ sync │ │• AST parsing │
│• Plans │ │• Decisions│ │• Chat │ │• Symbols │
│• Decisions│ │ │ │ relay │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────────┘
Contributions are welcome! See CONTRIBUTING.md for guidelines.
Dual-licensed, MIT AND BUSL-1.1: see LICENSE, LICENSE-MIT and LICENSE-EE.
The release artifacts also carry THIRD-PARTY-LICENSES.txt, the licenses and notices of the third-party code
in the binaries (generated by scripts/third-party-licenses.sh).
Give your AI agents a shared brain.