What can you do with this server?

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.

How do I use llm-context?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. 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.

en es ja ko zh

llm-context

by cyberchitta

Overview Schema Related Servers Score Discussions

Python

Hybrid

LLM Context

License PyPI version Downloads

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
`SKILL.md`	Writing a rule; the workflow; packing for a sub-agent
`COMMANDS.md`	CLI and MCP reference, including output routing
`SYNTAX.md`	Rule file schema and every field
`PATTERNS.md`	Reusable rule shapes
`EXAMPLES.md`	Worked examples
`TROUBLESHOOTING.md`	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 tools

lc_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

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes
`timestamp`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does (returns a list of modified files) but doesn't describe important behavioral aspects like: what format the returned list is in, whether it's recursive or only checks the root directory, error handling for invalid paths, permissions required, or rate limits. The description is minimal and lacks behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise and well-structured. It starts with the core purpose, then lists parameters with brief explanations. Every sentence earns its place, and there's no unnecessary verbiage. The example path format adds clarity without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there's an output schema (which should describe the return format), the description doesn't need to explain return values. However, for a file system tool with no annotations, it should provide more behavioral context about traversal depth, error conditions, or permissions. The description covers the basic purpose and parameters adequately but could be more complete about operational behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides clear semantic meaning for both parameters beyond what the schema offers. The schema has 0% description coverage (just titles 'Root Path' and 'Timestamp'), but the description explains: 'root_path: Root directory path (e.g. '/home/user/projects/myproject')' and 'timestamp: Unix timestamp to check modifications since'. This adds valuable context about format and purpose that the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Returns list of files modified since given timestamp.' This is a specific verb ('returns list of files') with a clear resource scope ('modified since given timestamp'). It doesn't explicitly differentiate from sibling tools like 'lc_missing' or 'lc_outlines', but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or any context for choosing this over other options. The only usage context is implied by the parameters, but there's no explicit when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes
`param_type`	Yes
`data`	Yes
`timestamp`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'retrieves' missing context, implying a read-only operation, but doesn't address permissions, rate limits, error handling, or what 'retrieving' entails operationally. The description lacks behavioral context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a purpose statement followed by parameter explanations in a list format. It's front-loaded with the main function and avoids unnecessary details, though the parameter explanations could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters with 0% schema coverage and no annotations, the description provides basic context but lacks depth. An output schema exists, so return values needn't be explained, but the tool's operational behavior and parameter semantics remain under-specified for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides brief explanations for each parameter (e.g., 'Root directory path', 'Type of data'), but these are minimal and don't fully clarify usage. For example, 'data' is described as 'JSON string containing the data' without detailing structure or examples beyond file paths. The description adds some value but doesn't fully compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'retrieving missing context' with specific resource types (files, implementations, excluded sections). It uses the verb 'retrieving' and identifies the resource scope, though it doesn't explicitly differentiate from sibling tools like lc_changed or lc_outlines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description mentions the tool is 'unified' but doesn't specify use cases, prerequisites, or exclusions compared to sibling tools like lc_changed or lc_outlines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns excerpted content highlighting important sections,' which implies a read-only operation, but doesn't specify whether it modifies files, requires specific permissions, has rate limits, or what the output format entails. The description lacks details on behavioral traits like error handling or performance characteristics, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise with two sentences and a parameter list, but it's not optimally structured. The first sentence clearly states the purpose, but the parameter list includes undocumented items that conflict with the schema, adding noise. While it avoids excessive verbosity, the inconsistency reduces its effectiveness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (involving file processing and rule-based selection) and the presence of an output schema, the description is incomplete. It doesn't explain what 'excerpted content' or 'important sections' mean, what file types are supported, or how rules are applied. The parameter discrepancy further undermines completeness. Although the output schema might cover return values, the description lacks essential context for proper tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description lists three parameters (root_path, rule_name, timestamp), but the input schema only documents one parameter (root_path) with 0% schema description coverage. This creates a contradiction and leaves two parameters (rule_name, timestamp) entirely undocumented in both the schema and description. The description fails to add meaningful semantics beyond the schema and doesn't compensate for the low coverage, resulting in confusion about parameter validity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Returns excerpted content highlighting important sections in all supported files.' It specifies the verb ('Returns excerpted content') and resource ('all supported files'), and distinguishes it from siblings by focusing on content highlighting rather than change detection, missing files, or rule instructions. However, it doesn't explicitly differentiate from siblings in the description text itself, so it falls short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings (lc_changed, lc_missing, lc_rule_instructions). It lists parameters but doesn't explain the context or prerequisites for invoking the tool, such as what types of files are supported or when excerpting is appropriate. This leaves the agent with minimal usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lc_rule_instructionsC

Provides step-by-step instructions for creating custom rules. Args: root_path: Root directory path

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'provides' instructions, implying a read-only operation, but doesn't clarify if this requires authentication, has rate limits, affects system state, or what format the instructions take. The description is too vague about behavioral traits beyond the basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences: one stating the purpose and another documenting the parameter. It's front-loaded with the main purpose. However, the parameter documentation could be integrated more smoothly rather than as a separate 'Args:' section.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (which handles return values), one parameter, and no annotations, the description is minimally adequate. It states the purpose and documents the parameter, but lacks behavioral context and usage guidance. For a tool with output schema support, this is borderline complete but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It documents the single parameter 'root_path' with minimal context: 'Root directory path.' This adds some meaning beyond the schema's type information but doesn't explain what this path represents, format expectations, or why it's required. With one parameter and low coverage, this is insufficient compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Provides step-by-step instructions for creating custom rules.' This is a specific verb ('provides') + resource ('instructions') combination that explains what the tool does. However, it doesn't differentiate from sibling tools like lc_changed, lc_missing, or lc_outlines, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparisons with sibling tools. The only usage hint is the parameter documentation, which doesn't address tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Jan 2, 2026
- Addedlc_changed
- Addedlc_missing
- Addedlc_outlines
- Addedlc_rule_instructions

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ContexterOAuth
io.github.maaakso
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Knowledge & Memory Note Taking
1
Great ArrowOAuth
ai.greatarrow
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
1
claude-context-bridgeOAuth
io.github.PhoenixFeuer32
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Communication Knowledge & Memory Developer Tools
2
ContextStream BOAuth
io.contextstream
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Knowledge & Memory Developer Tools
30241

Related MCP Servers

@lex-tools/codebase-contextofficial
Code Analysis Developer Tools Documentation Access
lex-tools
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).
Updated a year ago (2025-08-02 06:43 UTC)
1
12
3
Apache 2.0
hive
Knowledge & Memory Note Taking Developer Tools
mlorentedev
A
license
A
quality
A
maintenance
Context infrastructure for AI-assisted development — on-demand Obsidian vault access via MCP
Updated 5 days ago (2026-09-01 15:48 UTC)
13
10
MIT
Locus
Knowledge & Memory Developer Tools
Magnifico4625
A
license
Not graded
quality
B
maintenance
Local persistent memory for AI coding tools. Stores project context and conversation recall locally via MCP.
Updated 3 months ago (2026-06-10 10:53 UTC)
11
14
MIT
Context7 MCP Server
Developer Tools Code Analysis AI & Machine Learning
Mapileon2
F
license
Not graded
quality
D
maintenance
Enables LLM-powered code analysis, generation, debugging, and context management through MCP integration with IDEs like Cursor and Claude Desktop.
Updated a year ago (2025-08-20 20:45 UTC)
-

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyberchitta/llm-context.py'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

LLM Context

Documentation lives in the skill

Installation

Three ways to use it

Rules in one minute

What a generated context contains

Learn More

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@lex-tools/codebase-contextofficial

Appeared in Searches

Latest Blog Posts

MCP directory API