Jinni: Bring Your Project Into Context
About
A tool to provide Large Language Models with project context by intelligently filtering and concatenating relevant files.
Details
- License
- Apache-2.0
Explore
Efficient Context Gathering: Reads and concatenates relevant project files in one operation.
Intelligent Filtering (Gitignore-Style Inclusion):
Uses a system based on .gitignore syntax (pathspec library's gitwildmatch).
Automatically loads .gitignore files from the project root downward. These exclusions can be overridden by rules in .contextfiles.
Supports hierarchical configuration using .contextfiles placed within your project directories. Rules are applied dynamically based on the file/directory being processed.
Matching Behavior: Patterns match against the path relative to the target directory being processed. Output paths remain relative to the original project root.
Rule Root Behavior: Each target has its own rule root:
Targets within the project root (or CWD) use the project root/CWD as their rule root
External targets use themselves as their rule root, ensuring self-contained rule sets
Overrides: Supports --overrides (CLI) or rules (MCP) to use a specific set of rules exclusively. When overrides are active, both built-in default rules and any .contextfiles are ignored. Path matching for overrides is still relative to the target directory.
Explicit Target Inclusion: Files explicitly provided as targets are always included (bypassing rule checks, but not binary/size checks).
Customizable Configuration (.contextfiles / Overrides):
Define precisely which files/directories to include or exclude using .gitignore-style patterns applied to the relative path.
Patterns starting with ! negate the match (an exclusion pattern). (See Configuration section below).
Large Context Handling: Aborts with a DetailedContextSizeError if the total size of included files exceeds a configurable limit (default: 100MB). The error message includes a list of the 10 largest files contributing to the size, helping you identify candidates for exclusion. See the Troubleshooting section for guidance on managing context size.
Metadata Headers: Output includes a path header for each included file (e.g., ```path=src/app.py). This can be disabled with list_only.
Encoding Handling: Attempts multiple common text encodings (UTF-8, Latin-1, etc.).
List Only Mode: Option to only list the relative paths of files that would be included, without their content.
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
Jinni: Bring Your Project Into ContextCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
You can install Jinni using pip or uv:
Using pip:
pip install jinni
Using uv:
uv pip install jinni
This will make the jinni CLI command available in your environment. See the "Running the Server" section above for how to start the MCP server depending on your installation method.
MCP server config file for Cursor / Roo / Claude Desktop / client of choice:
{
"mcpServers": {
"jinni": {
"command": "uvx",
"args": ["jinni-server"]
}
}
}
You can optionally constrain the server to only read within a tree for security in case your LLM goes rogue: add "--root", "/absolute/path/" to the args list.
Install uv if it is not on your system: https://docs.astral.sh/uv/getting-started/installation/
Reload your IDE and you can now ask the agent to read in context.
If you want to restrict this to particular modules / paths just ask - e.g. "Read context for tests".
In action with Cursor:

Invocation: The model can invoke the usage tool (no arguments needed).
Output: Returns the content of the README.md file as a string.
(Detailed server setup instructions will vary depending on your MCP client. Generally, you need to configure the client to execute the Jinni server.)
Running the Server:
Recommended Method: Use uvx to run the server entry point directly (requires the jinni package to be published on PyPI or findable by uvx):
uvx jinni-server [OPTIONS]
Example MCP client configuration (e.g., claude_desktop_config.json):
{
"mcpServers": {
"jinni": {
"command": "uvx",
"args": ["jinni-server"]
}
}
}
You can optionally constrain the server to only read within a tree for security in case your LLM goes rogue: add "--root", "/absolute/path/" to the args list.
See your specific MCP client's documentation for precise setup steps. Ensure uv is installed
Jinni uses .contextfiles (or an override file) to determine which files and directories to include or exclude, based on .gitignore-style patterns.
Core Principle: Rules are applied dynamically during traversal, relative to the current target directory being processed.
Location (.contextfiles): Place .contextfiles in any directory. Rule discovery starts from the rule root (project root for internal targets, target itself for external targets) and proceeds downward to the current directory being processed.
Format: Plain text, UTF-8 encoded, one pattern per line.
Syntax: Uses standard .gitignore pattern syntax (specifically pathspec's gitwildmatch implementation).
Comments: Lines starting with # are ignored.
Inclusion Patterns: Specify files/directories to include (e.g., src//.py, .md, /config.yaml).
Exclusion Patterns: Lines starting with ! indicate that a matching file should be excluded (negates the pattern).
Anchoring: A leading / anchors the pattern to the directory containing the .contextfiles.
Directory Matching: A trailing / matches directories only.
Wildcards: , , ? work as in .gitignore.
Rule Application Logic:
1. Determine Target: Jinni identifies the target directory (either explicitly provided or the project root).
2. Override Check: If --overrides (CLI) or rules (MCP) are provided, these rules are used exclusively. All .contextfiles and built-in defaults are ignored. Path matching is relative to the target directory.
3. Dynamic Context Rules (No Overrides): When processing a file or subdirectory:
Jinni finds all .gitignore and .contextfiles starting from the rule root down to the current item's directory.
Rules are combined in order: built-in defaults, .gitignore rules, .contextfiles rules (which take precedence).
It compiles these combined rules into a specification (PathSpec).
It matches the current file/subdirectory path, calculated relative to the target directory, against this specification.
4. Matching: The last pattern in the combined rule set that matches the item's relative path determines its fate. ! negates the match. If no user-defined pattern matches, the item is included unless it matches a built-in default exclusion (like !.).
5. Target Handling: Explicitly targeted files bypass rule checks. Output paths always remain relative to the original project_root.
/config.json
1. Setup: Configure your MCP client (e.g., Claude Desktop's claude_desktop_config.json) to run the jinni server via uvx.
2. Invocation: When interacting with your LLM via the MCP client, the model can invoke the read_context tool.
project_root (string, required): The absolute path to the project root directory. Rule discovery and output paths are relative to this root.
targets (JSON array of strings, required): Specifies a mandatory list of file(s)/directory/ies within project_root to process. Must be a JSON array of string paths (e.g., ["path/to/file1", "path/to/dir2"]). Paths can be absolute or relative to CWD. All target paths must resolve to locations inside project_root. If an empty list [] is provided, the entire project_root is processed.
rules (JSON array of strings, required): A mandatory list of inline filtering rules (using .gitignore-style syntax, e.g., ["src//.py", "!.tmp"]). Provide an empty list [] if no specific rules are needed (this will use built-in defaults). If non-empty, these rules are used exclusively, ignoring built-in defaults and .contextfiles.
list_only (boolean, optional): If true, returns only the list of relative file paths instead of content.
size_limit_mb (integer, optional): Override the context size limit in MB.
debug_explain (boolean, optional): Enable debug logging on the server.
exclusions (object, optional): Exclusion configuration with three optional fields:
global (array of strings): Keywords to exclude globally (e.g., ["tests", "deprecated"])
scoped (object): Map of paths to keyword arrays for scoped exclusions (e.g., {"src/legacy": ["old", "deprecated"]})
patterns (array of strings): File patterns to exclude (e.g., [".test.js", "_old."])
3. Output: The tool returns a single string containing the concatenated content (with headers) or the file list. Paths in headers/lists are relative to the provided project_root. In case of a context size error, it returns a DetailedContextSizeError with details about the largest files.
Invocation: The model can invoke the usage tool (no arguments needed).
Output: Returns the content of the README.md file as a string.
(Detailed server setup instructions will vary depending on your MCP client. Generally, you need to configure the client to execute the Jinni server.)
Running the Server:
Recommended Method:* Use uvx to run the server entry point directly (requires the jinni package to be published on PyPI or findable by uvx):
uvx jinni-server [OPTIONS]
Example MCP client configuration (e.g., claude_desktop_config.json):
{
"mcpServers": {
"jinni": {
"command": "uvx",
"args": ["jinni-server"]
}
}
}
You can optionally constrain the server to only read within a tree for security in case your LLM goes rogue: add "--root", "/absolute/path/" to the args list.
See your specific MCP client's documentation for precise setup steps. Ensure uv is installed*
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"jinni: bring your project into context": {
"jinni": {
"command": "uvx",
"args": [
"jinni-server",
"[OPTIONS]"
]
}
}
}
}
McpServers
{
"jinni": {
"command": "uvx",
"args": [
"jinni-server",
"[OPTIONS]"
]
}
}
<a href="https://glama.ai/mcp/servers/@smat-dev/jinni">
</a>
Jinni is a tool to efficiently provide Large Language Models the context of your projects. It gives a consolidated view of relevant project files, overcoming the limitations and inefficiencies of reading files one by one. Each file's content is preceded by a simple header indicating its path:
path=src/app.py
print("hello")
``
The philosophy behind this tool is that LLM context windows are large, models are smart, and directly seeing your project best equips the model to help with anything you throw at it.
There is an MCP (Model Context Protocol) server for integration with AI tools and a command-line utility (CLI) for manual use that copies project context to the clipboard ready to paste wherever you need it.
These tools are opinionated about what counts as relevant project context to best work out of the box in most use cases, automatically excluding:
Binary files
Dotfiles and hidden directories
* Common naming conventions for logs, build directories, tempfiles, etc
Inclusions/exclusions are customizable with complete granularity if required using
.contextfiles – this works like .gitignore except defining inclusions. .gitignore files themselves are also respected automatically, but any rules in .contextfiles` take priority.
The MCP server can provide as much or as little of the project as desired. By default the scope is the whole project, but the model can ask for specific modules / matching patterns / etc.
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.



