Repomix MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| repomixA | Pack 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. |
| repomix-estimateA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The 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.