Skip to main content
Glama
Cachly — AI Cognitive Brain

Cachly — AI Cognitive Brain

cachly — memory for coding agents (MCP server)

Solve it once. From then on, your AI knows.

Every fix, decision and dead end becomes a lesson. Your AI finds it again when the same problem comes back, in the next session, in another editor, or on a teammate's machine.

npm version License: Apache-2.0 MCP Registry Hosted in the EU

Works with Claude Code · Cursor · GitHub Copilot · Windsurf · Cline · Continue.dev · Zed · Codex CLI · Gemini CLI · JetBrains IDEs

Quick start · What it looks like · Pricing · FAQ · Reference · cachly.dev

Quick start

Claude Code — two lines, and the next session has a Brain (the store of your lessons):

/plugin marketplace add cachly-dev/cachly-mcp
/plugin install cachly-brain@cachly

cachly creates a test Brain on EU servers when the session starts. It comes with 14 days of the Solo plan and then continues on Free with the same key. Check it with claude mcp list: you should see plugin:cachly-brain:cachly … ✔ Connected.

Cursor, Windsurf, VS Code, Cline, Continue.dev, Zed, Codex CLI, Gemini CLI — one command:

npx @cachly-dev/mcp-server@latest autopilot

autopilot finds your editors, writes the MCP config and the rule file for each, adds a git hook that learns from your commits, and fills your Brain from your git history. You sign in once in the browser with a device code. Restart your editor afterwards.

Already inside Claude, Cursor or Copilot? Paste this to your AI:

Set up cachly for this project. Run: npx @cachly-dev/mcp-server@latest autopilot
Follow the browser sign-in, then restart the editor.

In the IDE: the VS Code extension creates your Brain on first start. The JetBrains plugin brings it to IntelliJ IDEA, PyCharm, GoLand, WebStorm and Rider (guide).

Keep your test Brain with npx @cachly-dev/mcp-server@latest claim. You sign in once, and the Brain moves into your account with all its lessons.

The plugin adds three Claude Code hooks:

Hook

What it does

SessionStart

Gives your AI a short briefing: the 5 most-reused lessons (on a new Brain: starter tips)

UserPromptSubmit

Puts the lessons that match your prompt next to it

Stop

Saves a lesson when the AI's last message clearly reports a fix. It skips messages that say something failed or is unclear. It saves quietly.

Turn on auto-update once: /plugin → Marketplaces → cachly → Enable auto-update. Claude Code leaves it off for marketplaces outside Anthropic's own. The MCP server updates itself on every start; the hooks come with the plugin and update with it. If an update is waiting, the first session_start of a session says so in one line.

The test Brain is created by the plugin hook at session start, or by the first tool call if the hook did not run. claude mcp list is the reliable check: claude plugin details shows MCP servers (0) even while the server runs.

claim revokes every test key and stores a new key where your editor and hooks look for it. The Brain restarts once, which takes about 20 seconds. The Free plan holds one Brain: if you already have one, claim stops with a message and leaves both Brains as they are.

autopilot writes these rule files, so each editor's AI checks its memory before a task: CLAUDE.md, AGENTS.md, .cursor/rules/cachly.mdc, .github/copilot-instructions.md, .windsurfrules, .clinerules, and GEMINI.md, .junie/guidelines.md and .continue/rules/cachly.md where you use Gemini CLI, Junie or Continue. Claude Code and Gemini CLI also follow the server's own instructions; Cline, Continue and Zed rely on the rule file. You can also add the server by hand (see Manual Setup).

Related MCP server: Astria-Index

What it looks like

Monday, your AI fixes a bug and keeps what worked (output shortened):

learn_from_attempts(topic="billing:invoice-rounding", outcome="success",
  what_worked="ROUND HALF-EVEN IN invoice_total(): Math.round drifted by one cent on .5 values",
  file_paths=["src/billing/invoice.ts"])

✅ Lesson stored: billing:invoice-rounding

Three weeks later, a new session, a different person, the same symptom:

smart_recall(query="invoice total is one cent off")

💡 billing:invoice-rounding · 👤 anna
   ROUND HALF-EVEN IN invoice_total(): Math.round drifted by one cent on .5 values
   ▸ src/billing/invoice.ts

Your AI starts from the fix. With the hooks, this happens before you type: the matching lessons are placed next to your prompt.

Some fixes come back. After a time/date or a dependency fix, learn_from_attempts adds a relapse watch with counted numbers from 289 open-source projects. For example: 148 of 791 time/date fixes (19 %) were followed within 90 days by another time/date problem in the same files, 4.4× as often as a random issue in the same project. Each hint links a real pair of issues as an example.

Some fixes need a second file. When you store a security fix and none of the files you name is a manifest or lock file, learn_from_attempts says so: across the same 289 projects, 1127 security fixes changed a dependency file more often than other fixes in the same project, 59 % vs 25 % in the largest dataset.

Why developers and teams use it

  • Your AI keeps what it learned. Lessons outlive the session, the editor and the model. One Brain serves Claude Code, Cursor, Copilot, Codex and the others at the same time.

  • Your team learns each thing once. invite teammate@example.com shares your Brain. Every lesson carries the name of whoever learned it, and a reviewer can confirm it so it ranks higher.

  • A light footprint in the context window. Your editor lists 27 tool entries, about 8,000 tokens per request. All 124 MCP tools stay one call away through cachly_tool.

  • Your data stays in the EU and stays yours. Storage in Germany, embeddings computed in the EU, and export writes every lesson to Markdown and JSONL whenever you like. The server is open source under Apache-2.0.

How it works

  1. A fix, a decision or a dead end is stored as a lesson: topic, what worked, what failed, severity, file paths, commands and author.

  2. At the start of a session, your AI receives a briefing with the last session, open failures and recent lessons.

  3. When you ask for something, smart_recall looks up the lessons that match. It combines keyword search (BM25), meaning-based search and the causal graph, in 11 languages.

  4. When an error appears, causal_trace walks from the symptom to the cause and to the fix that worked.

  5. Before a deploy, brain_predict lists failure patterns from past incidents.

  6. A git hook and the CI templates add lessons from commits and from red-to-green runs.

  7. Lessons are shared in the team. Each one carries the name of whoever learned it.

See it on your own project first: npx @cachly-dev/mcp-server@latest demo reads your git history and prints the fixes, patterns and decisions your AI would know. It runs entirely on your machine.

Our agreement with you. You can leave and take your data: npx @cachly-dev/mcp-server@latest export writes every lesson to lessons.md (to read) and lessons.jsonl (to reuse). Code excerpts are stored only when you call index_project yourself, and then only on your own EU instance. Read what leaves your machine before you decide.

Pricing

Plan

Price

People

Storage

Free

€0

1

25 MB, one Brain, 500 recalls a month

Solo

€19/month

1

200 MB

Team

€49/month

up to 5

900 MB

Business

€199/month

up to 20, with SSO

7 GB

Start on Free with a sign-in, without a credit card. Organisations are free; you pay per Brain plan. Yearly billing and the current limits are on cachly.dev/pricing.

Guides

Guide

What you find there

Claude Code hooks: which event to use when

SessionStart, UserPromptSubmit, PreToolUse, Stop and more, sorted by when they fire. What each one can block, add and change.

A UserPromptSubmit hook for Claude Code

The stdin JSON, additionalContext, a working Node script and five traps to avoid.

The same hooks in VS Code and Copilot CLI, Codex CLI and Gemini CLI

Which event takes context in each editor, and the exact file setup writes there.

Comparisons: Supermemory, Zep, claude-mem, Basic Memory, mem0, Letta

Side by side, each row with its source and a visible date, including when the other product fits better.

EU-hosted MCP server: what leaves your machine

Where data lands: storage in Germany, embeddings in the EU, the network edge, and a checklist.

Lessons learned for coding agents

How to write a lesson your agent finds again: symptom, decisive fact first, what failed, files, a check. With examples and a LESSONS.md.

JetBrains plugin guide

What the plugin does, and how Claude Code, Junie and JetBrains AI Assistant use the Brain.

Repo X-ray

Enter a public GitHub repo. In a few seconds you see how many problems its team has solved, and which ones more than once.

FAQ

How is this different from a CLAUDE.md or a memory folder? A rule file is read in full in every session, so it grows and costs tokens each time. cachly keeps lessons outside the prompt and places only the matching ones next to it, ranked by outcome and review. The comparisons show where a plain file or another product fits better.

Does my AI need to call session_start by hand? No. A session starts on the first tool call and ends when the editor closes.

Can my whole team share one Brain? Yes. Use team_learn and team_recall, and invite people with npx @cachly-dev/mcp-server@latest invite teammate@example.com. They get an email and accept it with the link or with join <token>. Members can read and learn; deleting the Brain, rotating its password and billing stay with the owner.

Is my code sent to cachly servers? Only if you call index_project yourself. It stores a short excerpt (up to summary_chars, 1200 characters by default) per indexed file, on your own EU instance. Every other tool stores lesson text, commit messages, session summaries and key-value context, but no source code. Storage is in Germany and embeddings are computed in the EU. API traffic passes through Cloudflare, a US company. The EU guide lists every data flow.

What is causal_trace? Given an error, it walks the causal knowledge graph to find the root cause, the intermediate causes and the fix that worked, with its date and commands.

What if I hit the context-window limit mid-session? Call compact_recover. It rebuilds your context from the Crystal, the recent sessions and the registry of work in progress. Usually one tool call is enough.

How do I write lessons my agent finds again? Lead with the decisive fact. The lessons guide shows how, with examples.

Reference

Everything below is for looking things up. The long tables open with a click.

MCP Tools (124 total, 27 listed by default)

Your editor sees 27 entries by default: the daily tools (26 of them) and one dispatcher, cachly_tool. This is on purpose. The full list of 124 costs about 28,000 tokens in every request. The 27 listed entries cost about 8,000. All other tools (98 of them) run through the dispatcher:

cachly_tool(tool: "team_roster")                  run any of them by name
cachly_tool(tool: "team_roster", describe: true)  get its schema first

Every tool stays reachable. The server dispatches by name, so team_roster called directly still works. Set CACHLY_ALLE_WERKZEUGE=1 to list all 124. Set CACHLY_PROFILE=lean to list 8 plus cachly_tool, or CACHLY_PROFILE=recall to list the 3 read-only tools.

Session and lessons (most used)

Tool

What it does

session_start

Full briefing: last session, open failures, recent lessons, Brain health

session_end

Save what you built; extract lessons from the summary and the git log

learn_from_attempts

Store a structured lesson after any fix, deploy or discovery (with author, visibility)

recall_best_solution

The known fix for a topic, with its success and failure history

smart_recall

Hybrid BM25 + semantic + causal-graph search, 11 languages, quality-reranked

remember_context

Keep architecture findings, decisions and file summaries

compact_recover

Recover your context after you hit the context-window limit

Team Brain and org knowledge graph

Tool

What it does

team_learn / team_recall

Share lessons across the team with author attribution

team_confirm

A reviewer confirms a lesson (senior or peer); confirmed lessons rank higher in recall

team_assign_role / team_roster / team_whoami

Roles (admin, reviewer, contributor, viewer), enforced once an admin is set

team_audit

Admin-only governance trail: every role change and lesson confirmation

brain_who_knows

Find your team's experts on a topic, ranked from authorship

brain_file_map

Experts and lessons per file, before you touch it

team_expertise_map

The team's skills matrix in one table

brain_collab_pairs

Who works with whom, with bus-factor alerts

brain_portability

Config snippets for 7 MCP clients, so the same Brain serves any model

skill_gaps

Knowledge blind spots: unresolved failures, missing attribution

brain_coverage

A 0–100 health score for the knowledge of your codebase

madc_deliberate

Specialist AI agents vote to resolve contradictory lessons

memory_crystalize

Distill all lessons into a Crystal for instant team context

team_crystallize

A Team Crystal: fixes that 2 or more teammates reached independently

Causal intelligence

Tool

What it does

causal_trace

Root-cause analysis through the causal knowledge graph

brain_predict / brain_predict_failures

Predict likely failures before they happen

brain_from_git

Fill people, files and lessons from git history, incrementally

brain_from_ci

Bulk-ingest CI outcomes: red→green becomes a fix lesson with a causal fixes edge, green→red a causes edge

memory_consolidate

Detect contradictions, merge duplicates, expire stale lessons

ckg_inspect

Inspect the causal graph around a concept

Example:

causal_trace(problem="auth breaks after restart")

→ Root: k8s:namespace-terminating
→ Via:  keycloak:jwks-race
→ Fix:  PollUntilContextTimeout 3min

Shareable and public Brains

Tool

What it does

brain_seed_starter

Seed 16 universal lessons so your first smart_recall finds something; runs on a fresh repo

brain_share

Publish a Brain snapshot as a link (public or unlisted). For your own data, run npx @cachly-dev/mcp-server export

brain_import

Import a shared Brain into yours: topic_prefix, min_confidence, dry_run

brain_share_list / brain_unshare

List your shares; revoke one so the link goes dead

brain_discover

Search the Brain marketplace for ready-made knowledge bases

Knowledge Commons, infrastructure and roadmap

Tool

What it does

syndicate / fedbrain_search

Contribute to, and search, the global Knowledge Commons

brain_marketplace / brain_install

Browse and install curated Domain Brains (Kubernetes, Auth, databases)

cache_get / cache_set / semantic_search / index_project

Cache and semantic operations. Pass org_id on cache_get / cache_set to share the cache org-wide

cache_stats / cache_org_stats

Hits and requests served from the cache, per instance or across your org

list_instances / create_instance / delete_instance

Manage Brain instances

roadmap_add / roadmap_next

A project roadmap stored in the Brain

Run health to see what is wired up in your editor. The full catalog is generated from src/tools.ts.

CLI commands

npx @cachly-dev/mcp-server@latest autopilot # One command: signs in, configures every editor, fills the Brain from git

Every command below runs as npx @cachly-dev/mcp-server@latest <command>. Key and Brain instance come from the environment or from ~/.cachly/credentials.json, the file autopilot writes.

Every day

status

Lessons, recalls and team at a glance

ambient-stats

Tokens injected vs saved — the honest net, even when negative

doctor

Diagnose a broken or missing install, with the fix for each step

health

Check key, API, editor configs and git hook

digest

What your Brain learned this week, shareable

Set up

demo

Preview your Brain from git history (no account needed)

setup (alias autosetup)

Interactive variant: pick editors yourself

init --editor <id>

Write the config for one editor, with flags

claim

Move a test Brain into your account, lessons included

upgrade

Check for updates

uninstall

Take cachly out of this project again. Shows your numbers first, then the plan; --dry-run only lists, --global adds the home folder

Your data

export

Write every lesson to lessons.md and lessons.jsonl

index [dir]

Index a project's code into the Brain (CI-friendly)

learn-git [repo]

Learn lessons from recent git commits

Team & sharing

invite <email>

Share your Brain with a teammate. They get an email; members can read and learn

join <token>

Accept an invitation (the command is in the email) and connect that Brain

join --brain <id>

Connect a Brain you already have access to (for example after accepting on the web)

refer

Show your personal referral link for new users

share

Generate a shareable stats card

publish

Publish your Brain as an importable link (--public)

badge

Get a live README badge for your Brain

More

bench

Run the recall benchmark (no sign-in needed)

tool-specs / openapi

Tool definitions for other agent frameworks (OpenAI, Anthropic, LangChain, OpenAPI)

The method behind bench is described in BENCH.md.

Tip: learn from every merged PR. Run learn-git in CI with the cachly-brain-setup GitHub Action and mode: learn. Each merged PR then teaches your Brain.

CI integration

Every CI run is a lesson. A red→green transition is a proven fix, and a green→red one is a known cause. Ready-to-paste templates live in src/ci-integration/:

  • GitHub Actions: use cachly-dev/cachly-action. It needs the secrets CACHLY_API_KEY and CACHLY_BRAIN_INSTANCE_ID.

  • GitLab CI: pull in the GitLab template with include: remote:. It adds hidden jobs for learn, scan, confirm and hygiene; extend the ones you want.

  • Anything else: push-ci-outcome.mjs is a standalone Node.js helper with no dependencies. It always exits 0, so your CI never fails because of a Brain push.

Already have months of CI history? The brain_from_ci tool ingests past outcomes in one call, the way brain_from_git ingests commits.

Editor support matrix

npx @cachly-dev/mcp-server@latest autopilot detects and configures the editors below. Manual snippets are in Manual Setup.

Editor / client

Auto-setup

Config file written

Global config

Notes

Claude Code

yes

.mcp.json

with the plugin

Without a key: test Brain at session start (plugin) or on the first tool call; browser sign-in only as fallback

Cursor

yes, detected via .cursor/

.cursor/mcp.json, hooks in .cursor/hooks.json

no

Project-level; restart Cursor after setup. Lessons arrive with the first tool call of a turn

Windsurf

yes, detected via .windsurf/

.windsurf/mcp.json

no

Project-level; restart Windsurf after setup

VS Code + Copilot

yes, detected via .vscode/

.vscode/mcp.json, hooks in .github/hooks/cachly-ambient.json

no

Needs the VS Code MCP support or Copilot chat. Briefing at session start, lessons before each prompt

Codex CLI

yes, detected via ~/.codex

.codex/config.toml ([mcp_servers.cachly]), hooks in .codex/hooks.json

no

Codex loads both once you trust the folder; confirm the hook once in /hooks

Gemini CLI

yes, detected via ~/.gemini

mcpServers.cachly and hooks in .gemini/settings.json

no

Gemini loads both once you trust the folder. Lessons are appended to the prompt (BeforeAgent)

Cline

yes, detected via VS Code

.vscode/mcp.json

no

Shares the config with Copilot; restart VS Code

Continue.dev

yes, detected via .continue/

.continue/config.json

no

Uses the modelContextProtocolServers key

Zed

yes, detected via .zed/

.zed/settings.json

no

Uses the context_servers key

Windsurf (global)

autosetup --editor windsurf

~/.windsurf/mcp.json

yes

Pass --editor to target the global config

Any other MCP client

autosetup --editor claude

.mcp.json

no

Standard mcpServers stdio format

Which sign-in path each case uses:

Scenario

Path

autosetup or autopilot from a terminal (TTY)

OAuth device flow: one click in the browser, the API key is saved automatically

autosetup from a VS Code task or CI (no TTY)

Detects the non-interactive run, opens the browser with a step-by-step guide, prints the CACHLY_JWT=... autosetup command

First tool call without any key

Test Brain: an anonymous Brain on EU servers. The key is saved to ~/.cachly/credentials.json, and the call goes through. If that fails (offline, rate limit), the inline device flow starts with a URL and a code

First tool call with CACHLY_BRAIN_INSTANCE_ID set but no key

Inline device flow. You already have a Brain, so no second account is created

CACHLY_JWT=cky_live_xxx npx ... autosetup

Skips the sign-in step and uses the key you pass

Manual Setup

{
  "mcpServers": {
    "cachly": {
      "command": "npx",
      "args": ["-y", "@cachly-dev/mcp-server@latest"]
    }
  }
}

For all your projects at once, use the plugin above, or claude mcp add -s user cachly -- npx -y @cachly-dev/mcp-server@latest (Claude Code stores that in ~/.claude.json).

Without a key, the first tool call creates a test Brain on EU servers. No sign-up. Run npx @cachly-dev/mcp-server@latest autopilot to use your own account instead.

{
  "mcpServers": {
    "cachly": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@cachly-dev/mcp-server@latest"]
    }
  }
}
{
  "context_servers": {
    "cachly": {
      "command": {
        "path": "npx",
        "args": ["-y", "@cachly-dev/mcp-server@latest"]
      }
    }
  }
}

Self-hosting and bring-your-own embeddings

Embeddings turn text into vectors for the meaning-based search. By default, cachly computes them on its own servers in the EU as soon as you are signed in. Your text goes to a third-party provider only when you name that provider yourself:

Provider

Env vars

Model

cachly (default, EU servers)

none beyond your key

managed

Ollama (local)

OLLAMA_BASE_URL, detected automatically

nomic-embed-text

OpenAI

CACHLY_EMBED_PROVIDER=openai and OPENAI_API_KEY

text-embedding-3-small

Google Gemini

CACHLY_EMBED_PROVIDER=gemini and GEMINI_API_KEY

text-embedding-004

Mistral

CACHLY_EMBED_PROVIDER=mistral and MISTRAL_API_KEY

mistral-embed

Cohere

CACHLY_EMBED_PROVIDER=cohere and COHERE_API_KEY

embed-english-v3.0

Run npx @cachly-dev/mcp-server@latest health to see which provider is active.

Point at your own backend. Every install can talk to a private backend instead of api.cachly.dev:

# One command: run the setup against your self-hosted backend
npx @cachly-dev/mcp-server@latest autopilot --api-url https://cachly.mycorp.internal

# Or without prompts
npx @cachly-dev/mcp-server@latest autosetup \
  --instance-id <uuid> --api-key <cky_live_...> \
  --api-url https://cachly.mycorp.internal

autosetup writes CACHLY_API_URL into the editor config only when it differs from the default cloud. Default installs stay clean, and self-hosted installs keep talking to your backend on every editor start.

Environment Variables

Variable

Default

Description

CACHLY_JWT

none

API key. The setup wizard sets it for you

CACHLY_BRAIN_INSTANCE_ID

none

Default Brain UUID. Optional, it is resolved automatically

CACHLY_API_URL

https://api.cachly.dev

Override for a self-hosted backend

CACHLY_EMBED_PROVIDER

automatic

Name an embedding provider yourself (see above)

CACHLY_ALLE_WERKZEUGE

unset

Set to 1 to list all 124 tools instead of 27

CACHLY_PROFILE

unset

lean lists 8 tools plus cachly_tool, recall lists the 3 read-only tools

CACHLY_UPDATE_CHECK

on

Set to false to stop the version check. npm is asked at most once a day, with a 2-second limit

CACHLY_NO_TELEMETRY

unset

Set to 1 to disable usage pings. They carry up to 80 characters of smart_recall queries. Your API key travels only in the Authorization header; the API verifies it before it counts the event for your account

CACHLY_LERNEN

on

Learning from use in the prompt hook. For 5 % of prompts the matching lessons are computed but not shown (control group), up to 10 % try a stricter or shorter setting. At the end of each turn the hook reports which setting ran and whether the agent named a shown lesson; topics are sent hashed, prompts never. Set to 0 (or CACHLY_NO_TELEMETRY=1) to turn it off

CACHLY_KONTROLLE_ANTEIL

5%

Share of prompts in the control group. 0 turns the control group off, at most 50%

CACHLY_ERKUNDUNG

10%

Share of prompts that may try another setting. 0 keeps the leading setting, at most 10%

Where

What you find there

cachly.dev

Sign-up, dashboard and the product page

cachly.dev/pricing

Plans, yearly billing and current limits

MCP docs · AI memory docs

Setup, tools and concepts

Release notes

What changed in each version

github.com/cachly-dev/cachly-mcp

Source code of this server

GitHub Issues

Bugs and feature requests

MCP Registry

The official entry, io.github.cachly-dev/mcp-server

Cachly Brain for VS Code

Status bar, lessons view and ambient learning in the editor

Cachly Brain for JetBrains

The same Brain in IntelliJ IDEA, PyCharm, GoLand, WebStorm and Rider (source)

cachly-dev/cachly-action

GitHub Action: setup, PR risk scan, learning from merged PRs, weekly hygiene

@cachly-dev/openclaw

Semantic caching for LLM calls in JS/TS apps

The VS Code extension shows the same Brain in the editor:

The Lessons view inside the Cachly Brain VS Code extension, listing six stored lessons


Solve it once. From then on, your AI knows.

npx @cachly-dev/mcp-server@latest autopilot

Available Tools

122 tools
auto_learn_sessionA

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.

Inputs: instance_id (required), observations (required).

autopilotA

Generate a CLAUDE.md / copilot-instructions.md that makes any AI self-managing forever. Writes a configuration file to disk — 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 session_end before closing — without being asked. Returns the generated file content as a string and the path where it was written. Use style="minimal" for just the three hooks; style="full" for the complete ruleset with examples. One command. Every AI. Always on. Use setup_ai_memory instead if you want an interactive one-shot setup that also creates an instance.

Inputs: instance_id (required), style, editor, project_name.

brain_briefingA

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 — 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 description of what is being deployed). Returns a risk_level (low/medium/high) plus up to 5 ranked warnings with confidence and a known fix.

Inputs: context (required), event_type (required), instance_id (required), threshold.

brain_changelogA

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 — share the output directly in Slack or a doc. Example: brain_changelog(instance_id="...", days=7) → grouped Markdown changelog of the week's learning.

Inputs: instance_id (required), days, max_lessons, include_failures.

brain_collab_pairsA

Show the Person↔Person Collaboration Graph for your team (W5). Lists every pair of contributors who have worked together — 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 — ideal for onboarding and bus-factor analysis. Also flags solo contributors whose knowledge no teammate has yet recalled (bus-factor risk). Example: brain_collab_pairs() → "@alice ↔ @bob — 12 events · ask them together about auth/payments".

Inputs: instance_id (required), min_weight.

brain_confirm_ciA

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 — confirmed failures get +15%, false positives (brain predicted failure but CI passed) get −10%. Called automatically by cachly-action at the end of every pipeline. Also use manually after a deploy to confirm or refute the brain's last prediction.

Inputs: topics (required), job_status (required), instance_id (required), source, +1 more.

brain_conflictsA

READ-ONLY — 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_conflict.

Inputs: instance_id (required).

brain_contribute_signalA

Contribute a privacy-safe signal to the global Brain commons. Only the topic category, outcome, and confidence bucket (high/medium/low) are shared — no lesson text, no org identity. When ≥ 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).

Inputs: outcome (required), instance_id (required), topic_category (required), confidence.

brain_coverageA

Knowledge-coverage health score for your codebase — 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() → "🟢 Overall score: 78/100 · 42 lessons · 6 contributors · 31% files covered".

Inputs: instance_id (required), repo_path.

brain_diffA

git log for your AI Brain — 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") → "12 new · 4 updated · 2 stale"

Inputs: instance_id (required), since, format.

brain_discoverA

Search and browse publicly shared Brain snapshots in the cachly marketplace. Find ready-made knowledge bases on specific topics (TypeScript, Docker, auth, CI/CD, etc.) created and shared by the community. Returns a ranked list with lesson counts, topics, and import commands. Example: brain_discover(query="kubernetes deployment") · brain_discover(topic="auth")

Inputs: limit, query, topic.

brain_doctorA

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.

Inputs: instance_id (required), workspace_path.

brain_federateA

FedBrain Layer 6 — Private org knowledge transfer: copy CKG edges + lessons from a source brain into your brain for a specific domain (e.g. "billing", "auth", "deploy"). The new hire use case: one command gives you the senior engineer's 5 years of typed, confidence-weighted knowledge in your domain. Unlike syndicate_search (global, anonymous), brain_federate is org-private — both brains must be in the same Cachly org, or the source instance_id must be explicitly shared. Example: brain_federate(source="prod-brain-id", domain="billing", min_confidence=0.6)

Inputs: domain (required), source (required), instance_id (required), dry_run, +1 more.

brain_file_mapA

Show what cachly knows about a list of files — 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"]) → "🥇 alice (3× · today) — related: fix:jwt-expiry".

Inputs: file_paths (required), instance_id (required).

brain_from_ciA

Bulk-ingest CI run outcomes into the Brain — the brain_from_git equivalent for CI history. Feed it an array of {job, status, prev_status} objects from your CI system and it will learn which jobs have been fixed, broken, or are stable. Use it to bootstrap the Brain from historical CI logs.

Inputs: outcomes (required), instance_id (required).

brain_from_gitA

Bootstrap brain lessons from git history. Parses commit messages and infers fix/feature/refactor lessons automatically. Great for onboarding an existing codebase — run once and the brain instantly knows your team's accumulated patterns. Incremental by default: only processes new commits since the last run, so repeated calls are fast. Emits progress updates to stderr during long scans.

Inputs: instance_id (required), limit, since, branch, +2 more.

brain_get_prefA

Read back one or all preferences stored for this Brain instance. Call with a key to get a single value, or omit key to list every preference that has been set. Returns a default note when a key has never been set. Complement to brain_set_pref.

Inputs: instance_id (required), key.

brain_graphA

Export the Causal Knowledge Graph as a 3D-render-ready node/link payload (schema cachly.brain_graph/v1) — the data layer behind the brain viz: the visual, explorable 3D map of every concept, person, file and service the brain knows, and how they causally relate. Node kinds (concept/person/file/service) carry stable color groups and a size (val) scaled by reference count; links carry edgeType (fixes/causes/co-occurs/authored/collaborates) and confidence (value). Consumed verbatim by react-force-graph-3d / three.js frontends. Example: brain_graph(instance_id="...") · brain_graph(instance_id="...", domain="auth", min_confidence=0.5, format="summary")

Inputs: instance_id (required), domain, format, max_nodes, +1 more.

brain_hygieneA

Autonomously sweep and maintain your Brain — 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 → provisional (confidence < threshold) → archived (stale + low-recall + old). Archived lessons are excluded from smart_recall but preserved for audit. dry_run=true (default false) shows what would change without writing anything.

Inputs: instance_id (required), dry_run, archive_days, provisional_threshold.

brain_importA

Import lessons from a publicly shared Brain snapshot into your own Brain instance. Accepts a share ID (UUID) or the full share URL from brain_share. Optionally prefix all imported topics to avoid naming collisions (e.g. topic_prefix="team"). Existing lessons are NOT overwritten by default — pass overwrite=true to replace them. Example: brain_import(instance_id="...", share_id="abc123", topic_prefix="imported")

Inputs: share_id (required), instance_id (required), dry_run, overwrite, +2 more.

brain_import_metaA

Import k-anonymous meta-lessons from the global Brain commons into your local Brain. Meta-lessons are derived from ≥ k independent org signals — no individual org data is revealed. Imported lessons get state="meta" and never overwrite your own lessons. Filter by category to target relevant patterns.

Inputs: instance_id (required), limit, category.

brain_installA

Install a Domain Brain into your local Brain — 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") → "📦 Installed: Kubernetes Incident Brain · 42 lessons merged".

Inputs: slug (required), instance_id (required), limit, dry_run, +1 more.

brain_marketplaceA

Browse the Domain Brain marketplace — curated, installable packs of high-trust community lessons, grouped by domain (Kubernetes, Auth, Database, React, Payments, …). 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_install(slug="..."). Example: brain_marketplace() → "☸️ Kubernetes Incident Brain · 42 lessons · install: brain_install(slug="k8s")".

Inputs: min_confirms.

brain_metricsA

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 — 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.

Inputs: instance_id (required).

brain_planA

READ-ONLY — 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→16", "add Stripe webhooks"), returns an ordered action plan grounded in your own proven lessons — the failure modes most likely to bite (ranked by confidence), the concrete steps that fixed them before (with commands), and a pre-flight checklist. Where brain_predict answers "what might fail?", brain_plan answers "what should I do, in what order?". Requires a valid instance_id (your Redis brain). Call before starting non-trivial work.

Inputs: task (required), instance_id (required), top_k.

brain_portabilityA

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 — same lessons, crystals, predictions, and team data. Use autopilot to configure all detected editors in one command. Example: brain_portability() → config blocks for 7 clients + model-neutrality proof table.

Inputs: instance_id (required).

brain_predictA

READ-ONLY — 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 — nothing is cached or persisted. Requires a valid instance_id (your Redis brain). No rate limits. Call at session start when working on a specific feature or debugging area. Set scope="org" to widen prediction across your whole organisation — surfaces cross-team risks ("failed 3× across 2 other teams") from the Org Knowledge Graph, so an incident in one team becomes a vaccine for yours.

Inputs: context (required), instance_id (required), scope, top_k.

brain_predict_failuresA

Pre-deploy failure prediction with probability percentages. Given a change context (e.g. "upgrading Keycloak 21→24" or "deploying Redis 7 to prod"), returns the top likely failure modes ranked by probability, with pre-loaded fixes. Uses CKG causal edges + lesson history. Call before any significant deploy, migration, or infrastructure change.

Inputs: context (required), instance_id (required), top_k, format.

brain_resolve_conflictA

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.

Inputs: topic (required), winner (required), instance_id (required), resolved_by.

brain_seed_starterA

Seed a fresh Brain with a curated set of universal, high-value engineering lessons (Docker layer cache, JWT clock skew, Postgres migration locks, K8s OOM limits, N+1 queries, cache stampede, CORS preflight, and more). Makes the very first smart_recall return a useful hit instead of nothing — ideal right after setup or in a fresh repo with no git history to learn from. Starter lessons are tagged source:"starter", never override your own lessons, and are idempotent (won't double-seed). Example: brain_seed_starter(instance_id="...") · brain_seed_starter(instance_id="...", topic_filter=["docker","redis"])

Inputs: instance_id (required), force, dry_run, topic_filter.

brain_service_mapA

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 — 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_service_map(service="prometheus") → operators, known OOM failures, and the fixes that worked.

Inputs: service (required), instance_id (required).

brain_set_prefA

Persist a user preference for this Brain instance. Preferences are stored in Redis and survive restarts. Known keys: auto_changelog (set to "false" to disable the automatic changelog shown at session_start).

Inputs: key (required), value (required), instance_id (required).

brain_shareA

Export a Brain snapshot and create a publicly shareable link that anyone can import. Optionally filter by topic prefix (e.g. only "auth:" or "deploy:" lessons). Visibility can be "public" (discoverable) or "unlisted" (link-only). Returns a share URL and the import command to give to teammates or the community. Example: brain_share(instance_id="...", title="My Auth Patterns", topic_filter=["auth"])

Inputs: instance_id (required), title, dry_run, visibility, +3 more.

brain_share_listA

List all Brain snapshots you have previously shared with brain_share. Shows share ID, title, lesson count, visibility, and creation date for each share. Checks the local provenance log and the cachly API. Example: brain_share_list(instance_id="...")

Inputs: instance_id (required).

brain_unshareA

Revoke and permanently delete a public Brain share by its share ID. After calling this, the share URL becomes invalid and no one can import it. Note: users who already imported the Brain keep their local copy. Example: brain_unshare(instance_id="...", share_id="abc123")

Inputs: share_id (required), instance_id (required).

brain_watchA

Install an ambient git post-commit hook that automatically learns from every commit — no manual brain_from_git needed. After installation every git commit silently POSTs the commit message, SHA, and changed files to the cachly Brain API in the background. Idempotent: running brain_watch twice installs the hook only once. Uses curl (not Node/npx) so it works in any environment. The hook always exits 0 and runs asynchronously — it never blocks a commit. Returns the hook path and installation status (written/upgraded/appended/unchanged/skipped-no-git).

Inputs: api_key, instance_id, project_dir.

brain_who_knowsA

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(topic="kubernetes deployment") → "🥇 alice — 5 lessons, 94% confidence".

Inputs: topic (required), instance_id (required), limit.

cache_deleteA

Permanently delete one or more keys from a running cache instance (uses Redis DEL). This operation is destructive and irreversible — 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 for auto-expiring data. Do NOT use this to clear an entire instance — use the dashboard or delete_instance for that.

Inputs: keys (required), instance_id (required).

cache_existsA

Check whether one or more keys exist in a running cache instance (uses Redis EXISTS). Read-only — 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_get to avoid null handling, or to verify a cache warm-up completed. Use cache_get instead if you also need the value; use cache_ttl if you need expiry info.

Inputs: keys (required), instance_id (required).

cache_getA

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 — 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.

Inputs: key (required), instance_id (required), org_id.

cache_keysA

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.

Inputs: instance_id (required), count, pattern.

cache_lock_acquireA

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.

Inputs: key (required), ttl_ms (required), instance_id (required), retries, +1 more.

cache_lock_releaseA

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

Inputs: key (required), token (required), instance_id (required).

cache_mgetA

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.

Inputs: keys (required), instance_id (required).

cache_msetA

Set multiple key-value pairs in a single pipeline round-trip. Supports per-key TTL – 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 for a single key; use cache_stream_set for large streaming payloads.

Inputs: items (required), instance_id (required).

cache_org_statsA

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-instance breakdown. Zero-config: no API changes required — any cache_set call with org_id writes to this namespace.

Inputs: org_id (required), instance_id (required).

cache_setA

Set a key-value pair in a running cache instance. Overwrites any existing value at the key — 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 round-trip. Use cache_stream_set instead for caching LLM token streams (ordered string chunks).

Inputs: key (required), value (required), instance_id (required), ttl, +1 more.

cache_statsA

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

Inputs: instance_id (required).

cache_stream_getA

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}.

Inputs: key (required), instance_id (required).

cache_stream_setA

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.

Inputs: key (required), chunks (required), instance_id (required), ttl.

cache_ttlA

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 — no side effects. Use cache_set with a ttl parameter to set or update the expiry.

Inputs: key (required), instance_id (required).

cache_warmupA

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 ≥ 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.

Inputs: entries (required), instance_id (required), ttl, namespace, +1 more.

causal_traceA

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 — 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 with confidence scores plus the matching solution; returns an empty chain with a message if no causal path is found. Example: causal_trace(problem="auth breaks after restart") → "Root: k8s:namespace-terminating → keycloak:jwks-race → Solution: PollUntilContextTimeout 3min". Use recall_best_solution for direct topic lookup, syndicate_search for community patterns, and causal_trace when you have a symptom and need the full root-cause chain.

Inputs: problem (required), instance_id (required), tags, max_depth.

ckg_inspectA

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.

Inputs: concept (required), instance_id (required), max_hops.

cls_ingestA

Continuous Learning Stream (CLS — Layer 5): Ingest learning signals WITHOUT explicit session_end calls. Sources: git_commit (commit message + files → CKG edges), ci_outcome (green/red build → confirms fix), ide_diagnostic (compiler error + fix pair → instant lesson). Install automatic ingestion with cls_install_hooks — brain learns from every commit and CI run.

Inputs: source (required), payload (required), instance_id (required).

cls_install_hooksA

READ-ONLY — outputs text only, writes no files, makes no network calls, has no side effects. Generates ready-to-paste shell scripts: a git post-commit hook and/or a GitHub Actions step. You must manually copy and install the output. Once the generated scripts are installed, each git commit or CI run will make outbound HTTPS calls to api.cachly.dev to feed learning signals to your brain. No auth required to call this tool — only an instance_id. Run once per repository.

Inputs: instance_id (required), hooks, repo_path.

compact_recoverA

Call FIRST after any context limit hit / compaction. Reconstructs full context from Memory Crystal + recent sessions + WIP registry + open failures. Returns a condensed briefing so the new context window starts exactly where the previous one left off — no lost progress.

Inputs: instance_id (required), focus.

create_instanceA

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, €19/mo), pro (900 MB, €49/mo), speed (900 MB Dragonfly + Semantic Cache, €79/mo), business (7 GB, €199/mo).

Inputs: name (required), tier (required).

create_orgA

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 (€99/mo, 10 seats), Business (€299/mo, 50 seats), Enterprise (custom).

Inputs: name (required), slug.

crystal_viewA

Inspect the current Memory Crystal — the compressed wisdom distilled from all past sessions. Shows top patterns per category, lesson count, and when the crystal was last refreshed. Call after session_start when you want to quickly see accumulated wisdom across all past work.

Inputs: instance_id (required), show_raw.

delete_instanceA

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

Inputs: confirm (required), instance_id (required).

detect_namespaceA

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.

Inputs: prompt (required).

fedbrain_confirmA

Confirm that a syndicated lesson from the global commons worked for you. Propagates confirmation back — increments confirm_count on the knowledge certificate. Also updates your local CKG confidence. At 10 independent confirmations → Gold Standard.

Inputs: id (required), outcome (required), instance_id (required), topic.

fedbrain_contributeA

FedBrain (Layer 6): Contribute a lesson to the global Knowledge Commons with a cryptographic knowledge certificate. Certificate includes: domain fingerprint, confidence, outcome chain hash. Lessons with 10+ independent confirmations become Gold Standard. Context-weighted: other brains with similar tech stacks see your lesson ranked higher in fedbrain_search.

Inputs: lesson_key (required), instance_id (required), visibility.

fedbrain_statusA

Show your FedBrain federation status: lessons contributed to global commons, recent confirmations, Gold Standard lessons, pending propagations. Use to track your brain's global knowledge contribution.

Inputs: instance_id (required).

forget_contextA

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.

Inputs: keys (required), instance_id (required).

get_api_statusA

Full diagnostic for your cachly Brain — call this FIRST whenever anything is not working. Returns: API reachability, JWT validity + expiry, your user ID, all Brain instances with live status (🟢 running / 🟡 provisioning / 🔴 stopped), Redis ping on the active connection, and actionable fix steps for every issue found. Workflow: run get_api_status → read the issue it flags → fix it → retry your tool.

Inputs: no named parameters.

get_connection_stringA

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

Inputs: instance_id (required).

get_instanceA

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.

Inputs: instance_id (required).

get_org_planA

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.

Inputs: org_id (required).

global_learnA

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 — 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 preferences, personal workflows, platform quirks, and universal gotchas. Example: global_learn(topic="bash:macos-arrays", lesson="Arrays work differently on macOS bash 3.2"). Use learn_from_attempts for project-specific session lessons; use team_learn to share lessons with your team.

Inputs: topic (required), lesson (required), instance_id (required), tags, +1 more.

global_recallA

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 all projects (tool quirks, shell gotchas, platform behavior). Use recall_best_solution instead for project-specific lessons; use team_recall for org-scoped lessons.

Inputs: instance_id (required), topic.

import_public_brainA

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 knowledge before your first session_start. Use publish_lesson to contribute your own lessons to the Public Brain; use learn_from_attempts for storing lessons from your own sessions.

Inputs: framework (required), instance_id (required), limit.

index_projectA

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 CACHLY_EMBED_PROVIDER + key). Run once, then re-run after major refactors. TTL=86400 (24h) keeps entries fresh.

Inputs: dir (required), instance_id (required), ttl, max_files, +3 more.

invite_memberA

MUTATION — 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.

Inputs: email (required), org_id (required), role.

knowledge_decayA

Confidence scoring for every lesson in your Brain — because old knowledge rots. Computes a decay score (0–100%) 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: "████░░░░ 40%". Use this before a big refactor to know which lessons to trust and which to re-validate.

Inputs: instance_id (required), show_top, min_age_days.

learn_from_attemptsA

Store a lesson learned from a failed or successful attempt. Call this AFTER completing any non-trivial task (deploy, debug, fix, architecture decision). The lesson will be recalled automatically in future sessions via recall_best_solution. Fields: topic (short slug like "deploy:web"), outcome ("success"|"failure"), what_worked (what solved it), what_failed (what did NOT work), context (extra details). Supports structured metadata: severity, file_paths (files involved), commands (working commands), tags. Deduplication: if a lesson for this topic already exists, it is updated with full audit trail. Contradiction detection: warns if new outcome conflicts with existing lesson outcome. Confidence: lesson starts at 1.0, decays after 5d (→0.7) and 10d (→0.5) without recall. Example: learn_from_attempts(topic="deploy:api", outcome="success", what_worked="nohup docker compose up -d --build", what_failed="docker compose up hangs on SSH timeout", severity="critical", commands=["nohup docker compose up -d --build"])

Inputs: topic (required), outcome (required), instance_id (required), what_worked (required), +12 more.

list_instancesA

List all your cachly cache instances with their status and connection details. Read-only. Returns an array of instance objects — 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_instance, cache_get, cache_set, and all other cache tools. Use get_instance to retrieve full metadata for a single instance.

Inputs: no named parameters.

list_orgsA

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

Inputs: no named parameters.

list_rememberedA

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.

Inputs: instance_id (required), limit, category.

madc_deliberateA

Multi-Agent Deliberation Chamber (MADC — Layer 3): When conflicting lessons exist for a topic, run deliberation between 6 specialist expert agents (InfraAgent, AuthAgent, DeployAgent, DatabaseAgent, DebugAgent, APIAgent). Each agent votes based on its domain CKG coverage. Unanimous vote → loser superseded. Split vote → contested flag, causal_trace required before acting. Resolution stored as permanent CKG node. Called automatically when learn_from_attempts detects a contradiction.

Inputs: topic (required), instance_id (required), context.

memory_consolidateA

Cognitive memory consolidation — 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_doctor reports > 20 lessons. Like git gc for knowledge.

Inputs: instance_id (required), dry_run, stale_days.

memory_crystalizeA

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 — grouped by category (deploy, fix, debug, …). 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. Returns a digest of what was crystallized.

Inputs: instance_id (required), label.

publish_lessonA

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 — once published to the public brain, lessons cannot be deleted via the MCP interface. Use learn_from_attempts or global_learn for private lessons; use syndicate for anonymized global sharing without framework tagging.

Inputs: topic (required), lesson (required), instance_id (required), severity, +1 more.

recall_atA

Brain Archaeology — 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 → partial → success. Also useful to understand WHY old code decisions were made.

Inputs: date (required), topic (required), instance_id (required).

recall_best_solutionA

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. ⚠️ badge = lesson is >5d old (verify before applying). 🔴 = >10d old (likely stale!). Recalling a lesson resets its confidence clock to 1.0 (marks as recently verified). Example: recall_best_solution(topic="deploy:web") → returns the working deploy command.

Inputs: topic (required), instance_id (required).

recall_contextA

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.

Inputs: key (required), instance_id (required).

remember_contextA

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, ttl } confirming the saved context. Example: remember_context("project overview", "This is a Next.js app with...") then later: recall_context("project overview"). Use recall_context to retrieve; use list_remembered to see all stored keys.

Inputs: key (required), content (required), instance_id (required), ttl, +1 more.

roadmap_addA

Add a new item to the persistent project roadmap stored in the Brain. Items survive across sessions and editors — 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.

Inputs: title (required), instance_id (required), tags, priority, +2 more.

roadmap_listA

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.

Inputs: instance_id (required), tag, status, priority, +1 more.

roadmap_nextA

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.

Inputs: instance_id (required), tag.

roadmap_updateA

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

Inputs: id (required), instance_id (required), notes, title, +3 more.

session_endA

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.

Inputs: summary (required), instance_id (required), files_changed, workspace_path, +1 more.

session_handoffA

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 incomplete. This prevents the "continue" problem where new windows lose context, skip tasks, or produce broken code.

Inputs: instance_id (required), completed_tasks (required), remaining_tasks (required), blocked_on, +3 more.

session_pingA

Lightweight checkpoint — 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 → Copilot → Cursor all see the same last checkpoint. Extremely fast — one Redis SET, no blocking operations.

Inputs: task (required), instance_id (required), provider, next_step, +1 more.

session_startA

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 focus area has known failure patterns), and memory crystals (compressed wisdom from old sessions). Also saves a session start marker so session_end can compute duration.

Inputs: instance_id (required), focus, author, provider, +1 more.

session_start_summaryA

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.

Inputs: focus (required), instance_id (required), top_n, author.

set_cost_per_callA

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 → $0.02, gpt-5.5 → $0.015, claude-sonnet-4.6 → $0.009, claude-haiku-4.5 → $0.001. After updating, cache_stats will show savings computed from your real cost. Use list_instances to find your instance_id.

Inputs: instance_id (required), cost_per_call_usd (required).

setup_ai_memoryA

One-shot setup of the cachly 3-layer AI Memory system for a project.

Layer 1 — Storage: your cachly instance (Valkey, persistent across sessions) Layer 2 — Tools: learn_from_attempts + recall_best_solution + smart_recall (the memory API) Layer 3 — Autopilot: generates a copilot-instructions.md / .github/copilot-instructions.md that instructs any MCP-compatible AI to recall known solutions BEFORE each task and save lessons AFTER — fully automatic, zero manual effort.

Returns the copilot-instructions.md content + provider-specific .mcp.json snippet. Optionally writes copilot-instructions.md directly to the project directory.

Inputs: instance_id (required), project_dir, embed_provider, project_description.

skill_gapsA

Show knowledge blind spots in your Brain — 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: 🔴 critical (failures with no solutions) → 🟡 warn → 🔵 info. Pairs with brain_coverage for a full knowledge-health picture.

Inputs: instance_id (required), min_failures.

smart_recallA

Semantically search cached context using natural language. Instead of exact key matching, finds context by meaning. Example: smart_recall("how does authentication work") → returns cached auth architecture summary. Falls back to remember_context keys if no semantic match is found.

Inputs: query (required), instance_id (required), author, threshold, +1 more.

sync_file_changesA

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.

Inputs: instance_id (required), changed_files (required), commit_msg, git_diff_stat.

syndicateA

Contribute a verified lesson to the GLOBAL Cachly Knowledge Commons — 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 this AFTER every learn_from_attempts that is worth sharing universally (critical bugs, deployment gotchas, architecture discoveries). If a lesson with the same topic already exists in the commons, it is updated in place (idempotent). Returns { key, confirm_count, scope } confirming the stored lesson. Use scope="org" to keep the lesson private to your organisation. Do NOT use for secrets or PII — content is stored in a shared knowledge base.

Inputs: topic (required), what_worked (required), tags, scope, +3 more.

syndicate_statsA

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.

Inputs: no named parameters.

team_assign_roleA

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 (🛡️ badge, stronger recall boost); contributor can store lessons and peer-review (✔️ badge); viewer is read-only. First call bootstraps governance (no auth required when no admins exist yet). After that, only an admin can assign or change roles. Example: team_assign_role(handle="alice", role="reviewer", assigned_by="bob") — bob must be an admin.

Inputs: role (required), handle (required), instance_id (required), assigned_by.

team_auditA

View the governance audit log for a shared brain — 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 — no setup. Example: team_audit(requester="alice") → "👑 role: bob set carol viewer → contributor · ✅ confirm: dave confirmed auth:jwt-skew (senior)".

Inputs: instance_id (required), limit, requester.

team_confirmA

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 🛡️/✔️ badge. Use this in code review or knowledge reviews to bless the canonical solution for a topic.

Inputs: topic (required), reviewer (required), instance_id (required), note, +1 more.

team_crystallizeA

Create a Team Crystal — 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 — that cross-person signal is the moat against single-user "Dreaming"-style memory. Needs attributed lessons (learn_from_attempts(author=...) / team_learn). Surfaces in crystal_view. Example: team_crystallize() → "🧩 pool — 3 people converged (alice, bob, carol): bounded pool + timeout".

Inputs: instance_id (required), label, min_authors.

team_expertise_mapA

Full team expertise overview — 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 — no setup needed.

Inputs: instance_id (required), top_n.

team_grant_scopeA

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") — bob must be admin.

Inputs: group (required), handle (required), instance_id (required), action, +1 more.

team_learnA

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 " so the team knows who learned it.

Inputs: topic (required), author (required), outcome (required), instance_id (required), +6 more.

team_recallA

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.

Inputs: instance_id (required), limit, topic, author.

team_rosterA

Show all team members and their assigned roles on a shared brain instance. Returns a table of handles, roles (👑 admin · 🛡️ reviewer · ✏️ contributor · 👁️ viewer), and capabilities. Use during onboarding to see who can do what, or to verify role assignments.

Inputs: instance_id (required).

team_scopesA

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.

Inputs: instance_id (required), handle.

team_synthesizeA

Team Brain Synthesis — 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 process.

Inputs: topic (required), instance_id (required).

team_whoamiA

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.

Inputs: handle (required), instance_id (required).

trace_dependencyA

Causal Chain — 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.

Inputs: dependency (required), instance_id (required), mark_review.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.8/5.0

    Scored across 122 tools

    Disambiguation3/5

    Tools are grouped with clear prefixes (cache_, brain_, team_, global_, syndicate_), but within each group there are many tools with overlapping scopes. For example, recall_best_solution, smart_recall, team_recall, global_recall, and brain_search all retrieve knowledge with subtle differences. Detailed descriptions help but the volume forces agents to read carefully to avoid misselection.

    Naming Consistency4/5

    Overall naming follows a consistent snake_case verb_noun pattern with descriptive prefixes (e.g., cache_get, brain_conflicts, team_assign_role). A few tools like trace_dependency and compact_recover lack prefixes, and some use acronyms (madc_deliberate, cls_ingest), but the majority is predictable and well-organized.

    Tool Count2/5

    122 tools is far beyond typical MCP servers (3-15). Even for a comprehensive cognitive brain system, this number risks overwhelming agents and makes the set hard to navigate. Many tools could be consolidated (e.g., multiple session utilities, multiple recall variants with overlapping functionality).

    Completeness5/5

    The tool set is extremely comprehensive, covering every aspect of the declared purpose: cache CRUD and monitoring, lesson lifecycle (learn, recall, confirm, resolve, consolidate), team management, global knowledge commons, federation, session management, roadmap, and knowledge graph inspection. No obvious gaps exist for the stated domain.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      C
      maintenance
      Persistent cloud memory for AI coding assistants. 28 MCP tools for semantic search, auto-learning, task tracking, correction patterns, knowledge graphs, and session replay across Claude Code, Cursor, Windsurf, Cline, and any MCP client. Encrypted at rest. Team shared memory with author attribution.
      35
      992 npm
      7
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      AI memory that works like yours. Neural pathway architecture gives your AI persistent recall, contextual awareness, and cross-session continuity the way human memory actually works. 14 MCP tools. Works with Claude Code, Cursor, Windsurf, and any MCP client. $50/mo unlimited.
      15
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Persistent memory for any AI assistant. Zero token cost until recall. Stores memories in local SQLite, ranks by 6-factor scoring, returns results 79% smaller than JSON. Works with Claude, ChatGPT, Grok, Cursor, Windsurf, and any MCP client.
      56
      Apache 2.0
    • A
      license
      A
      quality
      D
      maintenance
      Persistent memory API for AI agents — store, recall, and inject semantically-searchable context across sessions. EU-hosted, GDPR-compliant. Supports Claude, Cursor, Cline, and any MCP-compatible client.
      4
      2
      MIT