Contorium

by ContoriumLabs

352 downloads Not rated yet

GitHub

About

Runtime continuity layer MCP for AI coding agents, providing persistent workspace state and session context across tools and runs.

Explore

- Observes workspace and development context continuously
- Does not execute actions or take control of the workflow
- Follows the Observe → Understand → Suggest cycle
- Provides persistent runtime awareness for AI systems
- Maintains continuity across files, terminals, and sessions

Setting up with Highlight

This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:

Download and install Highlight from highlightai.com/download
Navigate to the plugins tab and select "Add Custom Plugin"
Configure the plugin with the settings below

Plugin Name Contorium

Command (node, npx, python, etc.)

Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
Enable "Start Automatically" if you want the plugin to start when Highlight launches

Setting up with Cursor

Open Cursor's settings
Navigate to the MCP section
Click "Add new Global MCP server"
Copy and paste the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

Setting up with Claude Desktop

Open Claude Desktop's settings
Go to the Integrations tab
Click "Add MCP Server"
Use the configuration below based on your operating system

Note: Make sure Claude Desktop is running before attempting to connect.

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

Setting up with Windsurf

Open Windsurf's preferences
Go to the Integrations section
Click "Add MCP Integration"
Use the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

Setting up with Cline

Open Cline's settings
Navigate to the Integrations section
Click "Add MCP Server"
Copy and paste the configuration below based on your operating system

Note: Make sure to restart Cline after adding the configuration.

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

Setting up with Goose

Open Goose's preferences
Go to the Integrations tab
Select "MCP Servers"
Click "Add New Server"
Use the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

From the repository

—

`get_cognitive_mode`

[Cognitive Overlay] Read MCP mode A/B. Contorium MCP mode (v2): A = Core Runtime DEFAULT (pure observation — project, task, feed) B = Cognitive Overlay (A + skill suggestions + model presets + external search)

`set_cognitive_mode`

[Cognitive Overlay] Switch MCP mode A/B. Does NOT change runtime core behavior — overlay only. Contorium MCP mode (v2): A = Core Runtime DEFAULT (pure observation — project, task, feed) B = Cognitive Overlay (A + skill suggestions + model presets + external search)

`get_cognitive_insights`

[Cognitive Overlay · Mode B only] Full insight bundle: intent, skills, tools, model preset. Read-only — never installs or executes.

`get_skill_suggestions`

[Cognitive Overlay · Mode B only] Skill discovery from local registry + GitHub/NPM search. Display-only links — no auto install.

`get_model_preset`

[Cognitive Overlay · Mode B only] Task mode preset (SMART/FAST/REASON/CODE/LOCAL) — strategy hint only, NOT a model recommendation system.

`update_project_intent`

[Legacy alias · prefer record_project_intent] Record user direction overlay for cognition. Requires user_input. Does not execute work.

`record_project_intent`

[Write · Intent] Record project direction for intent/why layers (human → system). Requires user_input. Prefer capture_focus for simple current-task updates.

`analyze_project`

[Inspect · Composite] One-shot cognition snapshot (governance + handoff + state). Prefer ask_project or inspect_* for targeted reads; use this for a broad diagnostic dump.

`get_cognitive_state`

[Inspect] Derived cognitive projection (.contora/cognitive/). Prefer inspect_state / inspect_intent for PIL facts.

`get_change_log`

[Inspect] Recent guard / change-log records. Optional limit (1–50, default 20). Prefer get_recent_events for cognitive timeline.

`get_control_context`

[Legacy] Decision provenance context — prefer get_decision_context.

`get_decision_context`

[Decision Provenance · read] Project state, git, and latest decision snapshot.

`resolve_scope_context`

[Governance V4 · fast] Resolve diff/file/project into primary, related, risk, and dependency scopes. mode: auto | strict | minimal (not "project"). Prefer before a SLOW derive_decision_provenance when scoping a single file.

`derive_decision_provenance`

[SLOW · ~2–3 min · Prefer once] Derive decision provenance (review → decision → scope → trace). Records only — no code execution. Pass active_file + mode=advisory + persist=false for lighter runs. Do NOT also call aliases in the same turn (derive_decision_trace / decision_snapshot / run_governance_cycle / build_decision_provenance / trace_governance_cycle). Prefer get_decision_context or ask_project for quick reads.

`derive_decision_trace`

[SLOW · Alias · prefer derive_decision_provenance] Same handler — avoid calling both in one turn.

`decision_snapshot`

[SLOW · Alias · prefer derive_decision_provenance] Same derive cycle (persist=true only if you need a written snapshot) — not a separate API.

`build_decision_provenance`

[SLOW · Legacy · prefer derive_decision_provenance] Same heavy cycle — do not call for ordinary Q&A.

`run_governance_cycle`

[SLOW · Legacy · prefer derive_decision_provenance] Same heavy cycle. Not task execution. Avoid unless caller already uses this name.

`trace_governance_cycle`

[SLOW · Legacy · prefer derive_decision_provenance] Same heavy cycle — alias only.

`synthesize_context_payload`

[Prefer · Inject] Build structured AI context from decision provenance (no autonomous action). Call after derive_decision_provenance when injecting governance context.

`generate_inject_payload`

[Legacy alias] Same as synthesize_context_payload.

`export_decision_provenance`

[Decision Provenance · read] Export decision / scope / trace appendix for AI context.

`export_governance_context`

[Legacy alias] Same as export_decision_provenance.

`inspect_cognition_ready`

[SLOW · Ready] Verify Decision Provenance layer is initialized (~10–20s). Call before derive_decision_provenance on a fresh workspace; skip if already initialized this session.

`inspect_system_ready`

[SLOW · Legacy · prefer inspect_cognition_ready] Same ready check (~10–20s).

`inspect_control_ready`

[SLOW · Legacy · prefer inspect_cognition_ready] Same ready check (~10–20s).

`ensure_control_ready`

[SLOW · Legacy · prefer inspect_cognition_ready] Same ready check (~10–20s). Avoid unless caller already uses this name.

`get_project_identity`

[Project Intelligence · inspect] Cross-tool project identity (.contora/identity/project_identity.json).

`get_project_decision`

[Project Intelligence · inspect] Decision provenance graph + latest governance decision record.

`get_project_why`

[Project Intelligence · inspect] Why layer (.contora/intent/why.json).

`get_project_intent_graph`

[Project Intelligence · inspect] Intent graph (.contora/intent/intent_graph.json).

`get_project_evolution_timeline`

[Dimension · TIMELINE · inspect] Structured evolution history (.contora/timeline/project_timeline.json). Descriptive — not a log dump.

`get_impact_graph`

[Dimension · IMPACT · inspect] Scope and propagation model (.contora/graph/impact_graph.json). Descriptive — not risk prediction.

`get_confidence_index`

[Dimension · CONFIDENCE · inspect] Trustworthiness of recorded intelligence (.contora/confidence/confidence_index.json).

`get_stability_index`

[Legacy alias] Same as get_confidence_index.

`get_provenance_chain`

[System · PROVENANCE · inspect] Trace-back chains WHY → DECISION → INTENT → TIMELINE (.contora/provenance/provenance_chain.json).

`get_evolution_graph`

[System · EVOLUTION · inspect] Structured transformation chains (.contora/evolution/evolution_graph.json). Not chronological timeline.

`get_project_intelligence_health`

[v1.1.3 · inspect] Intelligence completeness, weighted health_score, knowledge_coverage (.contora/intelligence/health.json). Measures asset completeness — not project quality.

`get_decision_log`

[v1.1.3 · inspect] Append-only decision log (.contora/decision/decision_log.json). Records selected alternatives — not recommendations.

`get_cognitive_snapshot`

[Legacy alias · prefer transfer_context] Compressed Cognitive Snapshot (~300–800 tokens).

`get_full_intelligence`

[Legacy alias · prefer transfer_intelligence] Full Project Intelligence export (~8000 tokens).

`inspect_state`

[PIL · Inspect] Workspace state — state.json, status, built project state. Call first when grounding on current focus/stage. Prefer ask_project for NL questions.

`inspect_intent`

[PIL · Inspect · Prefer] vNext intent graph (.contora/intent/intent_graph.json). Prefer over legacy get_intent_graph / get_project_intent_graph.

`inspect_decision`

[PIL · Inspect · Prefer] Decision provenance + governance decision + decision log. Prefer over get_decision_graph / get_project_decision for a full decision picture.

`inspect_timeline`

[PIL · Inspect] Project evolution timeline (TIMELINE dimension).

`inspect_graph`

[PIL · Inspect] Change-neighborhood graph (.contora/graph.json).

`inspect_confidence`

[PIL · Inspect] Confidence index (CONFIDENCE dimension).

`inspect_health`

[PIL · Inspect] Project intelligence health metrics.

`inspect_why`

[PIL · Inspect] Why layer — feature rationale records.

`inspect_impact`

[PIL · Inspect] Impact graph (IMPACT dimension).

`inspect_evolution`

[PIL · Inspect] Evolution graph — structured transformation chains (EVOLUTION system).

`inspect_provenance`

[PIL · Inspect] Provenance chain — WHY → DECISION → INTENT trace-back (PROVENANCE system).

`transfer_context`

[Legacy alias · prefer transfer_project mode=context] Intelligence Transfer Context (~300–800 tokens).

`transfer_intelligence`

[Legacy alias · prefer transfer_project mode=intelligence] Full Intelligence Transfer (~8000 tokens).

`transfer_handoff`

[Legacy alias · prefer transfer_project mode=handoff] Compact handoff (~100–300 tokens) for new-chat continuity.

`transfer_runtime`

[Legacy alias · prefer transfer_handoff] Same as transfer_handoff.

`capture_focus`

[PIL · Capture · Write] Set current project focus (state.json currentTask). Side effect: persists focus.

`capture_note`

[PIL · Capture · Write] Append a timestamped note to state.json. Side effect: persists note.

`capture_decision`

[PIL · Capture · Write] Record a decision (append-only log). Side effect: persists decision. Requires selected; optional reason / intent_id / decision_id.

`run_decision_evolution`

[PIL · Evolution] Detect project-state transitions and enqueue pending decisions for human review. Does NOT auto-commit. Call after significant architectural changes or sync. Ingests git working-tree changes as ChangeEvents first.

`note_change_event`

[PIL · Evolution] Record a file ChangeEvent into the active Task Session (MCP tool-result bridge). Prefer after write/edit tools; does not Accept Decision.

`inspect_pending_decisions`

[PIL · Inspect · Prefer] List pending decisions awaiting human review (.contora/lifecycle/pending-decisions/). AI may read; must NOT auto-commit.

`review_pending_decisions`

[Legacy alias · prefer inspect_pending_decisions] Same as inspect_pending_decisions(status=waiting_review).

`review_decisions`

[PIL · Lifecycle · Prefer] Review pending decision queue or one pending_id. AI may read; must NOT auto-accept. Prefer before commit_decision.

`commit_decision`

[PIL · Capture · Write] Accept Decision — promotes a pending decision into ADR (.contora/decisions/). Reasoning State accept (not Git commit). REQUIRES user_confirmed=true after explicit human confirmation. Agents must NOT auto-accept.

`ignore_pending_decision`

[PIL · Write] Mark a pending decision as ignored after human decline. Requires pending_id.

`get_decision_evolution`

[PIL · Evolution · Prefer] Decision Evolution Graph + waiting pending + project-state fingerprint. How the project evolved decision-by-decision.

`get_project_context`

[PIL · Retrieval] Project background context for questions and exploration (decisions, constraints, evolution, state). For pre-edit agent work use prepare_execution_context instead. Read-only — does not Accept Decision.

`prepare_execution_context`

[PIL · Retrieval · Prefer] Prepare minimal must-know context before the agent executes a task (Analyzer → Risk → Retrieval → Budget). Call immediately before architecture-sensitive edits. Read-only — does not Accept Decision.

`explain_context`

[PIL · Retrieval] Explain why specific context items were included for a task. Read-only.

`ask_project`

[CIL · Prefer for Q&A] Natural-language project question (what happened, why, impact, validity, next). Call when the user asks in plain language. Prefer over chaining multiple inspect_* tools. Does not execute work.

`get_recent_events`

[CIL · History] Latest cognitive events (timeline + decision + why). Use for a short recent feed. Params: limit (default 12); optional range filters then applies limit. For a dated window with narrative blocks prefer get_project_history.

`get_project_history`

[CIL · History Explorer] Project history feed for a time range (formatted blocks). Use when the user asks what happened over a period. Params: range (default last_7_days); optional limit (default 24). For only the N newest events prefer get_recent_events.

`get_decisions`

[CIL · Decision Center] ADR-style decisions with Why / Risk / Alternatives. Use when listing or reviewing recorded decisions. Prefer ask_project for one-off “why was X decided”.

`get_project_story`

[CIL · Narrative] Combined story — goal, events, decisions, journey. Prefer transfer_project(mode=story) when exporting into a chat; use this to read the story payload in-place. Alias of kernel story (same as transfer_story).

`get_next_actions`

[CIL · Suggestions only] Suggested next actions from focus, handoff, and intent. is_executable=false — never treat as orders to run. Prefer ask_project(“what should I do next?”) for NL.

`get_module_history`

[CIL · History] Cognitive events for a module or file path. Requires `module`. Use when asking about a specific area of the codebase.

`get_blast_radius`

[CIL · Impact] Blast radius / affected nodes for a module or file. Requires `module`. Prefer inspect_impact for PIL impact graph; use this for CIL module-centric impact.

`get_project_journey`

[CIL · Evolution] Project growth roadmap narrative. Use for long-horizon “how did we get here / where next”.

`transfer_story`

[Legacy alias · prefer transfer_project mode=story or get_project_story] Same kernel story payload — not a separate Transfer pipeline.

`get_decision_graph`

[CIL · Decision Center] Decision DAG (.contora/decisions/graph.json). Prefer inspect_decision for PIL provenance + governance decision together.

`get_snapshot`

[CIL · Time travel] Project snapshot nearest a date (YYYY-MM-DD) or latest if date omitted. Optional perspective: historical | retrospective.

`get_cognitive_health`

[CIL · Health] Cognitive health score and warnings (missing WHY, stale ADR, conflicts). For decision lifecycle trust prefer get_knowledge_health; for PIL metrics prefer inspect_health.

`get_entity_knowledge`

[CIL · Knowledge] Everything related to an entity/topic (module name, feature, system). Requires `entity`. Prefer ask_project for open-ended questions.

`get_project_essence`

[CIL · Compression] Compressed project essence. Prefer transfer_project(mode=essence) when exporting into a new chat.

`get_handoff_replay`

[CIL · Replay] Cognitive evolution replay timeline. Use to reconstruct how understanding changed over sessions.

`get_project_dna`

[CIL · DNA] Project identity fingerprint for handoff. Prefer transfer_project(mode=handoff) for session continuity payloads.

`transfer_project`

[CIL · Prefer for Transfer] Unified export into the current chat. mode: context (~300–800 tok) | intelligence (~8k) | story | essence | handoff. Prefer this over transfer_context / transfer_intelligence / transfer_handoff / transfer_story aliases.

`get_suggested_questions`

[CIL · Onboarding] Suggested Ask Contorium questions. Call when starting exploration or the user asks what they can ask.

`get_knowledge_health`

[CIL · Lifecycle · Prefer] Knowledge Health + per-decision trust (.contora/lifecycle/). Call when checking if decisions are still valid / project knowledge freshness.

`get_review_queue`

[CIL · Lifecycle · Prefer] Decisions needing review (stale, expired, conflict, missing owner, invalidation). Call before trusting old ADRs; pair with set_decision_lifecycle_meta after human verify.

`set_decision_lifecycle_meta`

[CIL · Lifecycle · Write] Update decision owner, verification, or expiry → .contora/lifecycle/. Side effect: persists meta and refreshes knowledge lifecycle index. Requires decision_id.

`get_ai_status`

[CIL · AI Layer] LLM explanation-layer status — enabled flag, provider, model, module switches, intent router mode. Does not expose API keys.

`test_ai_connection`

[CIL · AI Layer] Test LLM provider connectivity using workspace llm.json + api_key_env. Returns ok/latency/message.

`store_memory`

Store important coding context into Contorium memory (persisted under .contora/mcp/).

`search_memory`

Search Contorium MCP memory entries by keyword.

`get_memory`

Get a Contorium MCP memory entry by exact key.

`get_workspace_context`

Read Contorium workspace snapshot from .contora/state.json (current focus, notes, files, Git) written by the VS Code/Cursor extension.

`get_project_intelligence`

Read Contorium v0.7 derived project understanding from .contora/intelligence/state-summary.json (written by the extension cognition layer).

`get_intent_graph`

[Legacy · prefer inspect_intent] Old intent graph at .contora/intent-graph/graph.json (not vNext). Use inspect_intent for .contora/intent/intent_graph.json.

`get_active_intents`

Return ACTIVE / WEAKENING / PARTIAL intent nodes from the Contorium intent graph (compact summary for agents).

`get_project_state`

Read Contorium State Builder structured project state from .contora/state-builder/project-state.json (goal, stage, decisions, problems, next actions).

`get_project_snapshot`

Read Contorium PROJECT SNAPSHOT markdown from .contora/state-builder/project-snapshot.md for cross-AI project continuity.

`get_state_conflicts`

Read Contorium v2 unresolved state conflicts from .contora/state-engine/conflicts.json (audit only — system does not auto-resolve).

`get_project_change`

Read Contorium V3.1 change semantics from .contora/change.json (changed files + key symbol changes).

`get_project_graph`

Read Contorium V3 change-neighborhood project graph from .contora/graph.json (functions, classes, imports around recent changes).

`get_project_knowledge_graph`

Read Contorium V3.1 Project Knowledge Graph from .contora/graph/knowledge.json (Intent → Module → File → Function + intent mappings).

`get_project_graph_snapshot`

Read Contorium V3.1 cognitive snapshot from .contora/graph/snapshot.json — compact summary for AI Handoff (top intents, hotspots, functions).

`get_project_impact`

[Deprecated V3.1] Impact merged into handoff.json — returns impact_summary from handoff or legacy impact.json.

`get_project_intent`

[Legacy · prefer inspect_intent] Compact intent summary artifact. Prefer inspect_intent (vNext graph) or ask_project for NL.

`get_handoff_injection_status`

[Prefer · New chat] Call at the start of a new session: check if runtime handoff injection is pending. If pending=true, ask the user then call confirm_handoff_injection (Y) or skip_handoff_injection (N). Else use transfer_project(mode=context) if continuity is needed.

`confirm_handoff_injection`

[Write · New chat] After user confirms (Y): write .contora/mcp.auto-context.md and mark injection done. Optional format: json | markdown | compact (default markdown). Side effect: persists context file.

`skip_handoff_injection`

[Write · New chat] User declined injection (N). Marks skip for this runtime session; get_project_handoff / transfer_project remain available on demand.

`get_project_handoff`

CHP v1 get_handoff — read unified AI handoff from Contorium Runtime (.contora/handoff.json + state). For new chats prefer get_handoff_injection_status → user confirm → confirm_handoff_injection.

`get_project_timeline`

Read Contorium V3.1 code evolution timeline from .contora/timeline.json (recent commits + symbol changes).

`get_recent_changes`

[MCP v1 standard] Recent file/function changes from .contora/change.json — alias of get_project_change.

`get_understanding_graph`

[MCP v1 standard] Runtime understanding graph — call chains + impact from .contora/understanding_graph.json.

`get_runtime_state`

[MCP v1 standard] Runtime session view — bootstrap, dashboard worker, session marker (read-only).

Your project's accumulated understanding shouldn't have to.

Your Project │ ▼ ┌──────────────────────┐ │ Contorium │ │ │ │ Project Intelligence │ │ Layer │ └──────────┬───────────┘ │ ┌──────────┼──────────┐ ▼ ▼ ▼ Cursor Claude Codex │ Code │ │ │ │ └──────────┼──────────┘ ▼ Shared Understanding

Use the tools you prefer without forcing each one to reconstruct the project from zero.

- Cursor
- Claude Code
- Gemini CLI
- Codex
- VS Code
- MCP-compatible AI tools

- sessions
- tools
- model switches
- long development cycles

Contorium builds structured relationships across the project:

Intent ↓ Module ↓ File ↓ Function ↓ Dependency

Instead of treating a repository as a collection of disconnected files, Contorium builds a queryable representation of how the project fits together.

Track the changes that matter and connect them to the project's broader state.

Preserve the knowledge that is usually lost after a conversation ends:

- what was decided
- what alternatives were considered
- why an approach was chosen
- what happened afterward

This helps future AI sessions understand not onlywhat exists, butwhy.

Projects evolve. Knowledge becomes outdated.

Contorium tracks whether decisions still hold:

Change → Assumption → Impact → Decision Validity

VALID → WARNING → DECAYING → SUSPECTED_INVALID → NEEDS_REVALIDATION → INVALIDATED

contorium ask "What decisions need review?"

Generate a compact representation of the project's current state for AI handoff.

New session ↓ Read everything again ↓ Reconstruct context ↓ Start working

New session ↓ Read project intelligence ↓ Understand current state ↓ Continue working

Contorium makes project intelligence accessible to both developers and AI agents.

contorium ask "Why was MCP added?" contorium ask "What changed recently?" contorium ask "What do we know about authentication?" contorium ask "Is this decision still valid?"

It is connecting the relevant pieces of project knowledge.

Workspace Activity ↓ Collection ↓ Parsing ↓ Project Structure ↓ Knowledge Graph ↓ Intent & State ↓ Project Intelligence ↓ AI-ready Context / Handoff ↓ Any AI Tool

Contorium stores project intelligence locally inside:

The project carries its own accumulated understanding instead of tying it to a particular AI provider or session.

Contorium separates project intelligence from the AI tool using a local, structured architecture.

AI Tools (Cursor · Claude · Codex · …) │ ▼ IDE · MCP · CLI (adapters) │ ▼ CIL — Cognitive Interaction Layer │ ▼ PIL — Project Intelligence Layer │ ▼ .contora/

CIL is theinteraction layerbetween AI agents, developers, and project intelligence.

It provides the mechanisms needed to query, capture, and transfer project knowledge.

It is architecture — not the product brand.

The deterministic local store of structured project intelligence:

STATE · INTENT · DECISION · WHY TIMELINE · IMPACT · PROVENANCE · CONFIDENCE

The intelligence stays with the project.

Deeper guides:](https://github.com/ContoriumLabs/contorium/blob/HEAD/docs/INTELLIGENCE_MODULES.md)docs/OVERVIEW.md·docs/PIL_RUNTIME.md·docs/CIL.md

contorium capture decision contorium inspect state contorium transfer context contorium ask "What is this project becoming?"

Contorium is related to AI memory — but it is not intended to be just another chat-memory or retrieval system.

What changed ↓ Why it changed ↓ What happened ↓ What remains true ↓ What comes next

Memory is a capability. Project Intelligence is the goal.

- an autonomous coding agent
- a replacement for your AI coding tool
- a task generator
- a system that decides what you should build
- a replacement for Git

Contorium preserves project understanding so humans and AI can work from the same evolving state.

- Node.js 18+
- npm
- VS Code / Cursor for the IDE extension
- An MCP-compatible AI tool for MCP integration

git clone https://github.com/ContoriumLabs/contorium.git cd contorium npm install npm run compile

- OpenExtensions
- SelectInstall from VSIX
- Choose the generated.vsix
- Reload the window
- Open your project
- Set the current focus
- Transfer AI-ready project context when needed

Full guide:docs/IDE_EXTENSION.md·docs/INSTALL.md

Expose project intelligence to MCP-compatible AI tools:

claude mcp add --scope project contorium -- npx @contorium/mcp

codex mcp add contorium -- npx @contorium/mcp

ask_project transfer_project inspect_state · inspect_intent · inspect_decision capture_focus · capture_note · capture_decision inspect_pending_decisions · commit_decision prepare_execution_context · get_project_context · explain_context get_knowledge_health · get_review_queue

Full guide:docs/MCP.md·packages/mcp/README.md

npx contorium init . npx contorium sync . npx contorium ask "What is this project?" npx contorium decisions detect npx contorium context build --task "…" npx contorium inspect npx contorium explain database npx contorium transfer context npx contorium lifecycle npx contorium review npx contorium status .

To remove the local project intelligence store:

Project understanding should survive sessions, tools, and model changes.

Relationships between decisions, code, intent, and history matter more than isolated text.

AI can understand the project. Humans decide what the project becomes.

Project intelligence should stay close to the project and remain portable.

Optional AI improves explanation, story, essence, and suggested questions.

AI is an interpreter — not the source of truth.

AI coding is moving beyond one-shot code generation toward long-running, multi-agent development.

Claude Desktop / Cursor

Paste into your MCP client config file to install this server.

{
    "mcpServers": {
        "contorium": {
            "contorium": {
                "command": "npx",
                "args": [
                    "@contorium/mcp"
                ],
                "env": {
                    "CONTORIUM_WORKSPACE": "/path/to/project"
                }
            }
        }
    }
}

McpServers

{
    "contorium": {
        "command": "npx",
        "args": [
            "@contorium/mcp"
        ],
        "env": {
            "CONTORIUM_WORKSPACE": "/path/to/project"
        }
    }
}

Project Intelligence Layer for AI-assisted development.

But it doesn't always knowwhy your project became what it is.

Contorium gives AI coding tools a persistent layer of project intelligence — preserving decisions, reasoning, constraints, structure, history, and evolving project state across sessions, tools, and models.

Not chat history. Not prompts. Project intelligence.

Website·Documentation·Overview·Decision Evolution & Retrieval

Git remembers what changed.
Contorium remembers why.

AI coding agents are getting better at writing and modifying code.

But long-lived projects have another problem:

The codebase contains what the project is — but not always why it became that way.

- AI sessions
- different coding tools
- model switches
- experiments and failed approaches
- architectural decisions
- long development cycles

Eventually, developers end up explaining the same project to AI again and again.

You should be building the project — not repeatedly explaining it.

Intent ↓ Decisions ↓ Reasoning ↓ Implementation ↓ Outcomes ↓ Evolution ↓ Current State

Contorium preserves and connects this information so AI tools can work from the project's accumulated understanding instead of reconstructing it from scratch every session.

Decisions
What was chosen, rejected, or changed?

Reasoning
Why was a particular approach taken?

Constraints
What must remain true, and why?

Structure
How are the project's modules, files, and functions connected?

Current State
What matters now, and what should happen next?

One Project. One Intelligence Layer. Every AI Tool.

Your project's accumulated understanding shouldn't have to.

Your Project │ ▼ ┌──────────────────────┐ │ Contorium │ │ │ │ Project Intelligence │ │ Layer │ └──────────┬───────────┘ │ ┌──────────┼──────────┐ ▼ ▼ ▼ Cursor Claude Codex │ Code │ │ │ │ └──────────┼──────────┘ ▼ Shared Understanding

Use the tools you prefer without forcing each one to reconstruct the project from zero.

- Cursor
- Claude Code
- Gemini CLI
- Codex
- VS Code
- MCP-compatible AI tools

- sessions
- tools
- model switches
- long development cycles

Contorium builds structured relationships across the project:

Intent ↓ Module ↓ File ↓ Function ↓ Dependency

Instead of treating a repository as a collection of disconnected files, Contorium builds a queryable representation of how the project fits together.

Track the changes that matter and connect them to the project's broader state.

Preserve the knowledge that is usually lost after a conversation ends:

- what was decided
- what alternatives were considered
- why an approach was chosen
- what happened afterward

This helps future AI sessions understand not onlywhat exists, butwhy.

Projects evolve. Knowledge becomes outdated.

Contorium tracks whether decisions still hold:

Change → Assumption → Impact → Decision Validity

VALID → WARNING → DECAYING → SUSPECTED_INVALID → NEEDS_REVALIDATION → INVALIDATED

contorium ask "What decisions need review?"

Generate a compact representation of the project's current state for AI handoff.

New session ↓ Read everything again ↓ Reconstruct context ↓ Start working

New session ↓ Read project intelligence ↓ Understand current state ↓ Continue working

Contorium makes project intelligence accessible to both developers and AI agents.

contorium ask "Why was MCP added?" contorium ask "What changed recently?" contorium ask "What do we know about authentication?" contorium ask "Is this decision still valid?"

It is connecting the relevant pieces of project knowledge.

Workspace Activity ↓ Collection ↓ Parsing ↓ Project Structure ↓ Knowledge Graph ↓ Intent & State ↓ Project Intelligence ↓ AI-ready Context / Handoff ↓ Any AI Tool

Contorium stores project intelligence locally inside:

The project carries its own accumulated understanding instead of tying it to a particular AI provider or session.

Contorium separates project intelligence from the AI tool using a local, structured architecture.

AI Tools (Cursor · Claude · Codex · …) │ ▼ IDE · MCP · CLI (adapters) │ ▼ CIL — Cognitive Interaction Layer │ ▼ PIL — Project Intelligence Layer │ ▼ .contora/

CIL is theinteraction layerbetween AI agents, developers, and project intelligence.

It provides the mechanisms needed to query, capture, and transfer project knowledge.

It is architecture — not the product brand.

The deterministic local store of structured project intelligence:

STATE · INTENT · DECISION · WHY TIMELINE · IMPACT · PROVENANCE · CONFIDENCE

The intelligence stays with the project.

Deeper guides:docs/OVERVIEW.md·docs/PIL_RUNTIME.md·docs/CIL.md

contorium capture decision contorium inspect state contorium transfer context contorium ask "What is this project becoming?"

Contorium is related to AI memory — but it is not intended to be just another chat-memory or retrieval system.

What changed ↓ Why it changed ↓ What happened ↓ What remains true ↓ What comes next

Memory is a capability. Project Intelligence is the goal.

- an autonomous coding agent
- a replacement for your AI coding tool
- a task generator
- a system that decides what you should build
- a replacement for Git

Contorium preserves project understanding so humans and AI can work from the same evolving state.

- Node.js 18+
- npm
- VS Code / Cursor for the IDE extension
- An MCP-compatible AI tool for MCP integration

git clone https://github.com/ContoriumLabs/contorium.git cd contorium npm install npm run compile

- OpenExtensions
- SelectInstall from VSIX
- Choose the generated.vsix
- Reload the window
- Open your project
- Set the current focus
- Transfer AI-ready project context when needed

Full guide:docs/IDE_EXTENSION.md·docs/INSTALL.md

Expose project intelligence to MCP-compatible AI tools:

claude mcp add --scope project contorium -- npx @contorium/mcp

codex mcp add contorium -- npx @contorium/mcp

ask_project transfer_project inspect_state · inspect_intent · inspect_decision capture_focus · capture_note · capture_decision inspect_pending_decisions · commit_decision prepare_execution_context · get_project_context · explain_context get_knowledge_health · get_review_queue

Full guide:docs/MCP.md·packages/mcp/README.md

npx contorium init . npx contorium sync . npx contorium ask "What is this project?" npx contorium decisions detect npx contorium context build --task "…" npx contorium inspect npx contorium explain database npx contorium transfer context npx contorium lifecycle npx contorium review npx contorium status .

To remove the local project intelligence store:

Project understanding should survive sessions, tools, and model changes.

Relationships between decisions, code, intent, and history matter more than isolated text.

AI can understand the project. Humans decide what the project becomes.

Project intelligence should stay close to the project and remain portable.

Optional AI improves explanation, story, essence, and suggested questions.

AI is an interpreter — not the source of truth.

AI coding is moving beyond one-shot code generation toward long-running, multi-agent development.

No reviews yet — be the first

Use Google, GitHub, or an email account so ratings stay tied to real people.

Email sign in

No reviews posted yet.