Any MCP tool
Your addon is a WASM module lean-ctx loads, or a small MCP server it starts and talks to for you. No fork, no recompile.
Addons
Extend lean-ctx, not fork it.
One command installs a signed addon: a sandboxed WASM module that runs inside your context pipeline, or an MCP server wired into your gateway. Its output is then handled like your own code — secrets scrubbed, compressed to a token budget, searchable before your agent reads it.
An addon’s output becomes part of your context.
Here’s what happens after you add one. Every result the addon returns runs through the same pipeline as your own code before your agent sees it. It comes back smaller, searchable, and for some addons it lands right inside the ctx_ tools you already use.
The lean-ctx gateway
Every result passes through four steps first:
- Compresses the output so it costs fewer tokens.
- Sends oversized results to disk and keeps a small reference.
- Indexes it in the background so you can search it later.
- Wires it straight into the ctx_ tools you already use.
The tools you already use
Results land in the same ctx_ tools your agent already calls. One place to look instead of ten.
✓Search your own code and every addon from one place.
✓Secrets get stripped out before anything reaches your agent.
✓Results are cached, so reading them again is basically free.
Addons directory for lean-ctx.
MCP servers people wire into lean-ctx. Each card shows the [mcp] block you drop into your own lean-ctx-addon.toml; signed packages are installed with one lean-ctx addon add. The ones marked “listed” don’t have an MCP endpoint yet, so they link to their project instead.
19 addons 0 installable packages 10 ready to wire
Headroom
Reversible context compression for tool outputs, logs, files and RAG chunks — 60–95% fewer tokens, originals retrievable on demand. Installs on add (uv tool install) and wires its MCP server (headroom mcp serve) into the lean-ctx gateway.
Sophon
Deterministic context compressor for MCP agents — shrinks prompts, conversation history, code digests, file deltas and shell output with zero ML at query time. Single Rust binary; installs on add (npm) and wires its MCP server (sophon serve) into the lean-ctx gateway.
RTK (Rust Token Killer)
Listed
Single-binary CLI proxy that filters and compresses shell command output by 60–90%. Reaches MCP clients through the community rtk-mcp bridge (built from source), so the lean-ctx gateway can run commands through it.
Repomix
Packs a whole repository into a single AI-ready file. Its MCP server (npx repomix --mcp) lets agents pack local or remote repos and grep the output on demand.
Serena
LSP-backed semantic code retrieval, editing and refactoring — the IDE for your coding agent. Connects over MCP via stdio or Streamable HTTP.
MCP Code Context
Compresses any codebase into LLM-ready semantic context with Tree-sitter WASM (TypeScript, JavaScript, Python, PHP, Dart) — symbol-level reads and AST-aware edits. Runs on add via npx; no install or native build needed.
Codebase Intelligence
Parses your whole repo with Tree-sitter into a semantic graph of symbols, references and dependencies — symbol search, call graphs and impact analysis. 18 tools, 8 languages, zero infrastructure or keys. Runs on add via npx.
CodeCompress
Local code-intelligence index that gives agents surgical access to symbols — project outline, get/expand symbol, hot-path and references — backed by a SQLite index. Installs on add (.NET global tool) and wires its MCP server.
Graphify
Listed
Turns code, docs, schemas and more into one queryable knowledge graph for agents. Ships an MCP server (stdio + HTTP), but serving needs a graph built by `graphify extract` (an LLM-backed step), so it is listed rather than auto-installed.
Claude Context
Listed
Semantic code search over an entire codebase (hybrid BM25 + dense vectors) via @zilliz/claude-context-mcp. Needs a Milvus/Zilliz vector database and an embedding API key to run, so it is listed rather than auto-installed.
Context-Mem
Local long-term memory and context compression for coding agents — a markdown vault with hybrid BM25 + vector search and progressive disclosure, no API key required. Installs on add (npm) and wires its MCP server (context-mem serve).
Mem0
Listed
Drop-in long-term memory for agents (vector + graph + key-value). Provides an official MCP server, but needs an API key/backend to run, so it is listed rather than auto-installed.
Cognee
Listed
Builds a queryable knowledge graph plus vector store from your data (ECL / GraphRAG pipeline). Ships an MCP server with local default databases, but needs an LLM API key to process, so it is listed rather than auto-installed.
Letta (MemGPT)
Listed
Stateful agent runtime that manages its own memory like an operating system (core + archival tiers). Exposes MCP-compatible tools, but needs a running server + database, so it is listed rather than auto-installed.
Graphiti (Zep)
Listed
Temporal knowledge-graph memory for agents — a bi-temporal entity/edge graph with hybrid semantic, keyword and graph search. Ships an MCP server, but needs a Neo4j/FalkorDB backend and an LLM API key, so it is listed rather than auto-installed.
Zep
Listed
Memory platform for AI agents — persistent threads, a knowledge graph and semantic recall via a managed cloud or self-hosted Community Edition. Reaches agents over MCP, but needs an account/API key, so it is listed rather than auto-installed.
Sequential Thinking
Structured step-by-step reasoning tool — the official MCP reference server for breaking a hard problem into revisable thoughts.
Lean-MarkDown (lean-md)
Listed
Directive-driven Markdown for agent plans. Reusable macros, phase-isolation and single-sourcing keep plans token-lean and cache-safe — written hard against lean-ctx, inspired by MarkdownAI.
Everything (MCP smoke-test)
Official MCP reference server that exercises every protocol feature — install it to verify your lean-ctx gateway can discover and call downstream tools.
No addons match your filters.
+Your addon here
Start building → Ship a WASM module or an MCP server, sign it with one command, and publish it anywhere.
Ship to every LeanCTX user.
It’s the easiest way to get your tool in front of people who already work in the terminal all day.
One command to install
Users run one lean-ctx addon add and your tool is live — loaded into their pipeline, or wired into their gateway. No fork, no recompile, no setup guide.
Reach the whole ecosystem
The module travels inside the signed package, so the signature covers the executable bytes. Nothing external to host, hash or serve.
Deeper than a passthrough
LeanCTX can fold your output into the same ctx_ tools it uses for your own code. People then search and graph your addon like everything else, instead of it sitting in a side channel.
Powerful addons, safe by design.
An addon runs real code on your machine. lean-ctx verifies what it can, bounds what it can, and tells you plainly about the part it cannot — before anything is installed.
Disclosed before it runs
Before anything is stored, you see the publisher key, every module digest, and the exact command a declared server would run — printed in full, not summarised. Nothing is installed until you say yes, and it refuses to proceed unattended without --yes.
Bounded where it can be, honest where it can’t
WASM modules run sandboxed: no ambient environment, a fresh store per call, and the host applies the output budget after decoding. A declared MCP server is an ordinary process with your privileges — lean-ctx says so before you consent, and never installs the binary for you.
Untrusted output, handled
Whatever an addon returns gets scanned for secrets and marked as untrusted before the model sees it. That’s a hard wall against data leaks and prompt injection.
Verified locally, not vouched for remotely
The signature is re-checked on your machine rather than trusted from wherever the file came — registry compromise is not client compromise. Every module is verified against its pinned SHA-256, and a pinned server binary is hashed before every spawn.
Bounds where they can be enforced: a WASM addon runs sandboxed and every package signature is re-verified on your machine. A declared MCP server is an ordinary process with your privileges — lean-ctx shows its exact command before you consent and never installs it for you. See the security model.
Ship your own addon in four steps.
Anyone can publish one. An addon is a signed package: a sandboxed WASM module, a declared MCP server, or both.
Expose your tool as an MCP server
Ship a small program that speaks MCP over stdin/stdout, or an HTTP endpoint. That’s what lean-ctx runs or connects to. It stays its own process, so there’s no fork and no recompile.
Add a lean-ctx-addon.toml manifest
Declare metadata in [addon] and how lean-ctx launches your server in [mcp]. Without an [mcp] block your entry is listed; with one it is installable.
Test it live, locally
Run lean-ctx addon release ./my-addon to build a signed .ctxpkg, then lean-ctx addon add ./my-addon-1.0.0.ctxpkg. That’s the full flow — no artifact host, no checksum files, no CI of your own.
Get listed
Publish the package wherever you like, or push it to a registry you name with lean-ctx pack publish. Users install it with lean-ctx addon add, which verifies the signature locally before asking them.
lean-ctx-addon.toml
[addon]
name = "my-addon" # slug: [a-z0-9-]
display_name = "My Addon"
description = "What it does, in one line."
author = "you"
homepage = "https://github.com/you/my-addon"
license = "Apache-2.0"
categories = ["workflow"]
[mcp]
transport = "stdio" # or "http"
command = "my-addon-mcp" # stdio: executable to spawn
args = ["serve"]Full walkthrough in the addons documentation and the build & publish guide. To be listed here, open a merge request against the curated list.
Built something for lean-ctx?Let’s launch it.
Ship a signed package and every lean-ctx user is one verified lean-ctx addon add away from your work.