KLYPIX Project Brain
NPM · KLYPIX-MCP · SCANNED SEP 21
Active state management for multi-agent coding: a shared, versioned project brain over MCP.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 40 of 110 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to dahshanlabs/klypix-mcp). View diagnostics → Pass
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 2 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability40
- 0% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Fail
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 6727 tokens (~292/item across 23 items; 22 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management87
- Stability observed for 26 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 99% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 22 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 24 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
- Supports UI / widget rendering.Pass
How do I install the KLYPIX Project Brain MCP server?
KLYPIX Project Brain runs locally as an npm package, launched with npx -y klypix-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · klypix-mcp
claude mcp add dahshanlabs-klypix-mcp -- npx -y klypix-mcp
{
"mcpServers": {
"dahshanlabs-klypix-mcp": {
"command": "npx",
"args": [
"-y",
"klypix-mcp"
]
}
}
} {
"servers": {
"dahshanlabs-klypix-mcp": {
"command": "npx",
"args": [
"-y",
"klypix-mcp"
]
}
}
} codex mcp add dahshanlabs-klypix-mcp -- npx -y klypix-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"dahshanlabs-klypix-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"klypix-mcp"
],
"enabled": true
}
}
} openclaw mcp add dahshanlabs-klypix-mcp --command npx --arg -y --arg klypix-mcp
mcp_servers:
dahshanlabs-klypix-mcp:
command: "npx"
args: ["-y", "klypix-mcp"] {
"McpServers": {
"dahshanlabs-klypix-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"klypix-mcp"
]
}
}
} assistant mcp add dahshanlabs-klypix-mcp -t stdio -c npx -a -y klypix-mcp
{
"mcpServers": {
"dahshanlabs-klypix-mcp": {
"command": "npx",
"args": [
"-y",
"klypix-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 21 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 20 Sept 26 +15
- Malware scan: unverified → pass ▲ security
- 19 Sept 26 +1
- Package version: 1.86.1 → 1.86.2 functional
- 18 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 1.86.0 → 1.86.1 functional
- 17 Sept 26 +26
- Malware scan: unverified → pass ▲ security
- Known CVEs: unverified → pass ▲ security
- Dependency health: unverified → 0.83 ▲ functional
- 16 Sept 26 −25
- Known CVEs: pass → unverified ▼ security
- Malware scan: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Stability: 0.67 → unverified ▼ security
- Schema quality: 264 → 292 ▼ functional
- Dependency health: 0.83 → unverified ▼ functional
- Capabilities: pass → unverified ▼ functional
- Schema quality: 0 → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Package version: 1.84.0 → 1.86.0 functional
- Package version: 1.84.0 → 1.85.0 functional
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed npm/klypix-mcp@1.86.2
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | dahshanlabs/klypix-mcp |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/dahshanlabs/klypix-mcp/.github/workflows/publish.yml@refs/tags/v1.86.2 |
| Rekor log index | 2889826300 |
| Predicate type | https://slsa.dev/provenance/v1 |
| Subject digest | sha512:1136f15b523db0d158c7780783bef5af190294427b04897e6cc956caf3e01133be3bfe7893160c4813f9f78c6972ee0f8895bca9ad9e643e94cef62a6 |
Background: How many MCP packages publish verified provenance →
Dependencies 110 packages
| Packages resolved | 110 |
|---|---|
| Stale | 40 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_to_canvas Add cards to an existing canvas ~97
Append cards (and optional connections) to an existing v4 .klypix, preserving all existing items and their positions. New cards are placed to the right of the current content. Connections may reference new cards (by index/title) or existing cards (by title).
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | yes | Canvas filename, vault-relative path, or absolute path. |
| cards | array | yes | Cards to add. |
| connections | array | – | – |
No output schema declared.
No examples provided.
brain_ask Ask the project brain a question (whole-brain, correction-aware answer) ~282
Answer a natural-language question from the WHOLE project brain — "what did we decide about X?", "where did the auth work land?", "why did we drop Y?". Ranks every card lexically, blended with on-device semantic similarity ONLY when the optional local model is installed (a fresh install is lexical; it degrades cleanly). INCLUDES superseded/archived history (flagged, so you can see how a decision changed), and attaches each stale card's live CORRECTION so the answer reflects the current truth, not an outdated card. Returns a synthesis-ready context (full cards + provenance + lifecycle) for you to turn into a direct, cited answer — it does not itself write prose. Prefer this over search_canvases when the user asks a QUESTION (not a keyword lookup). Optional as_of (YYYY-MM-DD) answers "what was true then". Defaults to the project brain ("brain").
| Name | Type | Req | Description |
|---|---|---|---|
| as_of | string | – | Optional YYYY-MM-DD: answer as of that date (superseded cards count as live if they were current then). |
| canvas | string | – | Brain canvas filename/path. Defaults to the project brain ("brain"). |
| k | number | – | Max cards to surface for synthesis (default 10, capped 20). |
| question | string | yes | The natural-language question to answer from the brain. |
No output schema declared.
No examples provided.
brain_challenge Challenge a decision against the brain (argue back with receipts) ~209
BEFORE committing to a significant decision, ask the brain to ARGUE BACK: prior decisions that deterministically contradict the claim (correction-cue / opposite-polarity evidence — never mere topical similarity), 🛠 standing rules that dispute it, approaches tried before and REVERSED (with the correction/successor as the receipt), and open questions it collides with. Candidates, not verdicts — silence means "no deterministic contradiction signal", not verified consistency. Cards captured by a DIFFERENT agent are flagged so you coordinate instead of overriding. Dismiss a confirmed-false pair (after capturing the claim) with brain_connect pairs + relationship:"not_contradiction". Defaults to the project brain ("brain").
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | – | Brain canvas filename/path. Defaults to the project brain ("brain"). |
| claim | string | yes | The proposed decision/claim to argue against — one concise statement. |
| k | number | – | Max contradiction candidates to surface (default 8, capped 20). |
No output schema declared.
No examples provided.
brain_connect Connect related-but-unlinked brain cards (densify the graph) ~342
Repairs orphaned decision/milestone cards first (scope:"orphans", the default) by proposing genuinely related unlinked pairs — semantic similarity at a conservative 0.55 threshold when the on-device model is installed, else shared tags + [[mentions]]. The dry run includes a before→projected orphan receipt; apply:true draws only additive, removable arrows and reports the measured after count. It NEVER archives or rewrites cards. Use scope:"all" for deliberate whole-graph densification. To DISMISS a brain_reconcile false-positive contradiction, pass pairs:[{fromId,toId}] with relationship:"not_contradiction".
| Name | Type | Req | Description |
|---|---|---|---|
| apply | boolean | – | false (default) = suggest only; true = draw the connections. |
| canvas | string | – | Canvas filename/path. Defaults to the project brain ("brain"). |
| max | number | – | Max connections to propose/draw (default 24). |
| pairs | array | – | Explicit card-id pairs to connect (bypasses auto-proposal). Use to dismiss a reconcile false-positive: pass the two card ids with relationship:"not_contradiction". |
| relationship | string | – | Relationship for explicit `pairs` (e.g. "not_contradiction" to permanently dismiss a contradiction candidate, or "relates_to", "depends_on", "supports"). |
| scope | string | – | "orphans" (default) repairs isolated decision/milestone cards; "all" proposes across every live card. |
| threshold | number | – | Min semantic similarity 0–1. Default 0.55 for orphan repair; 0.45 for scope:"all". Higher = fewer, tighter links. |
No output schema declared.
No examples provided.
brain_doctor Brain doctor — is this brain current, wired, and in sync? ~311
Read-only self-check of the installed klypix brain, as ONE verdict: VERSION (deployed brain-core + optional npm currency), CLAUDE (existing 5-hook capture readiness), CODEX (automatic MCP presence plus optional enhanced-hook status), TOOLS (discoverable MCP verbs), SESSIONS (all active presence-adapter sessions across hosts, never recent-chat history), and HARNESS (projection drift). Use to answer "is my brain current, correctly installed, in sync, and who is actually live?" without file-spelunking. Never writes: the only side effects are read-only subprocess queries (git rev-parse / tag --list / log / merge-base with fixed argument arrays, and `npm view` only when check_npm is true) — it creates, edits, and deletes nothing. SCOPE: only CLAUDE and CODEX get behavioural verdicts. HARNESS classifies the projected config/rules FILES on disk — a project can read fully ok while no other host has ever actually loaded them, so do not report a clean HARNESS as "Cursor/Cline/Windsurf/Copilot is working". The MCP-callable twin of `npx klypix-mcp doctor`.
| Name | Type | Req | Description |
|---|---|---|---|
| check_npm | boolean | – | Also fetch npm latest to flag a stale brain (default false — this one does a network `npm view`). |
| project | string | – | Project dir to audit harness + peers for. Defaults to the server's working directory. |
No output schema declared.
No examples provided.
brain_garden Garden the brain — consolidate over-grown areas (sleep-time compute) ~519
Tidy an over-grown brain WITHOUT losing anything — SMART and non-invasive: it only consolidates DORMANT cards (old + peripheral), never load-bearing ones. Two phases: call it with no apply to get the areas that have accumulated forgotten cards (deterministic: >3 cards that are older than 14 days, beyond the area's newest 8, AND have ≤1 connection — so hubs and still-referenced decisions are left untouched; Focus/Instructions/Archive/Open-questions areas protected) plus their card text; YOU write one tight synthesis per area; then call again with apply:true, syntheses:[{title, synthesis}] AND the human's 8-char `approve` code (apply is REFUSED without it — you are never shown the code; the human generates it with `npx klypix-mcp garden-code` after reviewing your plan). Each area gets a 🌿 synthesis card, the originals are stamped "⤵ consolidated", moved to Archive, and arrowed to the synthesis — nothing is deleted, and one undo un-gardens. Run it when brain_insights or the brief shows an area has grown noisy. SEPARATE PASS: `repair:"duplicate-partials"` lists (and with apply:true collapses) cards that carry the SAME `✔ partial` note more than once — the residue of a partial ✓ on a card that stays live by design. It keeps the earliest note of each distinct body and removes only exact repeats, so nothing is archived, nothing is deleted, no synthesis and no approval code are needed, and a second run finds nothing.
| Name | Type | Req | Description |
|---|---|---|---|
| apply | boolean | – | false (default) = list over-grown areas + cards to synthesize; true = consolidate using the supplied syntheses. |
| approve | string | – | Required when apply:true — the 8-char human-approval code. You are never shown it: the human runs `npx klypix-mcp garden-code` and pastes the code into chat after reviewing your plan. Never guess or… |
| canvas | string | – | Brain canvas filename/path. Defaults to the project brain ("brain"). |
| repair | string | – | Run a targeted repair instead of the consolidation pass. "duplicate-partials" collapses repeated ✔ partial notes on a card to the earliest one — lossless, idempotent, no syntheses and no approval cod… |
| syntheses | array | – | Required when apply:true — one entry per area you want consolidated. |
No output schema declared.
No examples provided.
brain_insights What matters in a brain — hubs, orphans, stale questions ~187
Structural read of a brain.klypix: the most-connected "hub" cards (load-bearing decisions), orphaned decisions (no connections — maybe forgotten), stale open questions (aging & unresolved), and area sizes. Use to answer "what matters here / what am I forgetting / what should I review?" — read it at the start of a planning session, or before tidying.
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | – | Canvas filename/path. Defaults to the project brain ("brain"). |
| staleDays | number | – | Open questions older than this many days count as stale (default 21). |
| view | string | – | "areas" = a cheap category map (what sections exist + live counts) to orient BEFORE retrieving. "status" = where each active area stands (newest milestone + open count). "full" (default) = hubs, orph… |
No output schema declared.
No examples provided.
brain_lens Brain lens — machine-readable views of a brain (freshness · provenance · activity · timeline · orrery · unresolved) ~359
The data twin of the desktop app's Brain Lenses: ONE structured payload any surface (agent, web viewer, iOS) can render. Views: freshness (age buckets + stale open ❓), provenance (who wrote the brain, by channel: you/claude/cursor/git/gardener/…), activity (last 7 days), timeline (birth-order events — the Replay spine; events included only for view:"timeline"), orrery (focus+context neighborhood of one card: 1/2/3-hop ring-capped nodes + typed edges — pass root as a card title prefix or id, defaults to the most-connected hub), unresolved (open-❓ triage, oldest first, with typed evidence). Read-only by construction — it never writes. Use it to answer "what's rotting / who wrote this / what happened this week / what's around X / what's undecided" with receipts, or to feed a UI.
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | – | Canvas filename/path. Defaults to the project brain ("brain"). |
| limit | number | – | Cap for recent-activity entries (default 30). |
| root | string | – | Orrery center: a card title prefix or id. Default: the most-connected hub card. |
| staleDays | number | – | Open questions older than this count as stale (default 21). |
| structured | boolean | – | Also return the full machine-readable lens object (large — tens of KB). Default false: the markdown answers the question, and the object was previously attached to every call whether or not anything… |
| view | string | – | Which lens to compute (default "all" — every section, timeline events omitted from structured output unless view is "timeline"). |
No output schema declared.
No examples provided.
brain_message Message the other live agent sessions on this project (one-time note, not a brain card) ~304
Leave a DELIBERATE, targeted note for the OTHER active agent sessions working on this project right now ("merged the hook refactor — rebase before you commit", "don't touch canvasStore, mid-refactor"). Any MCP client can send and receive through the shared machine-local presence lane. A supported lifecycle event or KLYPIX tool result offers the note into model-visible context; a later independent supported action acknowledges that offer. Pending/offered notes replay after reconnect, while expiry or capacity loss leaves a failed per-recipient receipt instead of silently disappearing. Acknowledged means a later action followed the offer — it is NOT proof a human read it. A note then retires either by an explicit brain_message_receipt ("acted on it") or by AUTO-CONSUMPTION on a further independent action, with no receipt; your receipt line names which, and auto-consumption evidences activity, not uptake. Delivery remains OS-user-local, machine-local, bounded by a 24h TTL, and unavailable to a peer that never takes a supported action. Ephemeral and NOT persisted to the brain — for a durable decision use brain_note instead.
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | – | Brain canvas filename/path. Defaults to the project brain ("brain"). |
| text | string | yes | The note to deliver (kept to 400 chars). |
| to | string | – | Target hint — a peer session id-prefix or branch name; omit or "all" for every live session. |
No output schema declared.
No examples provided.
brain_message_receipt Confirm a KLYPIX coordination note was consumed ~140
Explicit durable receipt for a coordination note already offered into model-visible context and acknowledged by a later independent action. Call only after the note has actually been incorporated into the receiving agent's work. Requires the exact message id and one-time offer token returned with the offered note; identity, token, state, lock, and write mismatches fail closed and never silently mark consumption.
| Name | Type | Req | Description |
|---|---|---|---|
| message_id | string | yes | Exact coordination message id returned with the offered note. |
| offer_token | string | yes | Exact offer token returned with the offered note. |
| project | string | – | Absolute project root containing brain.klypix. Defaults to this MCP connection's current project. |
No output schema declared.
No examples provided.
brain_note Write a deliberate note to the project brain (decision / question / milestone / skill / resolve / update) ~612
Record something in the project brain ON DEMAND — the agent-neutral twin of the Claude-Code capture hook, so any client (Cursor / Cline / Desktop) can write the brain, not just read it. Unlike add_to_canvas (a flat append), this routes through the brain's capture engine, so a new decision SUPERSEDES a heavily-overlapping older one, ✓ RESOLVES/archives a matching card, closes: resolves the strategy/question a milestone fulfils, and ~ UPDATES a card in place — the full decision lifecycle, with dedup. Use marker "+" to record a 🛠️ SKILL — a reusable how-to/gotcha/convention ("always dedup zKeys before REORDER") that should resurface every session and never age out, distinct from a one-time decision. Use it to remember a decision, ask an open question, mark a milestone, log a skill, resolve a finished item, or correct a card. Defaults to the project brain ("brain").
| Name | Type | Req | Description |
|---|---|---|---|
| area | string | – | Area/topic — routes the card into that titled container and becomes a #tag (e.g. "Auth", "Release"). |
| canvas | string | – | Brain canvas filename/path. Defaults to the project brain ("brain"). |
| closes | string | – | Title or [[wikilink]] of a strategy/question card this note fulfils — resolves+archives it and draws a "closed by" arrow. |
| evidence | array | – | Supporting references. File bytes are fingerprinted as captured working-tree sources; hashes only detect source changes. On ~, [] clears evidence. Not accepted on resolve; use a milestone with closes… |
| guard | object | – | GUARD CARDS: make this '+' skill fire BEFORE a matching tool call runs (Claude Code PreToolUse denies on severity block; other hosts warn), not just resurface in briefs. The card stays a normal 🛠️ r… |
| marker | string | – | (none)=decision · ?=open question · !=milestone · +=🛠️ skill (reusable how-to/gotcha; always resurfaces, never ages out) · ✓=resolve+archive the best-matching card · ~=update the matching card in pl… |
| question | string | – | The question this note ANSWERS, phrased as someone would ask it ("how do we keep a draft separate from what runs?"). Recorded as retrieval enrichment beside the vector cache — never on the canvas — s… |
| text | string | yes | The note — one concise idea; the first line becomes the card title. |
| verify | string | – | Verification instructions or command text to retain and display. Never executed by KLYPIX. On ~, an empty string clears it. |
No output schema declared.
No examples provided.
brain_reconcile Reconcile the brain — contradictions, unrecorded migrations, and what a release already closed ~786
Truth maintenance. (1) CONTRADICTIONS: finds same-subject live card pairs where one carries an explicit correction cue (uppercase "CORRECTION", "was WRONG", "OBSOLETE" — that side is the presumed truth, UNLESS the cue predates its counterpart: then the pair is marked "presumed superseded" and the newer card is presumed current — verify before retiring) or the two use opposite polarity words (deferred↔wired, broken↔fixed, dead↔live), i.e. stale facts whose correction never got linked — candidates only, YOU confirm each: retire the stale card via brain_note ✓. Dismiss a FALSE positive (either kind) by connecting the two ids with brain_connect pairs + relationship:"not_contradiction" — persisted, so it never resurfaces (and its cue stops overlaying recall/ask for that pair). (2) MIGRATIONS: lists committed migration files (Supabase / Rails / Prisma / Knex / generic) that NO brain card references, so an applied-but-unnarrated rollout can be recorded. (3) LEGACY: pre-v1.15 raw-bash ship cards to tidy. (4) RELEASE: which open cards look fulfilled by the commits a release ref already carries (subject+body coverage, the card's own #commit- receipt, or a hint edge whose milestone is in the ref). READ-ONLY by default and on every other mode. THE ONE EXCEPTION: on mode "claims" and mode "release" you may pass confirm/dismiss to actually close what you verified — confirm names exact card ids, so nothing is matched by prose; covering only part of a multi-item clause writes "✔ partial" and KEEPS the card open unless you pass whole:true; a call whose every entry is refused leaves the brain byte-identical. Never reads the database or the network. Run it periodically, when recall surfaces something you believe is stale, or right before cutting a release.
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | – | Brain canvas filename/path. Defaults to the project brain ("brain"). |
| confirm | array | – | Pairs YOU verified. Honoured on mode "claims" and mode "release" only. Each confirmed card is stamped ✅, archived, and arrowed "closed by" to its evidence. |
| dismiss | array | – | Wrong hints to retire permanently as "not_fulfilled" edges between two CARDS — never re-suggested by claims, release, or the self-heal. A card-to-card pair is what makes the dismissal durable; a cove… |
| mode | string | – | Which pass to run (default "all"): contradictions · migrations · legacy (pre-v1.15 raw-bash ship cards to tidy) · claims (open "remaining:/next:" clauses a later milestone likely fulfilled — receipts… |
| note | string | – | One line of why, echoed in the receipt. |
| ref | string | – | mode "release": the git ref being cut. Defaults to this session's active release lease, else HEAD. |
| root | string | – | Project root holding the migrations dir / git repo (default: the brain file's folder). |
| sinceRef | string | – | mode "release": the baseline the range starts from. Defaults to the highest release-shaped tag in the repo. |
No output schema declared.
No examples provided.
brain_sync KLYPIX Context Gateway — synchronize task, peers, conflicts, and relevant memory ~709
APPROVAL-FREE task gateway over the authorized MCP connection. Call FIRST with a concise intent and expected files, again when scope changes, and with phase:"complete" before the final response. One bounded response returns compact task-relevant brain context, active TASK peers (idle connections hidden), one-time messages, structured exact-file conflicts, and late-arrival overlap alerts. A completion that supplies machine-checkable result manifests is fail-closed: invalid, conflicting, or incomparable evidence returns needs-reconciliation and retains task scope. Works on any MCP host — it needs only the authorized MCP connection, so native lifecycle hooks are optional. LIMITS: conflict matching is EXACT-PATH and both sessions must have declared their files, coordination/result reconciliation is machine-local and OS-user-local (a teammate on another machine is invisible), and file overlap remains ADVISORY.
| Name | Type | Req | Description |
|---|---|---|---|
| files | array | – | Project-relative files you expect to touch or have touched. Exact overlaps with peers are flagged. |
| include_context | boolean | – | Include fast task-relevant brain cards and offer queued coordination notes in the same response. Defaults true; false also defers note delivery so internal supervisor probes cannot consume model-visi… |
| intent | string | – | One sentence describing the current task. Supply for start/checkpoint; completion clears it. |
| phase | string | – | start replaces prior task scope; checkpoint merges changed scope; complete clears task intent/files. Default: checkpoint. |
| project | string | – | Nonempty absolute current project root that directly contains brain.klypix or brain.any. Supply it on phase "start" so routing stays correct even when the MCP host launches from its own install direc… |
| releaseClaim | object | – | Stake a durable claim that specific commits ride the NEXT release — the promise "you'll see it in the next build" made machine-readable. Unlike presence rows (which age out ~10min after a session end… |
| releaseIntent | object | – | Declare EXCLUSIVE intent to prepare a release of this project. The first declarer takes a ~2h lease (refreshed by checkpoints, freed by phase "complete", by expiry, or when the holder session ends);… |
| results | – | – | On phase complete, 1-8 result manifests for stable claim keys. The in-handler versioned validator rejects malformed, empty, unknown-field, or incomparable evidence and retains task scope. |
No output schema declared.
No examples provided.
canvas_view View a canvas as a spatial board (whiteboard-in-chat) ~156
Read any .klypix canvas/brain as a SPATIAL BOARD (defaults to the project brain): returns a text summary plus a structured render spec of cards, containers and connection arrows. It ALSO declares an MCP Apps (SEP-1865) UI resource, so a host with that extension can render the spec as an interactive read-only whiteboard — EXPERIMENTAL: no host has been observed rendering it, so do not promise the user a visual board. Hosts without the extension get the text summary, which is the verified path. Use when the user asks to SEE the canvas/brain/board layout, not just query it.
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | – | Canvas filename/path. Defaults to the project brain ("brain"). |
No output schema declared.
No examples provided.
create_canvas Create a KLYPIX canvas ~234
Create a new .klypix canvas from cards + connections and save it to the vault. The user opens it in the KLYPIX app (Canvas → Open). Prefer short, titled cards (one idea each) connected by meaningful arrows. For anything a person reads IN ORDER — steps, phases, checklists, sections — put the cards in `groups`: each group becomes a titled box with its cards stacked in the order given, boxes left-to-right; the loose grid follows arrows, not reading order, and scatters a sequence.
| Name | Type | Req | Description |
|---|---|---|---|
| cards | array | yes | The cards. 5-12 atomic cards is ideal for a mind-map; a checklist can be longer when grouped. |
| connections | array | – | Arrows between cards. |
| filename | string | – | Override the output filename (without extension). |
| groups | array | – | Titled boxes, each listing its member cards in reading order (index, title, or id). Ungrouped cards form a band above the boxes — good for the title card, a link, a legend. |
| title | string | yes | Canvas title (also the filename). |
No output schema declared.
No examples provided.
list_canvases List KLYPIX canvases ~31
List all .klypix / .any canvas files in the vault, with card and connection counts.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
project_map_context Project Map context - current code structure plus brain decisions ~348
Read-only combined context for a coding question. It queries a provider-neutral, bounded view of the generated project graph (Graphify graphify-out/graph.json is supported first) and places that CURRENT CODE evidence beside fast, correction-aware KLYPIX brain cards (decisions and rationale). KLYPIX never installs or runs Graphify and never copies graph nodes into brain.klypix. Missing graph artifacts degrade cleanly to brain-only context. Source-file anchors are accepted only when they stay inside the declared project root. Set deep_history:true only when superseded history is genuinely needed; the default never loads the local embedding model.
| Name | Type | Req | Description |
|---|---|---|---|
| compare_to | string | – | Optional project-relative prior graph JSON path. Adds exact total deltas plus bounded query-neighborhood changes; it may not escape the project root. |
| deep_history | boolean | – | false (default) uses the sub-second lexical-fast correction-aware path; true opts into whole-brain semantic/history retrieval, which may cold-load the local model. |
| depth | number | – | Relationship hops around the best code matches (0-3, default 1). |
| graph_path | string | – | Optional project-relative graph JSON path. Defaults to graphify-out/graph.json and may not escape the project root. |
| k | number | – | Maximum brain cards returned (default 8; fast mode caps 8, deep history caps 20). |
| max_nodes | number | – | Maximum code nodes returned (default 60, capped 200). |
| project | string | – | Absolute project root. Defaults to this MCP connection's configured project/vault. |
| question | string | yes | Question or code concept to ground in both current structure and project memory. |
No output schema declared.
No examples provided.
project_map_drift Check brain cards against the repo's real files (drift report) ~184
Read-only drift check: every brain card that references THIS project's files is verified against the working tree. Reports cards whose referenced files are gone or moved (with rename candidates by unique basename), and headlines the checkout's own position against its origin default branch — reporting BOTH ahead and behind, so a DIVERGED checkout is named as diverged rather than merely behind. In either state a "missing" file may simply not be in this checkout. Slash-joined name enumerations and other-project paths are recognized and skipped, not reported as drift. Nothing is written; fix cards with a CORRECTION marker or by editing them in KLYPIX.
| Name | Type | Req | Description |
|---|---|---|---|
| brain | string | – | Optional brain filename/path inside the project. Defaults to brain.klypix / brain.any. |
| project | string | – | Absolute project root. Defaults to this MCP connection's configured project/vault. |
No output schema declared.
No examples provided.
project_map_scan Scan the project natively - no-install file inventory + import map ~143
KLYPIX's own zero-install scanner: walks the repo (gitignore-aware, junk dirs like browser profiles and build output excluded), extracts FILE-LEVEL import edges for the JS/TS family (relative, tsconfig-alias, and monorepo-workspace imports resolved), and writes klypix-map/graph.json inside the project — the only thing it ever writes. The artifact then serves project_map_context automatically when no Graphify artifact exists. It deliberately does not build a per-symbol AST graph; deeper external artifacts remain importable through the same door.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | – | Absolute project root. Defaults to this MCP connection's configured project/vault. |
No output schema declared.
No examples provided.
read_canvas Read a KLYPIX canvas ~133
Read a canvas as structured markdown (every card, the connection graph, [[wikilinks]], #tags) AND attach its image assets so you can SEE them, not just their filenames (capped: the first 8 images under ~5MB each — a bigger canvas returns the rest as filenames only). Pass the canvas TITLE directly (e.g. "SS2") — a filename, vault-relative path, or absolute path also work; you do NOT need to list or search first.
| Name | Type | Req | Description |
|---|---|---|---|
| canvas | string | yes | Canvas title or filename (e.g. "SS2"), vault-relative path, or absolute path. |
No output schema declared.
No examples provided.
search_all_brains Search every project brain on this machine ~191
Cross-project memory search: looks through every brain.klypix this machine has REGISTERED, not just the current vault. Ranking is lexical, blended with on-device semantic similarity ONLY when the optional local model is installed (a fresh `npx klypix-mcp install` is lexical) — it degrades cleanly, never errors. Use when the answer may live in ANOTHER project's decisions. Optional as_of (YYYY-MM-DD) answers "what was true then" — superseded cards count as live if they were current at that date. The registry is populated by Claude lifecycle and by brain_sync on any MCP host; a project that has never started through either path is absent from cross-project search.
| Name | Type | Req | Description |
|---|---|---|---|
| as_of | string | – | Optional YYYY-MM-DD: rank what was TRUE at that date (time-travel query). |
| query | string | yes | What to find across all project brains. |
No output schema declared.
No examples provided.
search_canvases Search inside all canvases ~51
Search card text, titles, and #tags across every canvas in the vault. Returns the canvases and the matching cards.
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | yes | Text or #tag to find inside canvases. |
No output schema declared.
No examples provided.
What is the KLYPIX Project Brain MCP server?
KLYPIX Project Brain is an MCP server listed in the public MCP registry as io.github.dahshanlabs/klypix-mcp. Active state management for multi-agent coding: a shared, versioned project brain over MCP. This page covers its npm package (klypix-mcp).
Is the KLYPIX Project Brain MCP server safe to use?
KLYPIX Project Brain scores 87 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the KLYPIX Project Brain MCP server expose?
KLYPIX Project Brain exposes 22 tools: list_canvases, read_canvas, search_canvases, search_all_brains, brain_ask, and 17 more. Their descriptions and schemas cost roughly 6,328 tokens of context every time the server is loaded.
Is the KLYPIX Project Brain MCP server still maintained?
KLYPIX Project Brain is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the KLYPIX Project Brain MCP server under?
KLYPIX Project Brain declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.