模型上下文协议 (MCP) 服务器，通过标准化 API 提供面向行的文本文件编辑功能。针对 LLM 工具进行了优化，具有高效的部分文件访问功能，可最大限度地减少令牌使用。
要将此编辑器与 Claude.app 一起使用，请将以下配置添加到提示中：
code ~/Library/Application\ Support/Claude/claude_desktop_config.json{
"mcpServers": {
"text-editor": {
"command": "uvx",
"args": [
"mcp-text-editor"
]
}
}
}或者使用 docker：
{
"mcpServers": {
"text-editor": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--mount",
"type=bind,src=/some/path/src,dst=/some/path/dst",
"mcp/text-editor"
]
}
}
}Related MCP server: RBT Document Editor
MCP 文本编辑器服务器旨在促进客户端-服务器架构中安全高效的基于行的文本文件操作。它实现了模型上下文协议 (MLP)，通过强大的冲突检测和解决功能确保可靠的文件编辑。这种面向行的方法使其成为需要同步文件访问的应用程序的理想选择，例如协作编辑工具、自动文本处理系统，或任何需要多个进程安全修改文本文件的场景。部分文件访问功能对于基于 LLM 的工具尤其有用，因为它可以通过仅加载文件的必要部分来减少令牌消耗。
基于行的编辑操作
使用行范围规范的高效令牌部分文件访问
针对 LLM 工具集成进行了优化
使用基于哈希的验证进行安全并发编辑
原子多文件操作
使用自定义错误类型进行强大的错误处理
全面的编码支持（utf-8、shift_jis、latin1等）
面向行的文本文件编辑和阅读
智能部分文件访问，最大限度地减少 LLM 应用程序中的令牌使用
获取具有行范围规范的文本文件内容
通过一次操作从多个文件读取多个范围
基于行的补丁应用，正确处理行号偏移
使用冲突检测编辑文本文件内容
灵活的字符编码支持（utf-8、shift_jis、latin1等）
支持多文件操作
使用基于哈希的验证正确处理并发编辑
高效内存处理大文件
Python 3.11 或更高版本
符合 POSIX 标准的操作系统（Linux、macOS 等）或 Windows
足够的磁盘空间用于文本文件操作
读/写操作的文件系统权限
安装 Python 3.11+
pyenv install 3.11.6
pyenv local 3.11.6安装 uv（推荐）或 pip
curl -LsSf https://astral.sh/uv/install.sh | sh创建虚拟环境并安装依赖项
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e ".[dev]"Python 3.13+
符合 POSIX 标准的操作系统（Linux、macOS 等）或 Windows
读/写操作的文件系统权限
uvx mcp-text-editor要通过Smithery自动安装 Claude Desktop 的文本编辑器服务器：
npx -y @smithery/cli install mcp-text-editor --client claude安装 Python 3.13+
pyenv install 3.13.0
pyenv local 3.13.0docker build --network=host -t mcp/text-editor .安装 uv（推荐）或 pip
curl -LsSf https://astral.sh/uv/install.sh | sh创建虚拟环境并安装依赖项
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e ".[dev]"启动服务器：
python -m mcp_text_editor使用docker启动服务器：
docker run -i --rm --mount "type=bind,src=/some/path/src,dst=/some/path/dst" mcp/text-editor与检查员：
npx @modelcontextprotocol/inspector docker run -i --rm --mount "type=bind,src=/some/path/src,dst=/some/path/dst" mcp/text-editor服务器提供了几个用于文本文件操作的工具：
获取具有行范围规范的一个或多个文本文件的内容。
单一范围请求：
{
"file_path": "path/to/file.txt",
"line_start": 1,
"line_end": 10,
"encoding": "utf-8" // Optional, defaults to utf-8
}多个范围请求：
{
"files": [
{
"file_path": "file1.txt",
"ranges": [
{"start": 1, "end": 10},
{"start": 20, "end": 30}
],
"encoding": "shift_jis" // Optional, defaults to utf-8
},
{
"file_path": "file2.txt",
"ranges": [
{"start": 5, "end": 15}
]
}
]
}参数：
file_path ：文本文件的路径
line_start / start ：开始的行号（从 1 开始）
line_end / end ：结束的行号（含，文件末尾为 null）
encoding ：文件编码（默认值："utf-8"）。指定文本文件的编码（例如，"shift_jis"、"latin1"）
单范围响应：
{
"contents": "File contents",
"line_start": 1,
"line_end": 10,
"hash": "sha256-hash-of-contents",
"file_lines": 50,
"file_size": 1024
}多范围响应：
{
"file1.txt": [
{
"content": "Lines 1-10 content",
"start": 1,
"end": 10,
"hash": "sha256-hash-1",
"total_lines": 50,
"content_size": 512
},
{
"content": "Lines 20-30 content",
"start": 20,
"end": 30,
"hash": "sha256-hash-2",
"total_lines": 50,
"content_size": 512
}
],
"file2.txt": [
{
"content": "Lines 5-15 content",
"start": 5,
"end": 15,
"hash": "sha256-hash-3",
"total_lines": 30,
"content_size": 256
}
]
}使用强大的错误处理和冲突检测功能，将补丁应用于文本文件。支持单次操作编辑多个文件。
请求格式：
{
"files": [
{
"file_path": "file1.txt",
"hash": "sha256-hash-from-get-contents",
"encoding": "utf-8", // Optional, defaults to utf-8
"patches": [
{
"start": 5,
"end": 8,
"range_hash": "sha256-hash-of-content-being-replaced",
"contents": "New content for lines 5-8\n"
},
{
"start": 15,
"end": null, // null means end of file
"range_hash": "sha256-hash-of-content-being-replaced",
"contents": "Content to append\n"
}
]
}
]
}重要提示：
编辑前务必使用 get_text_file_contents 获取当前 hash 和 range_hash
从下到上应用补丁，以正确处理行号偏移
补丁不得在同一个文件中重叠
行号从 1 开始
end: null可用于将内容附加到文件末尾
文件编码必须与 get_text_file_contents 中使用的编码匹配
成功响应：
{
"file1.txt": {
"result": "ok",
"hash": "sha256-hash-of-new-contents"
}
}带有提示的错误响应：
{
"file1.txt": {
"result": "error",
"reason": "Content hash mismatch",
"suggestion": "get", // Suggests using get_text_file_contents
"hint": "Please run get_text_file_contents first to get current content and hashes"
}
}"result": "error",
"reason": "Content hash mismatch - file was modified",
"hash": "current-hash",
"content": "Current file content"} }
### Common Usage Pattern
1. Get current content and hash:
```python
contents = await get_text_file_contents({
"files": [
{
"file_path": "file.txt",
"ranges": [{"start": 1, "end": null}] # Read entire file
}
]
})编辑文件内容：
result = await edit_text_file_contents({
"files": [
{
"path": "file.txt",
"hash": contents["file.txt"][0]["hash"],
"encoding": "utf-8", # Optional, defaults to "utf-8"
"patches": [
{
"line_start": 5,
"line_end": 8,
"contents": "New content\n"
}
]
}
]
})处理冲突：
if result["file.txt"]["result"] == "error":
if "hash mismatch" in result["file.txt"]["reason"]:
# File was modified by another process
# Get new content and retry
pass服务器处理各种错误情况：
未找到文件
权限错误
哈希不匹配（并发编辑检测）
无效的补丁范围
重叠斑块
编码错误（当文件无法使用指定的编码进行解码时）
行号超出范围
文件路径验证：服务器验证所有文件路径以防止目录遍历攻击
访问控制：应设置适当的文件系统权限以限制对授权目录的访问
哈希验证：所有文件修改均使用 SHA-256 哈希进行验证，以防止竞争条件
输入清理：所有用户输入都经过适当的清理和验证
错误处理：错误消息中不会暴露敏感信息
没有权限
检查文件和目录权限
确保服务器进程具有必要的读/写访问权限
哈希不匹配和范围哈希错误
文件已被另一个进程修改
被替换的内容已更改
运行 get_text_file_contents 来获取最新的哈希值
编码问题
验证文件编码是否符合指定的编码
对新文件使用 utf-8
检查文件中的 BOM 标记
连接问题
验证服务器正在运行且可访问
检查网络配置和防火墙设置
性能问题
考虑对大文件使用较小的行范围
监控系统资源（内存、磁盘空间）
对文件类型使用适当的编码
克隆存储库
创建并激活 Python 虚拟环境
安装开发依赖项： uv pip install -e ".[dev]"
运行测试： make all
用于除毛的褶边
黑色表示代码格式
isort 用于导入排序
mypy 用于类型检查
pytest-cov 用于测试覆盖率
测试位于tests目录中，可以使用 pytest 运行：
# Run all tests
pytest
# Run tests with coverage report
pytest --cov=mcp_text_editor --cov-report=term-missing
# Run specific test file
pytest tests/test_text_editor.py -v当前测试覆盖率：90%
mcp-text-editor/
├── mcp_text_editor/
│ ├── __init__.py
│ ├── __main__.py # Entry point
│ ├── models.py # Data models
│ ├── server.py # MCP Server implementation
│ ├── service.py # Core service logic
│ └── text_editor.py # Text editor functionality
├── tests/ # Test files
└── pyproject.toml # Project configuration麻省理工学院
分叉存储库
创建功能分支
进行更改
运行测试和代码质量检查
提交拉取请求
该项目在整个代码库中使用了 Python 类型提示。请确保所有贡献都维护这一点。
所有错误情况都应得到适当处理并返回有意义的错误消息。服务器不应因无效输入或文件操作而崩溃。
新功能应该包含适当的测试。尽量维持或提升当前的测试覆盖率。
所有代码均应使用 Black 格式化并通过 Ruff linting。导入排序应使用 isort 处理。
Append content to an existing text file. The file must exist.
| Name | Required | Description | Default |
|---|---|---|---|
| contents | Yes | Content to append to the file | |
| encoding | No | Text encoding (default: 'utf-8') | utf-8 |
| file_hash | Yes | Hash of the file contents for concurrency control. it should be matched with the file_hash when get_text_file_contents is called. | |
| file_path | Yes | Path to the text file. File path must be absolute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the existence constraint but does not disclose side effects (mutation) or concurrency behavior despite file_hash being required. Some transparency, but gaps remain.
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?
Extremely concise: two sentences with no wasted words. Front-loaded with the action and key constraint.
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 modifies files and has a concurrency mechanism, the description omits details about return values, error conditions (e.g., hash mismatch, file not found), and side effects. Not complete for the complexity.
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?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; the file_hash parameter's role is mentioned in the schema but not elaborated in the description.
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 action ('append') and the resource ('text file'), and distinguishes from siblings like 'create_text_file' and 'insert_text_file_contents'.
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 only states 'The file must exist' but does not provide guidance on when to use this tool versus alternatives like 'create_text_file' or 'insert_text_file_contents'. No explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new text file with given content. The file must not exist already.
| Name | Required | Description | Default |
|---|---|---|---|
| contents | Yes | Content to write to the file | |
| encoding | No | Text encoding (default: 'utf-8') | utf-8 |
| file_path | Yes | Path to the text file. File path must be absolute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It discloses the creation action and file existence precondition, but lacks details on error handling (e.g., what happens if file exists), encoding usage, or side effects. It is adequate but not comprehensive.
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?
One short sentence plus a condition. No unnecessary words. The essential information is front-loaded, making it easy to parse.
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?
For a tool with 3 parameters, no output schema, and no annotations, the description is minimal. It covers core purpose and a key precondition but omits details like error handling, encoding behavior, and any side effects (e.g., directory creation). It is adequate but could be more helpful.
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?
Schema coverage is 100%, and the description adds minimal value beyond schema. It mentions 'given content' for contents (schema already says 'Content to write') and restates 'File path must be absolute' (already in schema). Encoding is not mentioned in description.
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?
Description clearly states 'Create a new text file with given content', which is a specific verb and resource. It also adds the precondition that the file must not already exist, distinguishing it from siblings like append or patch.
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 explicitly says 'The file must not exist already', guiding when to use (for new files) and implying when not to use (file already exists). However, it does not explicitly name alternatives or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specified content ranges from a text file. The file must exist. File paths must be absolute. You need to provide the file_hash comes from get_text_file_contents.
| Name | Required | Description | Default |
|---|---|---|---|
| ranges | Yes | List of line ranges to delete | |
| encoding | No | Text encoding (default: 'utf-8') | utf-8 |
| file_hash | Yes | Hash of the file contents for concurrency control. it should be matched with the file_hash when get_text_file_contents is called. | |
| file_path | Yes | Path to the text file. File path must be absolute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the file must exist, paths must be absolute, and that a hash is required for concurrency control. However, it doesn't disclose what happens if the hash mismatches, whether the operation is destructive/reversible, or what the return value is. The destructive nature is implied by 'Delete' but not elaborated.
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 compact and front-loaded with the core action. The three sentences each add necessary context: what it does, the file existence/path requirement, and the hash prerequisite. It could be slightly more structured, but it's efficient and free of fluff.
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?
For a destructive mutation tool with no annotations and no output schema, the description should disclose more about failure modes, hash mismatch behavior, and whether the operation is reversible. It covers the key prerequisites but leaves the agent guessing about what happens on success or failure. The sibling tools and schema provide some context, but the description itself is incomplete for a destructive operation.
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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the crucial context that file_hash comes from get_text_file_contents and that range_hash should match the one from get_text_file_contents. This adds value beyond the schema, but the schema already covers the basics, so a baseline 3 is appropriate.
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 states a specific verb ('Delete'), a specific resource ('specified content ranges from a text file'), and the key precondition that the file must exist. It clearly distinguishes itself from siblings like append_text_file_contents, insert_text_file_contents, and patch_text_file_contents by focusing on deletion of ranges.
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 gives clear context: the file must exist, paths must be absolute, and the file_hash must come from get_text_file_contents. It doesn't explicitly say when to use this tool versus alternatives, but the deletion-specific wording and the mention of get_text_file_contents as a prerequisite provide adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read text file contents from multiple files and line ranges. Returns file contents with hashes for concurrency control and line numbers for reference. The hashes are used to detect conflicts when editing the files. File paths must be absolute.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | List of files and their line ranges to read | |
| encoding | No | Text encoding (default: 'utf-8') | utf-8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool is read-only, returns hashes for concurrency control, includes line numbers for reference, and requires absolute paths. It does not cover failure modes or size limits, but the core behavioral traits are clearly explained.
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?
Three concise sentences, each earning its place: the first defines the operation, the second explains the return payload, and the third explains why hashes matter. There is no redundant phrasing or filler.
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?
The description, combined with the complete input schema, gives an agent enough to invoke the tool correctly. It describes the key return elements (hashes, line numbers) despite no output schema. Minor gaps around error behavior and exact return formatting keep it from a 5.
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?
Schema description coverage is 100%, so the schema already documents every parameter, including the absolute path requirement and range semantics. The description adds no new parameter-level meaning beyond restating that paths must be absolute; the baseline 3 is appropriate.
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 opens with the specific verb 'Read' and resource 'text file contents', and immediately clarifies it handles multiple files and line ranges. This clearly distinguishes it from sibling editing/writing tools like append_text_file_contents and patch_text_file_contents.
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 clearly indicates this is for reading files before editing, since it returns hashes 'used to detect conflicts when editing the files.' It provides clear usage context and indirectly positions itself as the read counterpart to the editing siblings, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert content before or after a specific line in a text file. Uses hash-based validation for concurrency control. You need to provide the file_hash comes from get_text_file_contents.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Line number after which to insert content (mutually exclusive with 'before') | |
| before | No | Line number before which to insert content (mutually exclusive with 'after') | |
| contents | Yes | Content to insert | |
| encoding | No | Text encoding (default: 'utf-8') | utf-8 |
| file_hash | Yes | Hash of the file contents for concurrency control. it should be matched with the file_hash when get_text_file_contents is called. | |
| file_path | Yes | Path to the text file. File path must be absolute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses hash-based concurrency control and the prerequisite of file_hash. However, it omits error behavior (e.g., out-of-range line, hash mismatch) and the fact that the file is modified in place.
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?
Two concise sentences, front-loaded with the core purpose and followed by an important prerequisite. No wasted words.
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?
The description covers the main action and prerequisite, but lacks information on return value (no output schema) and error cases. For a tool with 6 parameters and no output schema, it is adequate but incomplete.
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?
Schema coverage is 100%, but the description adds value by explaining the concurrency control purpose of file_hash and the prerequisite relationship with get_text_file_contents. This goes beyond the schema's descriptions.
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 inserts content before or after a specific line in a text file, using specific verbs and resources. It distinguishes from siblings like append_text_file_contents and patch_text_file_contents by specifying line-based insertion.
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 implies usage by requiring the file_hash from get_text_file_contents, but does not explicitly state when to use this tool versus alternatives. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply patches to text files with hash-based validation for concurrency control.you need to use get_text_file_contents tool to get the file hash and range hash every time before using this tool. you can use append_text_file_contents tool to append text contents to the file without range hash, start and end. you can use insert_text_file_contents tool to insert text contents to the file without range hash, start and end.
| Name | Required | Description | Default |
|---|---|---|---|
| patches | Yes | List of patches to apply | |
| encoding | No | Text encoding (default: 'utf-8') | utf-8 |
| file_hash | Yes | Hash of the file contents for concurrency control. | |
| file_path | Yes | Path to the text file. File path must be absolute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions concurrency control via hashes but does not disclose error behavior (e.g., hash mismatch, partial patches) or permissions required. Could be more transparent about failure modes.
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 a single, dense paragraph with no superfluous words. It front-loads the main purpose and immediately gives prerequisite and alternative usage, making it efficient for agent parsing.
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 has 4 parameters, no output schema, and complex nested patches, the description provides necessary context: prerequisite hash retrieval and alternative tools for simpler edits. Missing details on return value and errors, but sufficient for typical use cases.
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?
Schema description coverage is 100%; each parameter has a description. The tool description adds context about hash usage and the need to fetch them from get_text_file_contents. However, it does not significantly enhance understanding beyond the schema beyond the prerequisite flow.
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 applies patches to text files with hash-based concurrency control. It distinguishes itself from siblings by mentioning that append and insert tools do not require range hashes and start/end parameters.
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?
Explicitly instructs the agent to use get_text_file_contents first to obtain file_hash and range_hash. Also provides alternatives (append, insert) for simpler operations, clearly delimiting when to use this tool and when not to.
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.
v1.2.2delete_text_file_contents2 fields changedInput schema / properties / ranges / items / properties / end / nullableAdded value: +trueInput schema / properties / ranges / items / properties / end / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"get_text_file_contents2 fields changedInput schema / properties / files / items / properties / ranges / items / properties / end / nullableAdded value: +trueInput schema / properties / files / items / properties / ranges / items / properties / end / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"v1.0.0append_text_file_contentscreate_text_filedelete_text_file_contentsget_text_file_contentsinsert_text_file_contentspatch_text_file_contentsScored across 6 tools
Each tool targets a distinct operation: create, read, append, insert, delete range, and patch. However, patch_text_file_contents can be seen as overlapping with insert and delete since patches may subsume those operations, so agents might occasionally hesitate between them.
Most tools follow a verb_text_file_contents pattern, which is clear and consistent. The exception is create_text_file, which drops the _contents suffix and breaks the otherwise uniform convention.
Six tools is a well-scoped set for a text file editor. Each tool covers a necessary primitive operation without redundant or bloated additions.
The server provides create, read, append, insert, delete-range, and patch operations, covering the core editing lifecycle. A whole-file overwrite or file deletion operation is missing, but most workflows can be accomplished with the existing tools.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Read and write your Fresh Jots notes from Claude, Cursor, and any MCP client.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
