Skip to main content
Glama
deenesjakoruzh
lex-tools

@lex-tools/codebase-context-dumper

Official
by lex-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

代码库上下文转储器 MCP 服务器

npm 版本许可证：Apache-2.0

模型上下文协议 (MCP) 服务器旨在轻松地将您的代码库上下文转储到大型语言模型 (LLM) 中。

为什么要使用这个？

LLM 中的大型上下文窗口功能强大，但从大型代码库中手动选择和格式化文件非常繁琐。此工具通过以下方式自动化此过程：

  • 递归扫描您的项目目录。

  • 包括指定目录树中未被.gitignore规则排除的文本文件。

  • 自动跳过二进制文件。

  • 将内容与清晰的文件路径标记连接起来。

  • 支持分块来处理大于 LLM 上下文窗口的代码库。

  • 与 MCP 兼容客户端无缝集成。

Related MCP server: code-index-mcp

用法（推荐：npx）

使用此工具的最简单方法是通过npx ，它可以运行最新版本而无需本地安装。

配置您的 MCP 客户端（例如，Claude Desktop、VS Code 扩展）以使用以下命令：

{
  "mcpServers": {
    "codebase-context-dumper": {
      "command": "npx",
      "args": [
        "-y",
        "@lex-tools/codebase-context-dumper"
      ]
    }
  }
}

然后，MCP 客户端将能够调用该服务器提供的dump_codebase_context工具。

功能和工具详细信息

工具： dump_codebase_context

以递归方式从指定目录读取文本文件，遵循.gitignore规则并跳过二进制文件。将内容与文件路径的页眉/页脚连接起来。支持对大型代码库的输出进行分块。

功能：

  • 扫描base_path中提供的目录。

  • 尊重所有级别的.gitignore文件（包括嵌套文件和默认的.git ）。

  • 检测并跳过二进制文件。

  • 读取每个有效文本文件的内容。

  • 在每个文件的内容前添加一个标题（ --- START: relative/path/to/file --- ）并添加一个页脚（ --- END: relative/path/to/file --- ）。

  • 将所有处理过的文件内容连接成一个字符串。

输入参数：

  • base_path （字符串，必需）：要扫描的项目目录的绝对路径。

  • num_chunks （整数，可选，默认值：1）：将输出划分成的块的总数。必须 >= 1。

  • chunk_index （整数，可选，默认值：1）：要返回的块的从 1 开始的索引。要求num_chunks > 1且chunk_index <= num_chunks 。

输出：返回连接后的（可能分块的）文本内容。

本地安装和使用（高级）

如果您希望运行本地版本（例如，用于开发）：

  1. 克隆存储库：

    git clone git@github.com:lex-tools/codebase-context-dumper.git
cd codebase-context-dumper

  2. 安装依赖项：

    npm install

  3. 构建服务器：

    npm run build

  4. 配置您的 MCP 客户端以指向本地构建输出：

    {
  "mcpServers": {
    "codebase-context-dumper": {
      "command": "/path/to/your/local/codebase-context-dumper/build/index.js" // Adjust path
    }
  }
}

贡献

欢迎贡献！有关开发、调试和发布新版本的详细信息，请参阅CONTRIBUTING.md 。

执照

本项目遵循 Apache License 2.0 许可协议。详情请参阅LICENSE文件。

Available Tools

1 tool
dump_codebase_contextA

Recursively reads text files from a specified directory, respecting .gitignore rules and skipping binary files. Concatenates content with file path headers/footers. Supports chunking the output for large codebases.

ParametersJSON Schema
NameRequiredDescriptionDefault
base_pathYesThe absolute path to the project directory to scan.
num_chunksNoOptional total number of chunks to divide the output into (default: 1).
chunk_indexNoOptional 1-based index of the chunk to return (default: 1). Requires num_chunks > 1.

TDQS

A4/5.0
Behavior4/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 effectively describes key operational traits: recursive file reading, .gitignore respect, binary file skipping, output formatting with headers/footers, and chunking for large outputs. However, it doesn't mention potential limitations like file size constraints, permission requirements, or error handling, leaving some gaps.

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

Conciseness5/5

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

The description is highly concise and well-structured in two sentences: the first covers core functionality and constraints, the second addresses scalability. Every phrase adds value (e.g., 'respecting .gitignore rules', 'skipping binary files', 'chunking the output'), with no wasted words or redundancy.

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

Completeness4/5

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

Given the tool's moderate complexity (recursive file operations, chunking) and lack of annotations/output schema, the description does a good job covering core behavior and constraints. It explains what the tool does, key features, and output handling, but omits details like return format, error scenarios, or performance implications, which would enhance completeness for an agent.

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 100%, so the input schema already fully documents all three parameters (base_path, num_chunks, chunk_index). The description adds no additional parameter-specific information beyond what's in the schema, such as examples or edge cases. The baseline score of 3 reflects adequate but minimal value addition from the description.

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

Purpose5/5

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

The description clearly states the specific action ('recursively reads text files', 'concatenates content with file path headers/footers') and resource ('from a specified directory'), including key behavioral details like respecting .gitignore rules and skipping binary files. With no sibling tools, it fully defines the tool's unique purpose without redundancy.

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

Usage Guidelines3/5

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

The description implies usage for scanning codebases ('large codebases') and mentions chunking for scalability, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. Since there are no sibling tools, the lack of comparative guidance is less critical, but still leaves usage context somewhat open-ended.

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.

  1. 1 tool update
    • First observeddump_codebase_context
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool has a single, clearly defined purpose.

Naming Consistency5/5

A single tool inherently has perfect naming consistency, as there are no other tools to compare it against for patterns or conventions.

Tool Count2/5

One tool is too few for most practical server purposes, as it severely limits functionality and interaction. While the tool is well-described, a single tool feels thin and incomplete for a codebase context server.

Completeness2/5

The server's purpose appears to be codebase context management, but with only a dump tool, there are significant gaps. Missing operations like search, filter, update, or delete context make the surface incomplete and likely insufficient for agent workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches