Allows packing remote GitHub repositories into AI-friendly files, enabling estimation of token counts and retrieval of consolidated codebase contents.
Supports packing repository contents into Markdown-formatted files, providing a structured and readable way for AI systems to consume entire codebases.
Supports packing repository contents into XML-formatted files, offering a machine-readable structure that includes file summaries and metadata.
Click on "Install 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., "@Repomix MCP Server pack https://github.com/expressjs/express using xml style and compression"
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.
A Model Context Protocol (MCP) server that provides access to the repomix tool for packing repositories into AI-friendly files.
Input paths: The server restricts file access to the directory from which it was started. Any attempts to access files outside this directory (like /etc/) will be denied.
Output files: All output is written to the system's temporary directory and automatically cleaned up after the contents are returned.
Remote URLs: Remote repository URLs are still allowed for processing.
Related MCP server: MCP-Repo2LLM
npm install
npm run buildclaude mcp add --scope user repomix node /path/to/repomix-mcp/dist/index.jsAdd this server to your MCP client configuration in your claude_desktop_config.json:
{
"mcpServers": {
"repomix": {
"command": "node",
"args": ["/path/to/repomix-mcp/dist/index.js"]
}
}
}Both tools accept the same parameters:
Parameter | Type | Required | Description | Examples |
| string | No | Directory path to pack |
|
| enum | No | Output format style |
|
| boolean | No | Compress output to reduce token count |
|
| string | No | Files to include (glob pattern) |
|
| string | No | Files to exclude (glob pattern) |
|
| string | No | Remote repository URL to process |
|
Estimate the size of repomix output without retrieving the content. Use this first to check if the output will fit in your context window.
Returns:
File size in KB/MB
Estimated token count (~4 characters per token)
Whether compression is enabled
Repomix output size estimate:
- Size: 5.27 KB (0.01 MB)
- Estimated tokens: ~1,349
- Compression: disabled
Use the repomix tool with these same parameters to retrieve the actual content.Pack a repository into a single, AI-friendly file. Returns the contents of the generated file.
Best Practice: Always use repomix-estimate first to check the output size, then use repomix with appropriate parameters (especially compress=true for large repos).
Example usage in Claude:
First check size: use repomix-estimate tool
If size is reasonable: use repomix tool
If too large, try with compression: use repomix-estimate tool with compress=true
Then retrieve: use repomix tool with compress=true
Workflow: Always estimate first, then retrieve only if the size fits your needs.
This file is a merged representation of a subset of the codebase, containing specifically included files, combined into a single document by Repomix.
<file_summary>
This section contains a summary of this file.
<purpose>
This file contains a packed representation of the entire repository's contents.
It is designed to be easily consumable by AI systems for analysis, code review,
or other automated processes.
</purpose>
<file_format>
The content is organized as follows:
1. This summary section
2. Repository informationPack repository files into a single AI-friendly file. Use at session start to load context efficiently. IMPORTANT: Always use the "include" parameter to filter only relevant files (e.g., ".md,.ts,.js" for a TypeScript project, or ".md,*.py" for Python). Start with root-level *.md files and source files in the language being worked on. Always use repomix-estimate first to check size.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the directory to pack | |
| style | No | Output format style | |
| compress | No | Compress output to reduce token count | |
| include | No | Files to include (glob pattern). Examples: "*.md,*.ts,*.js" for TypeScript projects, "*.md,*.py" for Python, "*.md,*.go" for Go. Always specify to avoid large outputs! | |
| ignore | No | Files to exclude (glob pattern). Use to filter out test files, build outputs, etc. Example: "*test*,*spec*,dist/**,build/**" | |
| remote | No | Remote repository URL to process |
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 effectively communicates that this tool can process both local directories and remote repositories, emphasizes the importance of filtering to avoid large outputs, and provides practical guidance on file selection patterns. However, it doesn't mention potential rate limits, authentication requirements, or error handling scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with purpose first, then usage context, then critical parameter guidance. Each sentence serves a distinct purpose, though the final sentence about repomix-estimate could be integrated more smoothly. Overall, it's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description does a good job covering usage context, sibling relationships, and critical parameter guidance. It explains the tool's role in a workflow and provides practical filtering advice. The main gap is lack of output format explanation, which would be helpful since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds some value by providing concrete examples for the 'include' parameter and emphasizing its importance, but doesn't significantly enhance understanding beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Pack repository files into a single AI-friendly file') and resource ('repository files'), distinguishing it from its sibling repomix-estimate by emphasizing this is the actual packing tool rather than a size estimation tool. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use at session start to load context efficiently') and when to use an alternative ('Always use repomix-estimate first to check size'). It also specifies important prerequisites and sequencing, making it clear how to integrate this tool into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate repomix output size before retrieval. ALWAYS use this first with the "include" parameter to filter only relevant files (e.g., ".md,.ts,.js" for TypeScript, ".md,*.py" for Python). If estimated tokens are reasonable (<50K), proceed with repomix using the same filters. This helps load the entire relevant context efficiently.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the directory to pack | |
| style | No | Output format style | |
| compress | No | Compress output to reduce token count | |
| include | No | Files to include (glob pattern). Examples: "*.md,*.ts,*.js" for TypeScript projects, "*.md,*.py" for Python, "*.md,*.go" for Go. Always specify to avoid large outputs! | |
| ignore | No | Files to exclude (glob pattern). Use to filter out test files, build outputs, etc. Example: "*test*,*spec*,dist/**,build/**" | |
| remote | No | Remote repository URL to process |
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 effectively describes the tool's purpose (estimation before retrieval), provides practical guidance on parameter usage, and mentions the token threshold (<50K) for decision-making. However, it doesn't cover potential errors, rate limits, or authentication needs, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each serve a clear purpose: stating the tool's purpose, providing usage instructions, and explaining the workflow. It's front-loaded with the core purpose and avoids unnecessary repetition. However, the second sentence is somewhat long and could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description provides good contextual coverage. It explains the purpose, usage workflow, and parameter importance. However, it doesn't describe what the estimation output looks like (token count, file count, etc.), which would be helpful since there's no output schema. The guidance on when to use the sibling tool partially compensates for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds value by emphasizing the importance of the 'include' parameter with specific examples and warnings ('Always specify to avoid large outputs!'), but doesn't provide additional semantic context beyond what's in the schema for other parameters. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate repomix output size before retrieval.' It specifies the verb ('estimate'), resource ('repomix output size'), and distinguishes it from its sibling 'repomix' by emphasizing it's for estimation before actual retrieval. This provides specific differentiation from the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'ALWAYS use this first with the "include" parameter to filter only relevant files.' It also specifies when to proceed with the sibling tool: 'If estimated tokens are reasonable (<50K), proceed with repomix using the same filters.' This offers clear alternatives and conditions for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
repomixrepomix-estimateThe two tools have clearly distinct purposes: repomix-estimate is for estimating output size before retrieval, while repomix is for actually packing repository files. There is no overlap or ambiguity between them, as one is a preparatory check and the other is the main action.
Both tools follow a consistent naming pattern with the 'repomix' prefix and descriptive suffixes ('-estimate' vs. no suffix for the base tool). This creates a clear hierarchy and makes the relationship between the tools immediately apparent.
With only 2 tools, the server feels thin for a repository management domain. While the tools cover a specific workflow (estimation and packing), typical repository operations like listing, searching, or updating files are missing, making the scope narrow and potentially limiting for agents.
The server is severely incomplete for repository management. It only supports packing and estimating repository files, with no tools for creating, reading, updating, or deleting repository content, nor for common operations like cloning, branching, or committing. This will cause significant agent failures in broader repository tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for building and testing AI agents with multi-model experimentation and insights.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Aeolun/repomix-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
