MCP Server

Read from the package source without running it. The installed server may list more.

• auto_learn_session

  Auto-learn from a list of session observations WITHOUT explicit learn_from_attempts calls. Pass what happened (commands run, errors seen, solutions found) and the brain classifies and stores lessons automatically. Use at session_end to capture everything you did, even if you forgot to call learn_from_attempts. Returns a summary of what was auto-stored.

• autopilot

  Generate a CLAUDE.md / copilot-instructions.md that makes any AI self-managing forever. Writes a configuration file to disk \u2014 will overwrite an existing file at the target path. No auth required beyond a valid instance_id. The generated file instructs Claude, Cursor, Copilot, Windsurf, or Gemini to automatically call session_start at window open, learn_from_attempts after every fix, and sessi

• brain_briefing

  Push-based Brain warning: instead of waiting for you to ask, the Brain proactively checks whether the file you just opened, the PR you are about to raise, or the deploy you are about to run matches any known failure pattern \u2014 and surfaces warnings BEFORE something breaks. Call this on file_open (with the file path as context), pr_open (with the PR title/body), or deploy (with a short descript

• brain_changelog

  Generate a human-readable Markdown changelog of lessons learned in the last N days. Groups lessons by topic category, annotates with author, recall count and confidence. Ideal for weekly standups, sprint retros, or async team updates \u2014 share the output directly in Slack or a doc. Example: brain_changelog(instance_id="...", days=7) \u2192 grouped Markdown changelog of the week's learning.

• brain_collab_pairs

  Show the Person\u2194Person Collaboration Graph for your team (W5). Lists every pair of contributors who have worked together \u2014 either by touching the same files in learn_from_attempts or by recalling each other's lessons via smart_recall(requester=...). Each pair includes a "Frag @X und @Y" routing suggestion \u2014 ideal for onboarding and bus-factor analysis. Also flags solo contributors w

• brain_confirm_ci

  Close the CI feedback loop: tell the Brain whether a CI job passed or failed and which topics it covered. The Brain adjusts lesson confidence automatically \u2014 confirmed failures get +15%, false positives (brain predicted failure but CI passed) get \u221210%. Called automatically by cachly-action at the end of every pipeline. Also use manually after a deploy to confirm or refute the brain's las

• brain_conflicts

  READ-ONLY \u2014 list every unresolved belief_conflict (a previously confirmed fix now contradicted by a failure) plus the agents currently writing to this Brain (last 1h). This is the arbitration inbox for multi-agent teams: when several AI sessions share one Brain, contradictory writes surface here instead of silently overwriting each other. Resolve any listed conflict with brain_resolve_conflic

• brain_contribute_signal

  Contribute a privacy-safe signal to the global Brain commons. Only the topic category, outcome, and confidence bucket (high/medium/low) are shared \u2014 no lesson text, no org identity. When \u2265 k independent orgs contribute the same pattern, a meta-lesson is derived in the commons. Use this instead of fedbrain_contribute when privacy is required (enterprise, GDPR).

• brain_coverage

  Knowledge-coverage health score for your codebase \u2014 scored 0-100. Reports: total lessons, success ratio, attribution completeness, team engagement, and file coverage vs git ls-files. Run after brain_from_git or periodically to track knowledge-capture progress. Use skill_gaps to find what to fix. Example: brain_coverage() \u2192 "\u{1F7E2} Overall score: 78/100 \xB7 42 lessons \xB7 6 contribut

• brain_diff

  git log for your AI Brain \u2014 see exactly what changed since a point in time. Returns a structured changelog: new lessons added, lessons updated (outcome changed), lessons recalled (hit count increased), and lessons that decayed. Perfect for weekly reviews: "What did my AI learn this week?" Example: brain_diff(instance_id="...", since="7d") \u2192 "12 new \xB7 4 updated \xB7 2 stale"

• brain_doctor

  Check the health of your AI Brain and get actionable recommendations. Reports: lesson count, context entries, last session age, open failures, quality score, effective IQ boost, stale index. Returns a prioritized list of issues with fix instructions.

• brain_file_map

  Show what cachly knows about a list of files \u2014 experts + related lessons per file. Call this before starting work on unfamiliar files, or in sync_file_changes to see what knowledge exists. For each file path: shows who has previously touched it (from learn_from_attempts author+file_paths) and which lessons reference it. Example: brain_file_map(file_paths=["src/auth/jwt.ts"]) \u2192 "\u{1F947}

• brain_hygiene

  Autonomously sweep and maintain your Brain \u2014 flags stale lessons as provisional, archives long-dormant ones, and resolves contradictions where success clearly dominates failure. Safe to run on a schedule (weekly CI job) or on-demand before a big release. Lesson state lifecycle: active \u2192 provisional (confidence < threshold) \u2192 archived (stale + low-recall + old). Archived lessons are

• brain_install

  Install a Domain Brain into your local Brain \u2014 pulls its curated, high-trust lessons so they surface in smart_recall immediately, even offline. Idempotent and non-destructive: it NEVER overrides your own lessons (only prior installs of the same brain). Re-run anytime to pull updates. Browse available brains first with brain_marketplace(). Example: brain_install(slug="k8s") \u2192 "\u{1F4E6} I

• brain_marketplace

  Browse the Domain Brain marketplace \u2014 curated, installable packs of high-trust community lessons, grouped by domain (Kubernetes, Auth, Database, React, Payments, \u2026). Each brain is built from verified, community-confirmed lessons in the global Knowledge Commons. Use at onboarding or when starting work in an unfamiliar domain to bootstrap your Brain instantly. Install one with brain_instal

• brain_metrics

  Report the three decisive Brain metrics: (1) time-to-first-recall (onboarding friction), (2) recall-lift vs. raw BM25 (the moat proof, from Cachly-Bench), and (3) team-knowledge-reuse \u2014 what % of proven recalls used a teammate's lesson. Use to track whether the Brain is delivering its core value. Pass author="handle" to smart_recall so cross-author reuse can be measured.

• brain_plan

  READ-ONLY \u2014 no side effects, no writes, no external network calls. Generative planning layer on top of the CKG: given a task you are ABOUT to do (e.g. "upgrade Postgres 14\u219216", "add Stripe webhooks"), returns an ordered action plan grounded in your own proven lessons \u2014 the failure modes most likely to bite (ranked by confidence), the concrete steps that fixed them before (with comma

• brain_portability

  Bring your own model, keep your brain: the same memory in every AI editor. Returns your Brain ID plus ready-to-paste MCP config snippets for every compatible AI client: Claude Code, Cursor, Windsurf, GitHub Copilot (VS Code), Cline, Zed, Continue. All 7 clients connect to the same Brain \u2014 same lessons, crystals, predictions, and team data. Use autopilot to configure all detected editors in on

• brain_predict

  READ-ONLY \u2014 no side effects, no writes, no external network calls. Predictive Pre-fetch Engine (PPE): given your current context, reads the CKG in your Redis instance to predict likely failures and return the highest-confidence fixes. "Pre-load" means results are returned inline \u2014 nothing is cached or persisted. Requires a valid instance_id (your Redis brain). No rate limits. Call at ses

• brain_resolve_conflict

  Arbitrate a contested topic by picking the winning side. winner="success" reaffirms the fix (the contradicting failure stops blocking recall); winner="failure" retires the fix (its CKG fixes-edges decay to ~0 and the losing lesson is archived). Human-in-the-loop resolution is the strongest possible confidence signal. List open conflicts first with brain_conflicts.

• brain_search

  BM25+ full-text search over ALL brain data: lessons, context entries, session history, CKG nodes, roadmap items. Unlike smart_recall (which focuses on lessons + context), brain_search casts a wider net. Use when smart_recall returns nothing or when you want to find anything the brain knows about a topic.

• brain_service_map

  Map everything the Brain knows about a running service or system: who operates it, which files run in it, every known failure, and every proven fix. Built from lessons tagged with `service="..."` in learn_from_attempts. Ideal for incident triage \u2014 when a service is misbehaving (e.g. a restarting pod), instantly surface who knows it and what has gone wrong with it before. Example: brain_servic

• brain_who_knows

  Find who in your team has the most expertise on a given topic. Queries the org-wide knowledge graph (built automatically from learn_from_attempts author fields) and returns a ranked list of contributors whose lessons match the query, ordered by lesson count and confidence. Use to find the right person to ask before starting a task, or to understand knowledge distribution. Example: brain_who_knows(

• cache_deletewrite action

  Permanently delete one or more keys from a running cache instance (uses Redis DEL). This operation is destructive and irreversible \u2014 deleted keys cannot be recovered. Deleting a non-existent key is safe and returns 0 for that key (no error). Returns the count of keys that were actually deleted (existing keys only). Use this to explicitly remove stale entries; prefer cache_set with a short TTL

• cache_exists

  Check whether one or more keys exist in a running cache instance (uses Redis EXISTS). Read-only \u2014 no side effects. Returns the count of keys that currently exist (integer 0 to N). If none of the keys exist, returns 0. If all exist, returns the total key count passed in. Duplicate keys in the input array are each counted separately (Redis behavior). Use this to check presence before a cache_ge

• cache_get

  Get a value from a running cache instance by key. Returns the stored value (string or deserialized JSON object) or null if the key does not exist or has expired. Read-only \u2014 no side effects. Use cache_mget when you need multiple keys in one round-trip. Use cache_exists to check existence without retrieving the value. Use semantic_search when you need fuzzy/vector search across stored values.

• cache_keys

  List keys in a cache instance matching an optional glob pattern (e.g. "user:*", "session:*"). Uses SCAN to avoid blocking the server. Returns at most `count` keys.

• cache_lock_acquire

  Acquire a distributed lock using Redis SET NX PX (Redlock-lite). Returns a fencing token on success. The lock auto-expires after ttl_ms to prevent deadlocks. Use cache_lock_release to free the lock early.

• cache_lock_release

  Release a previously acquired distributed lock. Uses a Lua script for atomic release \u2013 only deletes the key if the fencing token matches.

• cache_mget

  Retrieve multiple keys in one round-trip using native Redis MGET. Returns values in the same order as the keys array; missing keys are null.

• cache_mset

  Set multiple key-value pairs in a single pipeline round-trip. Supports per-key TTL \u2013 unlike native MSET. Uses one TCP round-trip for N keys via Redis pipeline. Each item overwrites any existing value for that key. On partial failure the successfully pipelined keys are committed; a per-key error list is returned for any that failed. Returns a summary: { set: N, errors: [...] }. Use cache_set f

• cache_org_stats

  Show shared cache statistics for an org namespace. Scans all keys under org:{org_id}:sem:* and reports how many entries are shared. Use this to verify org-sharing is working and to monitor cross-instance cache utilization. Also aggregates org-wide ROI via the Cachly API: total cache hits, hits in the last 24h, estimated total and projected monthly USD savings across all org instances, plus a per-i

• cache_set

  Set a key-value pair in a running cache instance. Overwrites any existing value at the key \u2014 not idempotent for new data. Returns "OK" on success; returns an error if the instance_id is invalid or the instance is paused. Value can be a string or a JSON-serialized object. Optionally set a TTL in seconds (omit for no expiry). Use cache_mset instead for setting multiple keys in a single pipeline

• cache_stats

  Get real-time stats for a cache instance: memory usage, hit/miss rate, commands/sec, connected clients, keyspace info, and uptime. Read-only \u2014 no side effects. The instance_id identifies the target instance (obtain from list_instances). Use this for monitoring, capacity planning, or debugging performance issues \u2014 not for reading cached values (use cache_get for that). Use cache_exists or

• cache_stream_get

  Retrieve a previously cached stream as an ordered list of string chunks. Returns null on cache miss (key absent or empty list). Stored under cachly:stream:{key}.

• cache_stream_set

  Cache a list of string chunks (e.g. LLM token stream) via Redis RPUSH. Each chunk is stored as a separate list element under cachly:stream:{key}. Replay with cache_stream_get.

• cache_ttl

  Get the remaining time-to-live (TTL) of a key in seconds. Returns -1 if the key exists but has no expiry, -2 if the key does not exist. Read-only \u2014 no side effects. Use cache_set with a ttl parameter to set or update the expiry.

• cache_warmup

  Pre-warm the semantic cache with a list of prompt/value pairs. For each entry: computes an embedding, checks if a similar entry already exists (similarity \u2265 0.98), and writes new entries to Valkey + pgvector index. Use this to seed FAQ responses, product descriptions, or known-good LLM answers before the first real user traffic. Requires OPENAI_API_KEY.

• causal_trace

  Root Cause Analysis through memory: given a problem description, traces the causal chain from root cause through intermediate failures to the current symptom, then surfaces the exact solution that worked before. Read-only \u2014 does not modify any stored data. Requires prior learning: brain must have lessons stored via learn_from_attempts or brain_from_git. Returns an ordered chain of concepts wi

• ckg_inspect

  Inspect the Causal Knowledge Graph (CKG) for a concept. Shows all typed edges (fixes, requires, co-occurs, causes) with Bayesian confidence scores. Use to understand what the brain knows about a topic and which fixes have the highest confidence. Also shows related concepts via graph traversal.

• create_instancewrite action

  Create a new managed Valkey/Redis cache instance on cachly.dev. Free tier provisions in ~30 seconds. Paid tiers return a Stripe checkout URL. Available tiers: free (25 MB), dev (200 MB, \u20AC19/mo), pro (900 MB, \u20AC49/mo), speed (900 MB Dragonfly + Semantic Cache, \u20AC79/mo), business (7 GB, \u20AC199/mo).

• create_orgwrite action

  Create a new Cachly organization for team collaboration. After creation, invite team members with invite_member and upgrade the plan via the billing portal. Org plans: Team (\u20AC99/mo, 10 seats), Business (\u20AC299/mo, 50 seats), Enterprise (custom).

• delete_instancewrite action

  Permanently delete a cache instance. Deprovisions the Kubernetes workload and removes all data. This action is irreversible.

• detect_namespace

  Classify a prompt into one of 5 semantic namespaces using text heuristics. Overhead: <0.1 ms, no embedding required. Useful to understand which namespace cachly will use for a given prompt. Returns one of: cachly:sem:code, cachly:sem:translation, cachly:sem:summary, cachly:sem:qa, cachly:sem:creative.

• forget_contextwrite action

  Delete one or more cached context entries. Use when context is stale or you want to force a fresh analysis. Supports glob patterns: "file:*" deletes all file summaries.

• get_api_status

  Full diagnostic for your cachly Brain \u2014 call this FIRST whenever anything is not working. Returns: API reachability, JWT validity + expiry, your user ID, all Brain instances with live status (\u{1F7E2} running / \u{1F7E1} provisioning / \u{1F534} stopped), Redis ping on the active connection, and actionable fix steps for every issue found. Workflow: run get_api_status \u2192 read the issue it

• get_connection_string

  Get the Redis/Valkey connection string (redis:// URL) for a running instance. Use this to configure your application or set environment variables.

• get_instance

  Get full metadata for a specific cache instance: name, tier, status (provisioning / running / paused), region, RAM limit, Redis connection string, created_at, and expiry. Read-only. Returns an error if the instance_id is not found or belongs to another account. Call list_instances first to discover valid UUIDs. Use get_connection_string instead if you only need the redis:// URL for your app config

• get_org_plan

  Get the current org plan, seat usage, and billing info for an organization. Shows: plan name, price, seats used/max, next billing date. To upgrade: use the billing portal URL returned by this tool.

• global_learn

  Store a lesson that applies across ALL your projects (cross-project knowledge). Idempotent: if a lesson with the same topic already exists, it is updated in place \u2014 no duplicates are created. Returns a confirmation with the stored lesson key. No rate limits. Global lessons are stored with the prefix cachly:global:lesson: and recalled from any instance via global_recall. Use for tool preferenc

• global_recall

  Read-only retrieval of cross-project lessons stored via global_learn. No side effects. Returns a list of matching global lesson objects, each with topic, lesson text, severity, and tags. If no topic is provided, returns all global lessons (up to 50). If topic is provided, returns all lessons whose topic key contains that string (partial match). Use this for lessons that apply universally across al

• import_public_brain

  Import community lessons from the Cachly Public Brain for a framework. Non-destructive: existing lessons with the same topic key are not overwritten. Returns the count of lessons imported and their topic slugs. Available frameworks: nextjs, fastapi, go, docker, kubernetes, react, typescript, python, rust, laravel, rails, spring. Use this to bootstrap a new brain with battle-tested community knowle

• index_project

  Index local source files into the cachly semantic cache so AI assistants can use semantic_search to find relevant files instead of re-reading the whole codebase every time. Walks a directory recursively, reads each matching file, and stores a summary + path as a semantic cache entry (prompt = file path + content excerpt, value = relative path). Requires an embedding provider (OPENAI_API_KEY or CAC

• invite_member

  MUTATION \u2014 sends an invite email immediately and cannot be undone via MCP. Invite a team member to a Cachly organization by email. Requires the caller to be an admin or owner of the organization. Valid roles: admin (manage members + instances), member (read + cache ops). Default role: member. Returns an error if the email is already a member or has a pending invite.

• knowledge_decay

  Confidence scoring for every lesson in your Brain \u2014 because old knowledge rots. Computes a decay score (0\u2013100%) per lesson based on age, recall frequency, and outcome. Lessons recalled recently score high. Lessons from 90 days ago never recalled score low. Returns a ranked list with visual confidence bars: "\u2588\u2588\u2588\u2588\u2591\u2591\u2591\u2591 40%". Use this before a big refa

• learn_from_attempts

  Store a lesson AFTER any non-trivial task (deploy, debug, fix, decision); future sessions recall it. instance_id may be omitted; the configured instance is used \u2014 never guess one. If the topic already exists, the write is an UPDATE and REQUIRES `grund` (one line: WHY the previous version was wrong) \u2014 without it the update is rejected. A conflicting outcome triggers a contradiction warnin

• lesson_verified

  Report that you RAN the check for a lesson and what came back. This is the only way a lesson gets fresh again \u2014 reading one does not verify it, and since 0.10.165 recall no longer pretends otherwise. The server never runs the command itself: you run it, you report the result. holds=true refreshes verified_at and clears any earlier failed check. holds=false marks the lesson as questionable and

• list_instances

  List all your cachly cache instances with their status and connection details. Read-only. Returns an array of instance objects \u2014 each with id, name, tier, status, region, RAM, and redis:// connection string. Returns an empty array if no instances exist. No pagination: all instances are returned in one call (typical accounts have < 20). Use this first to discover instance UUIDs required by get

• list_orgs

  List your Cachly organizations (team/org plans). Returns each org with plan, seat count, and member info. Org plans (Team \u20AC99, Business \u20AC299, Enterprise custom) are billed separately from cache tiers.

• list_remembered

  List all cached context entries for this project. Shows what knowledge the AI assistant has already cached, so you can decide whether to recall existing context or refresh it. Returns: key, category, size, TTL remaining, and a content preview.

• memory_consolidate

  Cognitive memory consolidation \u2014 the weekly garbage collector for your AI Brain. Scans all lessons, detects contradictions (same topic with conflicting outcomes), merges duplicates, flags stale entries (not recalled in 90+ days), and computes a health score. Returns a full consolidation report with conflicts resolved, duplicates merged, and a before/after count. Run weekly or when brain_docto

• memory_crystalize

  Compress the last 30-50 sessions and auto-learned lessons into a dense Memory Crystal. A crystal is a compact, structured summary of everything the brain learned \u2014 grouped by category (deploy, fix, debug, \u2026). Crystals survive session cleanup and appear in session_start once enough sessions have accumulated. Run this monthly or after a big milestone to preserve institutional knowledge. Re

• publish_lessonwrite action

  Publish a lesson to the Cachly Public Brain (anonymized community knowledge base). Published lessons can be imported by other developers via import_public_brain. PII is stripped automatically. Visible under the framework/category tag. Returns { lesson_id, topic, framework, published_at } confirming the publish. Irreversible \u2014 once published to the public brain, lessons cannot be deleted via t

• recall_at

  Brain Archaeology \u2014 see what a lesson looked like at a specific point in time. "What did we know about deployments 3 months ago?" Returns the history of a topic filtered to entries before the given date. Shows how the lesson evolved: failure \u2192 partial \u2192 success. Also useful to understand WHY old code decisions were made.

• recall_best_solution

  Recall the best known solution for a topic from past lessons. Call this BEFORE attempting any task that might have been done before. Returns the most recent successful lesson for the topic, with confidence indicator. \u26A0\uFE0F badge = lesson is >5d old (verify before applying). \u{1F534} = >10d old (likely stale!). Recalling a lesson resets its confidence clock to 1.0 (marks as recently verifie

• recall_context

  Retrieve previously saved context from the cache. Returns the saved content or null if not found. Use this at the START of any task to check if you already have relevant context cached, before doing expensive operations like reading many files. Supports glob patterns: "file:*" matches all file summaries, "arch*" matches architecture-related keys.

• recall_feedback

  Tell the Brain whether a recalled lesson ACTUALLY SOLVED your problem. This is the one signal the Brain cannot infer: recall_count only means "it was shown". Call it right after a lesson helped you \u2014 or after you solved something the Brain should have found. IMPORTANT: rank=0 means the lesson was NOT in the answer at all. That is the most valuable feedback there is, because it says the rankin

• remember_context

  Save context information to the cache so you can recall it later without re-computing. Perfect for caching: codebase overviews, file summaries, project structure, frequently-accessed data, or "thinking" results like dependency analysis. The AI assistant can use this to avoid re-reading the entire codebase every time. Overwrites any existing value stored under the same key. Returns { key, stored_at

• roadmap_add

  Add a new item to the persistent project roadmap stored in the Brain. Items survive across sessions and editors \u2014 the roadmap is always up to date. Use for features, bugs, refactors, or any planned work. Call roadmap_list to see all open items, roadmap_next to get the next actionable item.

• roadmap_list

  List all roadmap items, optionally filtered by status, priority, tag, or milestone. Returns items sorted by priority then creation date. Called automatically by session_start to show open work.

• roadmap_next

  Get the single most important next actionable roadmap item. Returns the highest-priority in-progress item first, then planned items, sorted by priority. Call at session start to immediately know what to work on next.

• roadmap_updatewrite action

  Update the status, priority, or details of a roadmap item. Use to move items through the lifecycle: planned \u2192 in-progress \u2192 done (or blocked/cancelled). Also use to add notes/findings while working on an item.

• semantic_search

  Find cached entries that are semantically similar to a natural-language query. Read-only \u2014 no side effects. Returns an array of objects, each with: key, value, similarity_score (0\u20131), and namespace. Returns an empty array if no entries meet the similarity threshold. Requires OPENAI_API_KEY (or compatible provider) and the Speed/Business tier with CACHLY_VECTOR_URL. Embeddings are compute

• session_end

  Save a session summary when you finish working. Records what was accomplished, files changed, and lesson count. The next session_start will show this summary as "Last session". Call this when ending a work session, before going idle, or before summarizing. Ambient Learning: if workspace_path is provided, reads git log since session start and auto-learns from commits.

• session_handoff

  Save a detailed handoff for the NEXT chat window / session. Stores: current progress, TODO list (done + remaining), changed files with descriptions, instructions for the next assistant, and any incomplete work. The next session_start automatically includes this handoff so the new window knows EXACTLY what happened and what remains. Call this BEFORE closing a chat window, especially if work is inco

• session_ping

  Lightweight checkpoint \u2014 call this every ~5 tool calls or whenever you complete a significant step. Stores the current task + files touched so session_start on the NEXT provider can reconstruct what happened even if session_end was never called (e.g. Claude context limit hit, window crashed). This solves the provider-switching problem: Claude \u2192 Copilot \u2192 Cursor all see the same last

• session_start

  Single-call session briefing. Call this at the START of every session INSTEAD of multiple separate smart_recall/recall_best_solution calls. Returns: last session summary, recent lessons sorted by recency, relevant lessons for your focus area, open failures (topics with only failure outcomes), brain health stats, team telepathy (what teammates learned this week), predictive pre-warnings (if your fo

• session_start_summary

  Focused session briefing for large brains. Returns only the top-N most relevant lessons for the given focus topic, scored by relevance, recall count, severity, recency, and outcome. Ideal when session_start returns too many lessons to fit in context (1000+ lesson brains). Use session_start for the full briefing including handoffs, streak, roadmap, and team telepathy.

• set_cost_per_call

  Set the assumed cost per avoided LLM API call (USD) for this instance. This is used to compute accurate ROI savings estimates in cache_stats. The default ($0.002) is calibrated for a small model (gpt-5.5-mini class). Set your actual model cost for accurate numbers: claude-opus-4.8 \u2192 $0.02, gpt-5.5 \u2192 $0.015, claude-sonnet-4.6 \u2192 $0.009, claude-haiku-4.5 \u2192 $0.001. After updating,

• setup_ai_memory

  One-shot setup of the cachly 3-layer AI Memory system for a project. Layer 1 \u2014 Storage: your cachly instance (Valkey, persistent across sessions) Layer 2 \u2014 Tools: learn_from_attempts + recall_best_solution + smart_recall (the memory API) Layer 3 \u2014 Autopilot: generates a copilot-instructions.md / .github/copilot-instructions.md that instructs any MCP-compatible AI to recall known sol

• skill_gaps

  Show knowledge blind spots in your Brain \u2014 domains with unresolved failures, lessons with missing attribution, and areas where brain_who_knows cannot help. Run periodically to find where to focus knowledge capture effort. Returns a prioritized list: \u{1F534} critical (failures with no solutions) \u2192 \u{1F7E1} warn \u2192 \u{1F535} info. Pairs with brain_coverage for a full knowledge-healt

• smart_recall

  Semantically search cached context using natural language. instance_id may be omitted; the configured instance is used \u2014 never guess one.Instead of exact key matching, finds context by meaning. Example: smart_recall("how does authentication work") \u2192 returns cached auth architecture summary. Falls back to remember_context keys if no semantic match is found.

• sync_file_changes

  Associate recent file changes with brain knowledge. Pass a list of changed file paths (from `git diff --stat`). Returns lessons relevant to those files, and records the file changes in session history. Call this after commits so the brain tracks what changed and why.

• syndicate

  Contribute a verified lesson to the GLOBAL Cachly Knowledge Commons \u2014 a privacy-preserving shared brain where every AI instance can learn from the discoveries of every other. Your contributor identity is a one-way HMAC hash: completely anonymous. The lesson is immediately searchable by any other AI using syndicate_search. This is how individual knowledge becomes collective intelligence. Call

• syndicate_search

  Search the GLOBAL Cachly Knowledge Commons for solutions contributed by the entire community. Returns lessons ranked by confirm_count (trust score) then recency. Use this BEFORE debugging any unknown issue \u2014 someone in the global brain likely solved it already. Example: syndicate_search(q="clickhouse localhost connection refused") \u2192 "fix: use 127.0.0.1 not localhost when IPv6 is disabled

• syndicate_stats

  Show the health of the global Knowledge Commons: total lessons, total confirms, top categories, most-trusted lessons, growth in the last 7 days, and top contributors (anonymous scores). Use for weekly reviews or to explore what the community knows.

• syndicate_trending

  Show the TRENDING lessons in the global Knowledge Commons \u2014 those with the fastest confirmation velocity in the last 7 days (confirm_count / age_in_days). Use this at the start of a session or weekly review to see what the community is actively validating. Lessons need at least 2 independent confirms to appear here.

• team_assign_role

  Assign a role (admin | reviewer | contributor | viewer) to a team member on a shared brain instance. Roles control what each person can do: admin can manage roles and delete lessons; reviewer can senior-review (\u{1F6E1}\uFE0F badge, stronger recall boost); contributor can store lessons and peer-review (\u2714\uFE0F badge); viewer is read-only. First call bootstraps governance (no auth required wh

• team_audit

  View the governance audit log for a shared brain \u2014 an immutable trail of who changed roles and who confirmed which lessons, with timestamps. Essential for enterprise compliance and security reviews. Admin-only once governance is active (an admin has been assigned). Events are recorded automatically on team_assign_role and team_confirm \u2014 no setup. Example: team_audit(requester="alice") \u

• team_confirm

  Endorse (review-confirm) a team lesson so trusted, human-reviewed knowledge ranks above unreviewed auto-learned entries. A senior review weighs more than a peer review; distinct endorsements add a small boost. Confirmed lessons surface higher in smart_recall and team_recall and carry a \u{1F6E1}\uFE0F/\u2714\uFE0F badge. Use this in code review or knowledge reviews to bless the canonical solution

• team_crystallizewrite action

  Create a Team Crystal \u2014 the team-wide, causal counterpart to memory_crystalize. Where memory_crystalize compresses ONE brain by category, team_crystallize surfaces what a per-user memory structurally cannot: which fixes solved structurally SIMILAR problems across MULTIPLE people. A pattern only crystallizes when 2+ distinct authors independently converged on it \u2014 that cross-person signal

• team_expertise_map

  Full team expertise overview \u2014 who knows what, at a glance. Returns a ranked table of all contributors with their lesson count, top domains, and last-active date. Use for onboarding (who to ask about X?), retrospectives, or to find knowledge gaps. Built automatically from learn_from_attempts(author=...) calls \u2014 no setup needed.

• team_grant_scope

  Add or remove a team member to/from a named group (sub-team) on a shared brain. Group-scoped lessons (stored with group="...") only surface in smart_recall for members of that group (and admins). This is team-level visibility, orthogonal to lesson-level private. Admin-gated after the role model is bootstrapped. Example: team_grant_scope(handle="alice", group="security", assigned_by="bob") \u2014 b

• team_learn

  Store a lesson in a shared team brain so all team members benefit. Like learn_from_attempts, but REQUIRES an author name for attribution. Shows up in team_recall with "by <author>" so the team knows who learned it.

• team_recall

  Recall lessons from a shared team brain, showing who learned what. Works on any shared instance (all team members using the same instance_id). Shows author, recency, and severity for each lesson. Use this to onboard new team members or find who knows about a topic.

• team_roster

  Show all team members and their assigned roles on a shared brain instance. Returns a table of handles, roles (\u{1F451} admin \xB7 \u{1F6E1}\uFE0F reviewer \xB7 \u270F\uFE0F contributor \xB7 \u{1F441}\uFE0F viewer), and capabilities. Use during onboarding to see who can do what, or to verify role assignments.

• team_scopes

  List team groups and their members, or the groups a specific person belongs to. Pass handle to see one person's scopes; omit it to see all groups on the instance. Use to audit who can see group-scoped lessons.

• team_synthesize

  Team Brain Synthesis \u2014 merge multiple contributors' lessons on the same topic into one canonical version. When 2+ developers store lessons for the same topic with different details, this proposes the best merged version. Shows: all contributions by author, what worked (consensus), what failed (union), canonical lesson to store. Use this when onboarding new team members or before documenting a

• team_whoami

  Show your own role and capabilities on a shared brain instance. Tells you what you can do (store, review, manage roles) and who to contact if you need a higher role. Run this after onboarding to confirm your role was set correctly.

• trace_dependency

  Causal Chain \u2014 find all lessons that depend on a given prerequisite. "What lessons are affected if node version changes?" When a dependency changes (new version, different provider, new OS), call this to see which lessons need review. Lessons store dependencies via the depends_on field in learn_from_attempts.

• Code scan92 source files scanned10/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 15 days ago15/15
• Maintainer identityregistry namespace matches repository owner7/10

MCP Server: common questions

Is MCP Server safe?

With care: it is graded C, so read the findings first (68/100). Read the MCP Server safety report

How do I install MCP Server?

It runs on your machine. Copy the Claude Code, Claude Desktop or Cursor config from the install section.

Does MCP Server need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is MCP Server maintained?

The last commit was 15 days ago (2026-09-05). The latest release is v0.10.169.

What can I use instead of MCP Server?

Servers from other publishers that do the same job: Vestige MCP server, Deja Vu MCP server and State Memory MCP server. Compare all MCP Server alternatives.