The MCP Text Editor Server provides robust, line-based text file editing and manipulation optimized for LLM tools and collaborative workflows with concurrency control.
Read text files: Retrieve specific line ranges from multiple files
Create text files: Create new text files with specified content
Append to files: Add content to existing files
Delete content: Remove specific line ranges from files
Insert content: Insert text before or after specific lines
Patch files: Apply multiple line-based edits
Concurrency management: Uses SHA-256 hashes to detect and handle conflicts
Partial file access: Efficiently retrieve or modify specific line ranges
Multi-file operations: Perform operations on multiple files in a single request
Encoding support: Supports various text encodings (utf-8, shift_jis, latin1)
Security features: Includes file path validation
Integration for code coverage reporting, as indicated by the codecov badge in the README.
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., "@mcp-text-editor show lines 15-30 from config.yaml"
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 line-oriented text file editing capabilities through a standardized API. Optimized for LLM tools with efficient partial file access to minimize token usage.
To use this editor with Claude.app, add the following configuration to your prompt:
code ~/Library/Application\ Support/Claude/claude_desktop_config.json{
"mcpServers": {
"text-editor": {
"command": "uvx",
"args": [
"mcp-text-editor"
]
}
}
}Related MCP server: RBT Document Editor
MCP Text Editor Server is designed to facilitate safe and efficient line-based text file operations in a client-server architecture. It implements the Model Context Protocol, ensuring reliable file editing with robust conflict detection and resolution. The line-oriented approach makes it ideal for applications requiring synchronized file access, such as collaborative editing tools, automated text processing systems, or any scenario where multiple processes need to modify text files safely. The partial file access capability is particularly valuable for LLM-based tools, as it helps reduce token consumption by loading only the necessary portions of files.
Line-based editing operations
Token-efficient partial file access with line-range specifications
Optimized for LLM tool integration
Safe concurrent editing with hash-based validation
Atomic multi-file operations
Robust error handling with custom error types
Comprehensive encoding support (utf-8, shift_jis, latin1, etc.)
Line-oriented text file editing and reading
Smart partial file access to minimize token usage in LLM applications
Get text file contents with line range specification
Read multiple ranges from multiple files in a single operation
Line-based patch application with correct handling of line number shifts
Edit text file contents with conflict detection
Flexible character encoding support (utf-8, shift_jis, latin1, etc.)
Support for multiple file operations
Proper handling of concurrent edits with hash-based validation
Memory-efficient processing of large files
Python 3.11 or higher
POSIX-compliant operating system (Linux, macOS, etc.) or Windows
Sufficient disk space for text file operations
File system permissions for read/write operations
Install Python 3.11+
pyenv install 3.11.6
pyenv local 3.11.6Install uv (recommended) or pip
curl -LsSf https://astral.sh/uv/install.sh | shCreate virtual environment and install dependencies
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e ".[dev]"Python 3.13+
POSIX-compliant operating system (Linux, macOS, etc.) or Windows
File system permissions for read/write operations
uvx mcp-text-editorTo install Text Editor Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install mcp-text-editor --client claudeInstall Python 3.13+
pyenv install 3.13.0
pyenv local 3.13.0Install uv (recommended) or pip
curl -LsSf https://astral.sh/uv/install.sh | shCreate virtual environment and install dependencies
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e ".[dev]"Start the server:
python -m mcp_text_editorThe server provides several tools for text file manipulation:
Get the contents of one or more text files with line range specification.
Single Range Request:
{
"file_path": "path/to/file.txt",
"line_start": 1,
"line_end": 10,
"encoding": "utf-8" // Optional, defaults to utf-8
}Multiple Ranges Request:
{
"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}
]
}
]
}Parameters:
file_path: Path to the text file
line_start/start: Line number to start from (1-based)
line_end/end: Line number to end at (inclusive, null for end of file)
encoding: File encoding (default: "utf-8"). Specify the encoding of the text file (e.g., "shift_jis", "latin1")
Single Range Response:
{
"contents": "File contents",
"line_start": 1,
"line_end": 10,
"hash": "sha256-hash-of-contents",
"file_lines": 50,
"file_size": 1024
}Multiple Ranges Response:
{
"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
}
]
}Apply patches to text files with robust error handling and conflict detection. Supports editing multiple files in a single operation.
Request Format:
{
"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"
}
]
}
]
}Important Notes:
Always get the current hash and range_hash using get_text_file_contents before editing
Patches are applied from bottom to top to handle line number shifts correctly
Patches must not overlap within the same file
Line numbers are 1-based
end: null can be used to append content to the end of file
File encoding must match the encoding used in get_text_file_contents
Success Response:
{
"file1.txt": {
"result": "ok",
"hash": "sha256-hash-of-new-contents"
}
}Error Response with Hints:
{
"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
}
]
})Edit file content:
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"
}
]
}
]
})Handle conflicts:
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
passThe server handles various error cases:
File not found
Permission errors
Hash mismatches (concurrent edit detection)
Invalid patch ranges
Overlapping patches
Encoding errors (when file cannot be decoded with specified encoding)
Line number out of bounds
File Path Validation: The server validates all file paths to prevent directory traversal attacks
Access Control: Proper file system permissions should be set to restrict access to authorized directories
Hash Validation: All file modifications are validated using SHA-256 hashes to prevent race conditions
Input Sanitization: All user inputs are properly sanitized and validated
Error Handling: Sensitive information is not exposed in error messages
Permission Denied
Check file and directory permissions
Ensure the server process has necessary read/write access
Hash Mismatch and Range Hash Errors
The file was modified by another process
Content being replaced has changed
Run get_text_file_contents to get fresh hashes
Encoding Issues
Verify file encoding matches the specified encoding
Use utf-8 for new files
Check for BOM markers in files
Connection Issues
Verify the server is running and accessible
Check network configuration and firewall settings
Performance Issues
Consider using smaller line ranges for large files
Monitor system resources (memory, disk space)
Use appropriate encoding for file type
Clone the repository
Create and activate a Python virtual environment
Install development dependencies: uv pip install -e ".[dev]"
Run tests: make all
Ruff for linting
Black for code formatting
isort for import sorting
mypy for type checking
pytest-cov for test coverage
Tests are located in the tests directory and can be run with 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 -vCurrent test coverage: 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
Fork the repository
Create a feature branch
Make your changes
Run tests and code quality checks
Submit a pull request
This project uses Python type hints throughout the codebase. Please ensure any contributions maintain this.
All error cases should be handled appropriately and return meaningful error messages. The server should never crash due to invalid input or file operations.
New features should include appropriate tests. Try to maintain or improve the current test coverage.
All code should be formatted with Black and pass Ruff linting. Import sorting should be handled by 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?
With no annotations, the description carries full burden. It mentions concurrency control via file_hash and that file must exist, but fails to describe error behavior (e.g., if file not found or hash mismatch), side effects, or reversibility. Partial transparency.
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, front-loaded with the main action, no unnecessary words. Optimal length for quick comprehension.
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?
As a destructive tool with no output schema, the description lacks details on return values, error conditions, and post-deletion state. Given the existence of siblings, it does not fully cover the tool's usage context.
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 parameter descriptions already clarify each field. The description repeats some schema info (file must exist, absolute paths) and adds provenance for file_hash. This adds slight value but not enough to raise above baseline 3.
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?
Clearly states the verb 'Delete' and the resource 'text file', specifying 'content ranges' which distinguishes it from sibling tools like append, create, insert, and patch. The description adds necessary preconditions (file existence, absolute paths, file_hash).
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?
Provides prerequisites (file must exist, paths absolute, file_hash from get_text_file_contents) that help with usage context, but does not explicitly compare with siblings or specify when to use vs. alternatives. Lacks 'when not to use' 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?
With no annotations provided, the description carries full transparency burden. It discloses that returned contents include hashes for concurrency control and line numbers, and explains the purpose of hashes (conflict detection). This adds value beyond a simple 'read' operation.
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 three sentences, front-loaded with the primary purpose. No redundant words, but could be slightly more structured by separating behavioral details from parameter reminders.
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 no output schema, the description informs about return values (contents, hashes, line numbers). It covers the main use case and constraints (absolute paths). Sibling tools are all write operations, so contextual completeness is adequate.
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% with descriptions for all parameters. The description adds minimal new info about parameters, merely reinforcing that file paths must be absolute. It does not elaborate on encoding or range semantics beyond schema.
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 reads text file contents from multiple files and line ranges. It specifies the resource (text files) and action (read), and implicitly distinguishes from sibling tools that write or modify files.
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 indicates when to use the tool (reading file contents) but does not explicitly mention when not to use it or provide alternatives among siblings. It implies usage context but lacks exclusions or comparative guidance.
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. Dates show when Glama detected each change.
v1.0.0append_text_file_contentscreate_text_filedelete_text_file_contentsget_text_file_contentsinsert_text_file_contentspatch_text_file_contentsEach tool targets a distinct file operation: create, read, append, insert, delete, and patch. The descriptions clarify the differences, with no overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., create_text_file, get_text_file_contents, making them predictable.
Six tools cover the essential operations for a text file editor (CRUD plus advanced insert and patch). The count is well-scoped for the domain.
The tool surface covers create, read, append, insert, delete, and patch. Missing a direct replace or update operation, but patch can address many update needs. Minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
A real timeline video editor for AI agents: journaled edits, FFmpeg/MLT rendering, exports
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tumf/mcp-text-editor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
