llm-context
The server provides tools for managing and querying project context in LLM-assisted development with three primary functions:
Generate Repository Overview: Creates a structured overview with directory trees, file statuses, key file contents, and smart outlines for supported languages
Retrieve File Contents: Fetches complete contents of specific files for analysis or text searches
List Modified Files: Tracks files changed since a given timestamp, helping identify updates during conversations
The server also supports customization through profiles to define file inclusion rules and presentation formats for tailored outputs, while managing context to avoid redundant requests.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@llm-context generate context for the authentication module"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
LLM Context
Context curation your coding agent does for itself. lc-init installs a skill that teaches the agent to work out which files a task actually needs, write that down as a composable rule, check the rule against the codebase, and pack the result — for its own context, for a chat you paste into, or for a sub-agent it dispatches.
Getting the right context into an LLM is friction-heavy: finding and copying files by hand wastes time, too much context hits token limits, too little misses what matters, and follow-up file requests mean more manual fetching. The usual answers are to send everything, or to have a person curate by hand. A rule describes the selection once, and it is a thing an agent can author, verify and reuse — the tooling handles packing, follow-up fetches, and change tracking.
Documentation lives in the skill
The full documentation is the lc-curate-context skill, installed into your project by lc-init. It is written to be read by an agent, and it is the only copy — this README is a landing page, not a manual.
File | Contents |
| Writing a rule; the workflow; packing for a sub-agent |
| CLI and MCP reference, including output routing |
| Rule file schema and every field |
| Reusable rule shapes |
| Worked examples |
| Failure cases |
Find them at .claude/skills/lc-curate-context/ after lc-init. In Claude Code the skill loads automatically; elsewhere, read the files directly.
Related MCP server: hive
Installation
uv tool install "llm-context>=0.6.0"
cd <project-root>
lc-init # creates .llm-context/, installs the skill into .claude/skills/Upgrading: uv tool upgrade llm-context, then any lc-* command refreshes the skill, rules and templates in place.
Three ways to use it
Your coding agent, curating for itself — this is the primary path. After lc-init the agent has the lc-curate-context skill, so "get me focused context for the auth refactor" becomes a rule it writes and verifies without you naming files.
lc-preview -r tmp-prm-auth # what does this rule actually select?lc-preview reports the exact file lists, the size, and — via the code graph — files defining symbols the selection uses but does not include. That last section is how the agent catches the module it forgot, before spending a turn on a wrong answer.
A sub-agent, via a pipe — a dispatcher writes the prompt, llm-context supplies the files.
lc-context -r tmp-prm-auth -a | claude -p 'Your task here'-r routes output to stdout; without it lc-context copies to the clipboard, so a pipe or redirect gets nothing but log lines. These commands take no bare positional rule name — always -r. -a renders the pack's fetch instructions as shell commands the child runs itself, so from the repo root it can call lc-missing against the pack's timestamp for anything left out. See SKILL.md "Packing for a Sub-Agent".
A chat, via MCP or the clipboard — for models that aren't driving a terminal.
{
"mcpServers": {
"llm-context": {
"command": "uvx",
"args": ["--from", "llm-context", "lc-mcp"]
}
}
}With MCP the model pulls files it wasn't given and notices ones that changed underneath it, through lc_missing, lc_changed, lc_outlines and lc_preview. Without it, lc-select then lc-context puts the pack on your clipboard to paste anywhere.
Rules in one minute
A rule is YAML frontmatter plus optional markdown:
---
description: "Debug API authentication"
compose:
filters: [lc/flt-no-files]
excerpters: [lc/exc-base]
also-include:
full-files: ["/src/auth/**", "/tests/auth/**"]
---
Focus on the authentication system and its tests.You rarely write one by hand — the skill does, and lc-preview is how it checks its work. Rules compose, and are named by category: prm- produces a context, flt- controls file inclusion, ins- supplies guidelines, sty- enforces coding standards, exc- configures excerpting. Files you expect to edit go in full-files; supporting code goes in excerpted-files, where it is reduced to signatures and definitions. See SYNTAX.md and PATTERNS.md.
What a generated context contains
Complete contents for full files, structural excerpts for the rest, a filtered file listing marking what is and isn't included, and a timestamp that lc-missing and lc-changed resolve against.
A pack is always partial — the listing is filtered by your .gitignore files and by the rule before anything is marked excluded, so files can exist that it never mentions. The header reports how many files are full, outlined and excerpted, so a consumer can check what it actually received rather than trusting the rule.
Learn More
Design Philosophy — why llm-context exists
Real-world Examples — using full context effectively
License
Apache License, Version 2.0. See LICENSE for details.
Developed in collaboration with several Claude models and Groks, using LLM Context itself to share code during development. All code is heavily human-curated by @restlessronin.
Available Tools
4 toolslc_changedB
Returns list of files modified since given timestamp. Args: root_path: Root directory path (e.g. '/home/user/projects/myproject') timestamp: Unix timestamp to check modifications since
Inputs: root_path (required), timestamp (required). Returns: result
lc_missingC
Unified tool for retrieving missing context (files, implementations, or excluded sections). Args: root_path: Root directory path (e.g. '/home/user/projects/myproject') param_type: Type of data - 'f' for files, 'i' for implementations, 'e' for excluded sections data: JSON string containing the data (file paths in /{project-name}/ format or implementation queries) timestamp: Context generation timestamp
Inputs: root_path (required), param_type (required), data (required), timestamp (required). Returns: result
lc_outlinesC
Returns excerpted content highlighting important sections in all supported files. Args: root_path: Root directory path rule_name: Rule to use for file selection rules timestamp: Context generation timestamp to check against existing selections
Inputs: root_path (required). Returns: result
lc_rule_instructionsC
Provides step-by-step instructions for creating custom rules. Args: root_path: Root directory path
Inputs: root_path (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 4 tools
The tools have distinct purposes: lc_changed identifies modified files, lc_missing retrieves missing context, lc_outlines highlights important sections, and lc_rule_instructions provides rule creation guidance. There is minor potential overlap between lc_missing and lc_outlines in handling file content, but their specific focuses (missing vs. highlighted sections) keep them mostly separate.
All tool names follow a consistent 'lc_' prefix with descriptive suffixes (changed, missing, outlines, rule_instructions). This uniform pattern makes the tools easily identifiable as part of the same set and aligns with the server's 'llm-context' theme.
With 4 tools, the count is reasonable for a context management server, covering key operations like tracking changes, retrieving missing data, outlining content, and rule creation. It might benefit from additional tools for advanced context manipulation, but the core functionality is well-represented.
The tools cover essential context management tasks: monitoring changes, filling gaps, summarizing content, and rule setup. However, there are notable gaps, such as tools for deleting or updating context rules, managing context history, or integrating with external systems, which could limit agent workflows in more complex scenarios.
Maintenance
Related MCP Connectors
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Shared brain, one current version of memory for any MCP client: ChatGPT, Claude, Gemini, Cursor
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).12 npm3Apache 2.0
- AlicenseAqualityBmaintenanceContext infrastructure for AI-assisted development — on-demand Obsidian vault access via MCP131,232 PyPI10MIT
- AlicenseNot gradedqualityDmaintenanceEnables LLM-powered code analysis, generation, debugging, and context management through MCP integration with IDEs like Cursor and Claude Desktop.MIT
- AlicenseNot gradedqualityDmaintenanceProvides VS Code active editor context (open file, cursor position, selection) to MCP-compatible AI tools.10 npm1MIT