표준화된 API를 통해 줄 단위 텍스트 파일 편집 기능을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 효율적인 부분 파일 접근을 통해 토큰 사용량을 최소화하는 LLM 도구에 최적화되어 있습니다.
Claude.app과 함께 이 편집기를 사용하려면 프롬프트에 다음 구성을 추가하세요.
지엑스피1
{
"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 텍스트 편집기 서버는 클라이언트-서버 아키텍처에서 안전하고 효율적인 라인 기반 텍스트 파일 작업을 지원하도록 설계되었습니다. 모델 컨텍스트 프로토콜(Model Context Protocol)을 구현하여 강력한 충돌 감지 및 해결 기능을 통해 안정적인 파일 편집을 보장합니다. 라인 기반 접근 방식은 협업 편집 도구, 자동 텍스트 처리 시스템 또는 여러 프로세스가 텍스트 파일을 안전하게 수정해야 하는 시나리오와 같이 동기화된 파일 액세스가 필요한 애플리케이션에 이상적입니다. 부분 파일 액세스 기능은 파일의 필요한 부분만 로드하여 토큰 소모를 줄이는 데 도움이 되므로 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.6uv(권장) 또는 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]"파이썬 3.13+
POSIX 호환 운영 체제(Linux, macOS 등) 또는 Windows
읽기/쓰기 작업에 대한 파일 시스템 권한
uvx mcp-text-editorSmithery를 통해 Claude Desktop용 Text Editor Server를 자동으로 설치하려면:
npx -y @smithery/cli install mcp-text-editor --client claudePython 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_editordocker로 서버를 시작합니다.
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를 사용하여 현재 해시와 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 configurationMIT
저장소를 포크하세요
기능 브랜치 생성
변경 사항을 만드세요
테스트 실행 및 코드 품질 검사
풀 리퀘스트 제출
이 프로젝트는 코드베이스 전체에서 Python 타입 힌트를 사용합니다. 모든 기여는 이 힌트를 유지해야 합니다.
모든 오류 사례는 적절하게 처리되어야 하며, 의미 있는 오류 메시지를 반환해야 합니다. 서버는 잘못된 입력이나 파일 작업으로 인해 충돌해서는 안 됩니다.
새로운 기능에는 적절한 테스트가 포함되어야 합니다. 현재 테스트 범위를 유지하거나 개선해 보세요.
모든 코드는 Black으로 포맷하고 Ruff 린팅을 통과해야 합니다. 가져오기 정렬은 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.
