Server data from the Official MCP Registry
Persistent knowledge graph and MCP server for AI workflows with git-tracked project context.
About
Persistent knowledge graph and MCP server for AI workflows with git-tracked project context.
Security Report
Valid MCP server (1 strong, 1 medium validity signals). 1 known CVE in dependencies Package registry verified. Imported from the Official MCP Registry.
3 files analyzed · 2 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
How to Install
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-wandercom-kindex": {
"args": [
"kindex"
],
"command": "uvx"
}
}
}Documentation
View on GitHubFrom the project's GitHub README.
Kindex
Every agent is smart inside its own silo. Kindex lets them work together.
Kindex does one thing. It knows what you know.
Claude Code, Codex, Gemini CLI, Google Antigravity, OpenCode, Cursor, and other MCP-capable agents each remember for themselves, and none of them can read the others. Kindex is the local knowledge graph they all read and write: continuity across sessions and restarts, handoffs between vendors, shared decisions and constraints, and live coordination while several of them work at once. Available as a free MCP plugin or standalone CLI.
Memory plugins capture what happened. Kindex captures what it means and how it connects. Most memory tools are session archives with search. Kindex is a weighted knowledge graph with typed nodes, provenance, and decay, that surfaces constraints and decisions and manages exactly how much context to inject based on your available token budget.
Kindex is the index for an individual and a codebase: your own graph, and the repository's git-tracked .kin/. Kinbase is the company product above it, in development: engineering direction, architecture, standards, ownership, and history, held by named authorities and composed into every coding session. Same engine, same protocol, physically separate stores.
Docs: kindex.tools is the canonical public site, served by the companion Fly static app. This repo also publishes its docs/ directory at wandercom.github.io/kindex. Human setup lives in docs/human-guide.md; agent operating rules live in docs/mcp-agent-guide.md.
Install
Development preview: Claude function hooks and signet-eval coexistence
adds repo-local durable tasks, secret minimization at Kindex-owned boundaries,
and separately selectable modern/legacy adapters. The default remains compatible
legacy hooks. The modern adapter is a Claude Code mod: it installs on Claude Code
2.1.287 or newer when that host's claude plugin validate accepts it (last
verified on 2.1.288). This is not a promise that all Claude logs can be redacted
or a published 1.0 release.
Pick whichever installer you already use. They all install the same kin and kin-mcp binaries.
# pip
pip install 'kindex[mcp]'
# uv (single binary, no virtualenv)
uv tool install 'kindex[mcp]'
# uvx (no install — runs from cache, useful for one-off MCP invocation)
uvx --from 'kindex[mcp]' kin-mcp --help
# from source
git clone https://github.com/wandercom/kindex && cd kindex && make install
Upgrading to v0.36.0
[!WARNING] Before upgrading, stop every Kindex daemon, MCP server, and older CLI process. A v0.35.x process does not reject schema v12 and can write non-canonical session paths after migration.
Dream is Kindex's background knowledge-consolidation pass: it finds related
nodes, safely merges strong duplicates, and stages weaker links for review.
The first v0.36.0 process to open an older graph creates a transaction-safe
pre-migration snapshot under
$XDG_STATE_HOME/kindex/snapshots/<db>-<hash>/migrations/ (defaulting below
~/.local/state/kindex/snapshots/) before atomically migrating schema v11 to
v12. The owner-private snapshot passes SQLite integrity and source-version
checks, and a partial file is deleted if creation or validation fails.
Concurrent v0.36+ processes serialize this step through a dedicated
rollback-journal SQLite lock and recheck the schema after waiting. Migration
recovery points are retained outside the rotating ten-file
automated-merge snapshot pool. Older duplicate active session tags become paused
history, one active tag per normalized project and name is enforced, and Dream
suggestions carry an explicit title-or-node-ID identity contract and title
ambiguity is refused. No node or edge rows are deleted; legacy
domain-co-membership edges remain available as stored history but no longer
participate in semantic traversal or health metrics. kin status exposes the
durably recorded recovery path; normal stores also record it in kin changelog.
Rolling back the schema migration
Do not open the migrated database with v0.35.x: that version has no forward-schema guard and can write old, non-canonical session identity. Instead:
- While v0.36 is still installed, run
kin statusand record theRecoverypath. It names the latest validated migration attempt; older attempts remain in the samemigrations/directory. - Stop every Kindex process again.
- Move the live database's
-waland-shmsidecars aside. - Copy the recorded snapshot over the live database.
- Only then install or run v0.35.x and verify the graph.
This differs from recovering a bad automated merge,
which does not change package versions. Graph-health consumers must also
recalibrate: existing node/edge/orphan/component outputs now describe the
semantic graph, while explicit stored counts expose retained lifecycle and
legacy rows. Machine-readable stats identify this contract as metrics_schema: 2.
Then initialize the graph:
kin init
Extras — combine in one install ('kindex[mcp,llm,reminders]') or use 'kindex[all]':
| Extra | Adds |
|---|---|
mcp | kin-mcp MCP server (for Claude Code, Codex, Gemini, Antigravity, OpenCode, Cursor, etc.) |
llm | Anthropic-powered extraction (kin learn, kin ask) |
vectors | sqlite-vec for semantic similarity search |
reminders | Natural-language time parsing for kin remind |
all | Everything above |
Homebrew and apt packages aren't published yet. Use
pip,uv tool,uvx, or source until they are.
Install as Agent MCP Plugin
Each agent reads MCP servers from a different config file. The kin setup-*-mcp commands write the right shape into the right path; the manual snippet is shown alongside in case you'd rather edit the file yourself.
Claude Code
As a plugin (MCP server, skills, and session hooks in one install):
claude plugin marketplace add wandercom/kindex
claude plugin install kindex@kindex
or, inside a session, /plugin install kindex --marketplace wandercom/kindex.
What the plugin runs:
- MCP server (
scripts/claude-plugin/kin-mcp): your installedkin-mcpwhen one is onPATH, so the server and thekinCLI share one version and one database. Otherwise it runs the matching PyPI release withuvx --from 'kindex[mcp]==<version>' kin-mcp, which downloads kindex and its dependencies from PyPI once and caches them. That needs uv; without uv or kindex it exits with an install hint. - Hooks (
hooks/hooks.json, throughscripts/claude-plugin/kin): session start, prompt submit, pre-tool-use, pre-compact and stop call your installedkinto prime context, check prompts against the graph and capture the session. Without an installedkinthey do nothing. They source~/.profilefirst so akininstalled by pipx, uv or Homebrew is found. - Skills:
kindex-prime,kindex-capture,kindex-learn.
Everything stays on your machine: the graph is a local SQLite database
(~/.kindex/ and per-repo .kin/). Nothing is sent anywhere unless you
configure an LLM or embedding provider (see Privacy).
Or as a bare MCP server:
claude mcp add --scope user --transport stdio kindex -- kin-mcp
kin init
Or add .mcp.json to any repo to register the server for that project:
{ "mcpServers": { "kindex": { "command": "kin-mcp" } } }
Registration scope does not restrict graph access. For an agent that should use
only one repository's memory, run kindex-lite --repo /absolute/path/to/repo
instead. It binds the MCP server to that repository's .kin graph and Kinbase
reads, without global-graph fallback. Kinbase submission and write-capable status
require the launcher's --allow-kinbase-submit; --no-kinbase omits Kinbase entirely.
See repository-bound MCP
for configuration and the isolation boundary.
The MCP server exposes 50+ native tools to supported clients: search, add, context, show, ask, learn, link, edit, supersede, list_nodes, status, suggest, candidate_*, verify, invalidate, stale_check, graph_stats, graph_merge, dream, changelog, ingest, tag_start, tag_update, tag_resume, query_context, task_claim, coord_*, lock_acquire, lock_release, remind_*, mode_*, and more.
For explicitly scoped read-only query preparation and optional additive retained
evidence, see query context. The supported pilot paths
are kin context-query and full MCP query_context.
Offline recall cues are an experimental, disabled-by-default lexical sidecar.
Explicitly prepare a bounded batch with kin recall-cues build --limit 100
(repeat --node ID to select sources), and inspect counts with
kin recall-cues status; both accept the shared --config, --data-dir,
--profile and --json flags after the subcommand. MCP exposes the same
operations as recall_cues_build(node_ids=None, limit=100) and
recall_cues_status().
Enable supplemental retrieval in your selected configuration:
recall_cues:
enabled: true
candidate_limit: 20 # 1..100 additional source candidates
rank_weight: 0.10 # relative ranking weight; not factual confidence
Builds make no provider calls and change only derived metadata. Each source
gets at most three aliases or framed exact source spans; source alias origin
does not assert human authorship. The index uses only the supporting source
wording, while answers and context receive only original source nodes. This
extractive arm cannot invent missing synonyms or demonstrate personalized
memory benefits. It has an additional candidate/index budget, so compare it
with ordinary retrieval explicitly. Source changes invalidate cues immediately;
run an explicit bounded rebuild to refresh them. Roll back retrieval by setting
enabled: false; stored sidecars remain available for later rebuilding. There
is no automatic maintenance, generation service, or background scheduling.
For coding agents, install both the MCP server and the instruction file. The
instruction file tells the model how to use kindex: start a session tag, read
tracked .kin/config, check project policy, search before adding, capture
durable decisions, and end the tag with a summary.
Codex
kin setup-codex-mcp
kin setup-codex-hooks
kin setup-agents-md --install --global
kin ingest codex-sessions # optional: backfill saved Codex sessions
setup-codex-hooks installs a SessionStart hook (alongside the prompt/tool attention hooks), so Codex begins each session with the same auto-primed context and "use kindex" / .kin directive as Claude Code. Codex runs new or changed hooks only after you trust them, at its startup review prompt or in /hooks; until then it does not run them, SessionStart included.
Or hand-edit ~/.codex/config.toml:
[mcp_servers.kindex]
command = "kin-mcp"
Gemini CLI
kin setup-gemini-mcp
kin setup-gemini-md --install
Or hand-edit ~/.gemini/settings.json:
{ "mcpServers": { "kindex": { "command": "kin-mcp", "args": [] } } }
Google Antigravity
kin setup-antigravity-mcp
kin setup-antigravity-hooks
kin setup-antigravity-md --install
setup-antigravity-mcp writes the standalone MCP config shape used by
Antigravity's editor/shared config and CLI config. setup-antigravity-hooks
installs PreInvocation priming/prompt checks, PreToolUse advisory attention and
permission gating for Kindex config writes, and Stop-time reinforcement enqueue.
Or hand-edit ~/.gemini/config/mcp_config.json and
~/.gemini/antigravity-cli/mcp_config.json:
{ "mcpServers": { "kindex": { "command": "kin-mcp", "args": [] } } }
Muse
kin setup-muse-mcp
Muse reads ~/.config/muse/settings.json (camelCase mcpServers; never add a
legacy mcp_servers key, which makes Muse drop every MCP server). Muse already
loads Claude Code and Codex personal rules, so kin setup-agents-md --install --global
covers its directives. Muse does not run Claude or Codex hooks, and Kindex does
not yet install Muse-native hooks. Or hand-edit:
{ "mcpServers": { "kindex": { "type": "stdio", "command": "/opt/homebrew/bin/kin-mcp", "args": [], "mode": "optional" } } }
OpenCode
kin setup-opencode-mcp
kin setup-opencode-hooks
kin setup-agents-md --install --global
Or hand-edit ~/.config/opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"kindex": { "type": "local", "command": ["kin-mcp"], "enabled": true }
}
}
OpenCode reads AGENTS.md natively, so install the MCP server and the shared AGENTS.md instructions together.
The OpenCode plugin supplies periodic supervisor advice on the primary user message. See supervision and independent health for configuration and notification setup.
Cursor
kin setup-cursor-mcp
kin setup-cursor-hooks
kin setup-cursor-rules --install # writes ~/.cursor/rules/kindex.mdc
Or hand-edit ~/.cursor/mcp.json:
{ "mcpServers": { "kindex": { "type": "stdio", "command": "kin-mcp" } } }
Cursor integration includes MCP, always-applied rules, and native supervisor hooks. The adapter has automated boundary coverage; authenticated Cursor model delivery and IDE activity discovery remain unverified. No Cursor account is needed to use Kindex with the other supported agents. See supervision and independent health.
Remote agents (HTTPS behind Cloudflare Access)
kindex-remote (extra kindex[remote]) serves your graph over streamable HTTP
to agents on other machines. It listens on loopback only; a Cloudflare Tunnel
publishes it and a Cloudflare Access application authenticates every caller:
Managed OAuth for interactive agents (Claude Code, Codex, claude.ai connectors)
and a service token for headless ones. The server also verifies the Access JWT
(Cf-Access-Jwt-Assertion: signature, audience, issuer) on every request.
kindex-remote --access-team-domain <team>.cloudflareaccess.com \
--access-aud <application AUD tag> --public-host app.example.com --port 8767
Only graph tools are served (search, context, add/edit/learn/link, tasks, tags,
coordination, watches, ask). Tools that run commands, read host paths or ingest
from the host (reminders, ingest, modes, maintenance, Kinbase, task_execute)
are not, nor is graph_stats. add accepts only URL referents, task tools
refuse project_path, and show does not resolve saved sources. Tool calls run
one at a time on a worker thread, off the request loop.
The Access application needs Managed OAuth with dynamic client registration
enabled (and the client's callback URLs allowed) for interactive agents. Connect
one with claude mcp add --transport http kindex https://app.example.com/mcp
(OAuth opens a browser once); a headless client sends CF-Access-Client-Id and
CF-Access-Client-Secret headers instead.
Why Kindex
Context-aware by design
Five context tiers auto-select based on available tokens. When other plugins dump everything into context, Kindex gives you 200 tokens of executive summary or 4000 tokens of deep context — whatever fits. Your plugin doesn't eat the context window.
| Tier | Budget | Use Case |
|---|---|---|
| full | ~4000 tokens | Session start, deep work |
| abridged | ~1500 tokens | Mid-session reference |
| summarized | ~750 tokens | Quick orientation |
| executive | ~200 tokens | Post-compaction re-injection |
| index | ~100 tokens | Existence check only |
Knowledge graph, not log file
Nodes have types, weights, domains, and audiences. Edges carry provenance and decay over time. The graph understands what matters — not just what was said.
Operational guardrails
Constraints block deploys. Directives encode preferences. Watches flag attention items. Checkpoints run pre-flight. No other memory plugin has this.
Answers from dated evidence
kin ask answers in one model call from dated evidence: the matching nodes in chronological order with today's date and your standing directives, trimmed to the messages that bear on the question, within a small budget for a single fact and a wider one for counts, lists, orderings, summaries and advice. Conversation facts and per-person profiles written by kin digest let it answer from a few thousand tokens, and relative dates in the evidence arrive already resolved. With conversations.claims: true in your config, kin digest records turn-level claims instead of per-conversation facts, each tied to the message it came from (its place in the conversation and its words); kin digest --claims converts conversations digested earlier. In a terminal the answer streams as it is written. The answer rules cover updated values, counts across conversations, date arithmetic and missing details. The defaults suit an agent asking about its own graph: today's date is the clock's (or --as-of), reasoning effort is ask.effort (medium), and a question that gets a version, name or date wrong is told what the record says. ask.preset: benchmark restores the configuration the published LoCoMo, LongMemEval-S and BEAM scores were measured with (docs/benchmarks/); pass each question's date with --as-of to reproduce them. A directive kin digest reads from an imported chat applies once you confirm it (kin set-state <id> confirmed true), and conversations.profiles: true also writes per-person profiles. kin ingest conversations --directory DIR stores chat transcripts without loss for it to search. The MCP ask tool returns the same dated evidence to the agent that called it (and drafts the answer itself with answer=true); context(level="evidence") returns it for a topic.
Claim revisions include source expiry, so changing or removing an expiry refreshes derived claims on the next requested claims backfill. Retraction also clears that conversation's claim revision, allowing an identical re-import to regenerate claims. Older revision keys refresh once on the next explicit kin digest --claims, including conversations without expiry; this can use the configured model budget. Claims remain off by default, and upgrading does not start a backfill.
Team and org ready
.kin inheritance chains let a service repo inherit from a platform context, which inherits from an org voice. Private/team/org/public scoping with PII stripping on export. Enterprise-ready from day one.
In Practice
A 162-file fantasy novel vault — characters, locations, magic systems, plot outlines — ingested in one pass. Cross-referenced by content mentions. Searched in milliseconds.
$ kin status
Nodes: 192
Edges: 11,802
Orphans: 3
$ time kin search "the Baker"
# Kindex: 10 results for "the Baker"
## [document] The Baker - Hessa's Profile and Message Broker System (w=0.70)
→ Thieves Guild, Five Marks, Thieves Guild Operations
## [person] Mia and The Baker (Hessa) -- Relationship (w=0.70)
→ Sebastian and Mia, Mia -- Motivations and Goals
0.142 total
$ kin graph stats
Nodes: 192
Edges: 11,802
Density: 0.3218
Components: 5
Avg degree: 122.94
192 nodes. 11,802 edges. 5 context tiers. Hybrid FTS5 + graph traversal in 142ms.
Getting Agents to Actually Use It
Installing the MCP plugin gives the agent the tools. But agents won't use them proactively unless you tell them to. Kindex ships with recommended instruction blocks that turn passive tools into active habits. For the full agent playbook, see docs/mcp-agent-guide.md.
# Claude Code
kin setup-claude-md --install
# Codex (and OpenCode — both honor AGENTS.md)
kin setup-agents-md --install --global
# Gemini CLI
kin setup-gemini-md --install
# Google Antigravity
kin setup-antigravity-md --install
# Cursor — writes ~/.cursor/rules/kindex.mdc with alwaysApply: true
kin setup-cursor-rules --install
This adds session lifecycle rules (start/orient/during/segment/end), explicit capture triggers (discoveries, decisions, tasks, key files, notable outputs), and search-before-add discipline. The difference between "the agent has a knowledge graph" and "the agent actively maintains a knowledge graph" is this block.
For durable work, agents should use Kindex's persistent task and knowledge
surfaces rather than host-session-only task state. Use task_add, task_list,
and task_done for work that must survive the current conversation; search
before adding knowledge; prefer edit or supersede over duplicate nodes; and
treat tracked .kin files as shipped project state, not local cache.
If the host also exposes session-local task tools, use those only for temporary
planning; durable work belongs in Kindex.
For MCP clients in a repository, retain either project- or global-qualified
references when reads supply them, and pass them unchanged to follow-up tools.
In dual-graph sessions, use those qualified evidence IDs in source_refs when
a new node or task derives from existing knowledge. Ordinary single-store and
profile responses keep legacy raw IDs; source_refs does not accept those raw
IDs. Search again after restarting the MCP server because qualified reference
tokens are bound to its store selection. See Profiles for read
scopes and write routing.
The Claude SessionStart hook (kin setup-hooks) and Codex hooks (kin setup-codex-hooks) reinforce these directives at the start of supported sessions with a "Session directives" block that reminds the agent to use kindex MCP tools throughout the session.
What gets captured
With the directives active, the agent will:
- Search the graph before starting work and before adding nodes
- Add discoveries, decisions, key files, notable outputs, and new terms as they emerge
- Link related concepts when connections are found
- Learn from long files and outputs via bulk extraction
- Tag sessions to track work context across conversations
- Remind with actions for deferred tasks (shell commands or headless agent wakeups)
Actionable Reminders
Reminders can carry shell commands, natural-language instructions, or a headless agent wakeup. Codex, Claude, Antigravity, Cursor, OpenCode and Muse can start or resume a turn using their documented CLI surfaces. Explicit session IDs and the creation-time working directory are preserved. Codex can queue to the same session after a recognized active-writer conflict; queue acceptance is not execution confirmation. Other clients offer headless resume, not live injection.
Notifications default to an output channel writing to /dev/null, independently
of wakes. Set reminders.output_destination or --destination to an absolute
file/device path, fd:N, or an HTTP(S) POST endpoint. Output failures never trigger
terminal/system fallback. Existing explicit channel configurations remain valid.
See notification routing for supported transports,
configuration, failure states, and migration guidance.
remind_create stores the reminder. A later kin remind check, kin remind exec,
kin cron, or installed kin setup-cron schedule must run it. No UI automation or
permission bypass is used. last is pinned when the reminder is created, never
resolved at firing time.
Hook-time reminder injection uses a scoped reminder board. When a client supplies a chat/session id (conversation_id, chat_id, session_id, CLAUDE_SESSION_ID, CODEX_SESSION_ID, OPENCODE_SESSION_ID, CURSOR_SESSION_ID, etc.), Kindex injects only reminders scoped to that id plus reminders explicitly marked --scope global. Legacy unscoped reminders still work for manual kin prompt-check, daemon checks, and notifications, but they are not injected into an identified chat by default.
# Kill a cloud instance in 1 hour (but download results first)
kin remind create "Kill vast.ai instance" --at "in 1 hour" \
--action "vastai destroy instance 12345" \
--instructions "Download results from /workspace/ before killing"
# Wake a headless Codex or OpenCode turn when due
kin remind create "Continue rollout check" --at "in 10 minutes" \
--wake codex --session last --cwd "$PWD" \
--instructions "Check the rollout and fix any new failures."
kin remind create "Continue OpenCode build" --at "in 10 minutes" \
--wake opencode --session last --cwd "$PWD" --wake-agent build \
--instructions "Continue the build triage."
# Chat-scoped or intentionally global hook-visible reminders
kin remind create "Deploy checklist" --at "tomorrow 9am" \
--conversation-id "$CLAUDE_SESSION_ID" --attention-trigger deploy
kin remind create "Monthly billing review" --at "next Monday 9am" --scope global
# Manual trigger
kin remind exec --reminder-id <id>
Dream — Knowledge Consolidation
Kindex can run fuzzy deduplication, auto-apply high-confidence pending suggestions, and stage bounded domain-link proposals for review. Resolved fuzzy matches are not recreated. The pending domain-review queue is capped per graph (reminders.dream_max_domain_link_suggestions, 50 by default), proposals are round-robin across domains, and rejected pairs stay rejected. The setting lives under reminders because scheduled and Stop-hook Dream runs use the reminder/maintenance configuration. Shared domains are never materialized directly as semantic edges. Like memory consolidation during sleep — replay important paths and prune noise without turning tags into topology.
# See exact merge and domain-link proposals (no changes)
kin dream --dry-run
# Run full consolidation
kin dream
# Fast path: dedup + suggestions only
kin dream --lightweight
# Include LLM-powered cluster summarisation
kin dream --deep
# Fork and return immediately; repeated detached starts are throttled
kin dream --detach --lightweight
Default triggers are manual CLI, periodic cron (step 11 of kin cron), and a throttled detached Stop hook. File locking prevents concurrent cycles, and reminders.dream_min_interval prevents hooks or cron from relaunching dream repeatedly after a recent start. Set reminders.dream_on_stop_enabled: false to disable Stop-time detached dream while leaving manual and cron dream available.
Conversation Modes
Modes are reusable conversation-priming artifacts that induce a processing mode in an AI session. Based on research showing that induced understanding outperforms direct instruction by 5.4x, and that 15 tokens of mode-setting capture 98.8% of achievable priming benefit.
Five built-in modes: collaborate, code, create, research, chat. Create custom modes from any session and export them for team sharing (PII-free).
# Seed default modes
kin mode seed
# Activate a mode — outputs the priming artifact
kin mode activate collaborate
# Create a custom mode
kin mode create debug-session \
--primer "We're hunting a bug. Precision over speed..." \
--boundary "Show your reasoning chain. Name assumptions." \
--permissions "Speculate about root causes freely."
# Export for team sharing (PII-stripped)
kin mode export collaborate > collaborate.json
# Import a teammate's mode
kin mode import their-mode.json
Modes are not instructions — they're state inductions. A primer establishes how to think, a boundary defines what quality means, and permissions state what's allowed. The AI shifts processing mode rather than following a checklist.
Quick Start
# Add knowledge (with optional tags)
kin add "Stigmergy is coordination through environmental traces" --tags biology,coordination
# Search with hybrid FTS5 + graph traversal
kin search stigmergy
kin search coordination --tags biology # filter results by tag
# Ask questions (with automatic classification)
kin ask "How does weight decay work?"
# Get context for AI injection
kin context --topic stigmergy --level full
# List and filter by tags
kin list --tags python,ml # nodes tagged with both
kin list --type concept --tags ai # combine type and tag filters
# Track operational rules
kin add "Never break the API contract" --type constraint --trigger pre-deploy --action block
# Check status before deploy
kin status --trigger pre-deploy
# Ingest from all sources
kin ingest all
# Session tags — named work context handles
kin tag start auth-refactor --focus "OAuth2 flow" --remaining "tokens,tests"
kin tag segment auth-refactor --focus "Token storage" --summary "Flow design done"
kin tag pause auth-refactor --summary "Waiting for review"
kin tag resume auth-refactor # reactivate and render admission-controlled context
kin tag end auth-refactor --summary "All done"
# After 60 days, `kin cron` step 8 (or `kin archive run`) moves completed,
# unlinked session tags from the fast graph (the live database) into the slow
# archive (separate SQLite files searched explicitly). Active, paused, and
# artifact-linked sessions stay in the fast graph.
kin archive run
kin archive list # warns if an interrupted move left an ID in both stores
kin archive search auth-refactor
kin archive restore <session-node-id>
# Reminders — never forget, never nag
kin remind create "standup" --at "every weekday at 9am" --priority high
kin remind create "reply to Kevin" --at "in 30 minutes" --priority urgent
kin remind list
kin remind snooze --reminder-id <id> --duration 1h
kin remind done --reminder-id <id>
Trust, Capture Review, and Bounded Resume
Kindex keeps automatic extraction separate from durable knowledge. The pre-compact hook stages review candidates; it does not create graph nodes or edges. Inspect and resolve candidates explicitly:
kin candidate list --status pending
kin candidate show <candidate-id> # exact untrusted payload + freshness token
kin candidate accept <candidate-id> \
--review-token <token> --by "reviewer" --method "manual-review"
kin candidate reject <candidate-id> --by "reviewer" --code not_relevant
kin candidate prune # expire candidates whose TTL elapsed
kin candidate erase <candidate-id> # remove any candidate or receipt
The review token detects changes between show and accept. It is not authentication, authorization, or proof of reviewer identity. Candidate source text is retained only as a SHA-256 digest, and accepted, rejected, or expired candidates are reduced to minimal receipts. Human candidate output is visibly delimited because its content is untrusted.
Verification is also explicit and records asserted local audit text:
kin verify <node-id> --by "reviewer" --method "source-check" \
--valid-at 2026-08-18T12:00:00Z
kin invalidate <node-id> --by "reviewer" --code superseded \
--at 2026-09-01T00:00:00Z
# Ordinary search/context remain legacy-compatible recall.
kin search deployment
kin search deployment --trusted-only
kin context --topic deployment --trusted-only
Trusted-only search/context and kin tag resume admit only active, explicitly
verified, currently valid, non-contradicted knowledge. Resume output includes an
authority warning and machine-reason omission counts. Its legacy --tokens
option is an exact UTF-8 byte budget by default; direct library callers can pass
a provider's exact token counter when they require a provider-token guarantee.
Non-positive resume budgets return no output.
Referent Binding and Verifiable Staleness
A node can bind the external thing its claim describes — a file, URL, or repo
state — with a content digest and two clocks: asserted_at (when the claim was
made) and true_of (when the referent was observed in the digested state).
Staleness then stops being a heuristic and becomes a measurement:
# Bind at capture time (file paths are hashed now; binding implies direct
# creation, so the exact claim text is what gets bound)
kin add "The parser in src/parse.py handles escapes" --referent src/parse.py
# Re-hash every bound claim; a moved or missing referent demotes the node
# from trusted recall and lists it as a re-verification candidate
kin stale
# After confirming a claim still holds for the new state, rebind it
# (true_of moves to now; the claim is never re-dated)
kin stale --rebind <node-id>
Detection never deletes or rewrites content: a stale claim stays recallable,
visibly marked [stale-referent] in search and context output, and drops out
of --trusted-only projections until re-verified. URL and repo-scope bindings
are recorded with explicit digests (--referent-digest) and surfaced but never
auto-fetched.
Kindex also snapshots the SQLite store (rotating, ten per database) before any
automated destructive merge, so a false graph_merge or dream-cycle merge is
recoverable — see the human guide's restore section.
Automatic candidates expire after seven days by default. Configure a positive retention period in global or project config:
capture:
candidate_ttl_days: 7
Grounded Retrieval — When the Graph Knows Nothing
Vector search returns the nearest neighbours for any query, however unrelated. Without a floor a near-null question still pulls real nodes into an agent's context, and the graph can never say "I don't know."
Kindex calibrates a similarity floor against your own corpus and reports a verdict with every result set:
# Measure the null-query similarity distribution and record the floor
kin embed calibrate
# Inspect the current record without recalibrating
kin embed calibrate --show
The floor is never a config value. It is an immutable, versioned record keyed
by provider:model that carries the corpus it was measured against — node
count, embedding count, sample size, timestamp — so a floor calibrated when 2%
of your graph was embedded is detected as stale rather than silently trusted.
Config holds only the policy:
grounding:
enabled: true
enforce: false # shadow mode: report the verdict, drop nothing
floor_percentile: 95.0
weak_margin: 1.15
recalibrate_coverage_delta: 0.25
Verdicts are grounded, weak, ungrounded, and uncalibrated — the last
kept deliberately distinct, because "we have no yardstick" is a different fact
from "we measured and found nothing."
Shadow mode is the default on purpose. Enforcing turns a visible,
self-correcting problem (irrelevant results in context) into a silent one (an
agent proceeding without knowledge that was actually there). Run it in shadow
first, see what it would have dropped, then set enforce: true.
Multi-Hop Reach
Graph expansion honours --hops, with per-hop score decay and a mandatory
beam. The beam's ordering is total and stable, so traversal is reproducible:
adding an edge elsewhere in a hub's neighbourhood cannot silently change what a
query returns.
ranking:
hop_decay: 0.5 # a 2-hop neighbour cannot outrank a 1-hop one
graph_beam: 200 # required — real graphs have 800+ fan-out hubs
Extraction Engines
Extraction is an input, never an authority. Engine output lands in the
capture_candidates quarantine and never writes nodes or edges directly.
# Which engines are available here
kin extract engines
# Score them against your own corpus
kin extract eval --engines keyword,llm --limit 200
The gate is two-part: grounding precision is a floor (don't invent), title recall is the discriminator (actually find what a curator would record). Either alone is gameable — an engine that only copies verbatim scores perfect grounding while finding nothing.
An optional LLM-free deterministic engine is available behind an extra:
pip install 'kindex[talon]' # ~2.5 GB — never a core dependency
It is excluded from kindex[all] by design, and degrades to keyword extraction
with a warning when absent. Measure it with kin extract eval before enabling
it; an engine that cannot beat regexes on your corpus has not earned the
install size.
Editing & Superseding
Knowledge changes. Kindex edits are policy-aware: each node type has a mutability class that says how its content may change, so facts stay correctable while history-bearing records stay append-only.
| Class | Node types | What's allowed |
|---|---|---|
editable | concept, document, artifact, skill, person, project, question | Full in-place edit: title, content, append, tags, intent, expires |
additive | decision, constraint, directive, checkpoint, watch | History matters — append and expires only; use supersede to replace |
managed | task, session, coordination | Refused — use the dedicated task/tag/coord commands |
# In-place edit (editable types) — accepts node id or exact title
kin edit oauth-flow --title "OAuth2 + OIDC flow" --add-tags auth,oidc
# Additive types only grow: append a dated addendum
kin edit deploy-constraint --append "Clarified: applies to staging too"
# Give any node an expiry — expired nodes stop surfacing and get archived
kin edit conference-notes --expires 2026-09-01
# Replace with history: new node + supersedes edge, old node marked superseded
kin supersede old-decision "We now use OIDC trusted publishing" --reason "tokens deprecated"
Every edit logs per-field value diffs to the activity log, and kin changelog renders them:
## Edited (1 nodes)
2026-06-11 [concept] OAuth2 + OIDC flow
title: OAuth2 flow -> OAuth2 + OIDC flow
Edits re-embed the node for vector search, protect reserved operational state (locks, claims, coordination messages), and refuse to modify a node another agent has locked unless you pass --force. The per-type class can be overridden in config with edit_policy: {document: additive} if your team wants stricter history.
Profiles
One machine, multiple sequestered graphs. Profiles map names to separate data directories so work and personal knowledge never mix — different DBs, different embeddings, different everything.
# ~/.config/kindex/kin.yaml
profiles:
work:
data_dir: ~/.kindex-work
roots: [~/Work]
personal:
data_dir: ~/.kindex
roots: [~/src, ~/notes]
default_profile: personal
Resolution order (first match wins):
--profile <name>flagKIN_PROFILEenvironment variableprofile:key from the project's.kin/configchain- Longest-prefix match of the current directory against profile
roots default_profile- Legacy single graph — no profiles configured means nothing changes
Documentation truncated — see the full README on GitHub.
Reviews
No reviews yet
Be the first to review this server!
More Developer Tools MCP Servers
Rea
Freeby Morluto · Developer Tools
Reverse engineer anything from your terminal or agent with one CLI and MCP server.
Paperclip
Freeby Paperclipai · Developer Tools
Trending hip-hop artist momentum scores across four cultural dimensions.
Fetch
Freeby Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
Git
Freeby Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
Toleno
Freeby Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
MCP Marketplace
Freeby mcp-marketplace · Developer Tools
Search and install MCP servers from inside your AI client.
