The MCP File Editor Server is a comprehensive tool for advanced file operations, enabling reading, writing, searching, and editing of files and directories with robust error handling and comprehensive testing.
File Reading: Read entire files or specific line ranges with optional line number prefixes
Text Replacement: Replace content using regex patterns with support for single or multiple occurrences
Content Management: Delete content between specific lines, insert content at specific positions (before/after lines or at end), and replace entire line blocks
Advanced Multi-Line Editing: Perform multiple line replacements in a single operation with automatic line number adjustment
File & Directory Searching: Search for regex patterns within individual files or across directories, with context lines and include/exclude filters
Directory Operations: List files and subdirectories with size information and recursive support
Quality & Integration: Features robust error handling, path validation, content verification, and 80+ test cases for reliability. Designed for seamless integration with MCP-compatible clients via stdio.
Built on Node.js runtime environment for server execution and JavaScript-based file operations
Distributed and installed via npm package manager, with npm-based dependency management
Implemented in TypeScript providing type-safe file manipulation operations and modern JavaScript features
Uses Vitest testing framework for comprehensive test coverage of all file editing operations
Integrates Zod for schema validation of tool parameters and input validation
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 File Editor Server search for TODO comments in my project's src directory"
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 comprehensive Model Context Protocol (MCP) server that provides advanced file operations for reading, writing, searching, and editing files. This server offers 10 powerful tools for file manipulation with robust error handling and comprehensive test coverage.
read_file - Read file contents with flexible options
Full file reading or specific line ranges
Optional line number prefixes
Support for partial file reading
replace_in_file - Regex-based string replacement
Single or multiple occurrence replacement
Complex regex pattern support
Safe replacement with occurrence limits
delete_from_file - Remove content between line numbers
Line content verification for safety
Single or multi-line deletion
Precise line range targeting
insert_into_file - Insert content at specific positions
Before/after line placement
End-of-file appending
Line content verification
replace_lines_in_file - Replace content between lines
Multi-line content replacement
Line content verification
Flexible content insertion
multireplace_lines_in_file - Multiple line replacements with automatic adjustment
Perform multiple edits in a single operation
Automatic line number adjustment after each edit
Detailed success/failure reporting for each edit
Handles complex line shifting scenarios
search_file - Search within individual files
Regex pattern matching
Context lines (before/after)
Detailed match reporting
list_files - Directory content listing
File and directory enumeration
File size information
Recursive directory support
search_directory - Search across multiple files
Directory-wide regex search
Include/exclude pattern filtering
Recursive subdirectory searching
create_file - Create new files with automatic directory creation
Safe file creation with overwrite protection
Automatic directory structure creation
Comprehensive error handling for file system operations
Robust Error Handling: User-friendly error messages with actionable guidance
Path Validation: Absolute path enforcement with helpful error messages
Content Verification: Line content verification to prevent accidental edits
Comprehensive Testing: 80 test cases covering all functionality
TypeScript Implementation: Full type safety and modern JavaScript features
FastMCP Framework: Built on the FastMCP library for optimal performance
Related MCP server: File System MCP Server
Node.js 16.x or later
npm or yarn package manager
npm installnpm run build"mcpServers": {
"file-edit": {
"command": "npx",
"args": ["mcp-file-editor@latest"]
}
}
node build/index.jsThe server will start and listen for MCP client connections via stdio transport.
This server is designed to work with MCP-compatible clients. The server communicates via stdio and supports the following MCP tools:
// Read a file
const result = await client.callTool({
name: 'read_file',
arguments: {
file_path: '/absolute/path/to/file.txt',
show_line_numbers: true,
start_line: 1,
end_line: 10
}
});
// Search for patterns
const searchResult = await client.callTool({
name: 'search_directory',
arguments: {
directory_path: '/path/to/search',
regexp: 'TODO|FIXME',
recursive: true
}
});
// Multiple line replacements with automatic adjustment
const multiEditResult = await client.callTool({
name: 'multireplace_lines_in_file',
arguments: {
file_path: '/path/to/file.txt',
edits: [
{
line_start: 10,
line_end: 15,
line_start_contents: 'Line 10: Tenth line',
contents: 'REPLACED LINES 10-15\nWith new content'
},
{
line_start: 25,
line_end: 30,
line_start_contents: 'Line 25: Twenty-fifth line',
contents: 'REPLACED LINES 25-30\nWith different content'
}
]
}
});
// Create a new file
const createResult = await client.callTool({
name: 'create_file',
arguments: {
file_path: '/absolute/path/to/new-file.txt',
contents: 'This is the content of the new file.\nIt can span multiple lines.'
}
});Run the comprehensive test suite:
npm testThe test suite includes:
80 total tests across 5 test files
Unit tests for all 10 tools
Error handling validation
Edge case coverage
Integration testing with MCP client
read-file.test.ts - 16 tests for file reading operations
editing-tools.test.ts - 26 tests for file modification tools (including multireplace_lines_in_file)
search-tools.test.ts - 22 tests for search and directory operations
utils.test.ts - 16 tests for utility functions
create_file.test.ts - 7 tests for file creation operations
file_path (string, required): Absolute path to the file
show_line_numbers (boolean, optional): Prefix lines with numbers
start_line (number, optional): Starting line number (1-based)
end_line (number, optional): Ending line number (1-based)
full (boolean, optional): Read entire file (mutually exclusive with line ranges)
file_path (string, required): Absolute path to the file
regex_source (string, required): Regular expression pattern
target (string, required): Replacement string
multiple (boolean, optional): Allow multiple replacements
file_path (string, required): Absolute path to the file
line_start (number, required): Starting line number
line_end (number, required): Ending line number
line_start_contents (string, required): Expected content of starting line
file_path (string, required): Absolute path to the file
line_number (number, required): Target line number (0 for end)
line_contents (string, required): Expected content of target line
where (enum, required): 'before' or 'after'
contents (string, required): Content to insert
file_path (string, required): Absolute path to the file
line_start (number, required): Starting line number
line_end (number, required): Ending line number
line_start_contents (string, required): Expected content of starting line
contents (string, required): Replacement content
file_path (string, required): Absolute path to the file
edits (array, required): Array of edit operations
line_start (number, required): Starting line number (1-based)
line_end (number, required): Ending line number (1-based)
line_start_contents (string, required): Expected content of starting line
contents (string, required): New content to replace the lines with
file_path (string, required): Absolute path to the file
regexp (string, required): Regular expression pattern
lines_before (number, optional): Context lines before matches
lines_after (number, optional): Context lines after matches
directory_path (string, required): Absolute path to the directory
directory_path (string, required): Absolute path to the directory
regexp (string, required): Regular expression pattern
recursive (boolean, optional): Search subdirectories
lines_before (number, optional): Context lines before matches
lines_after (number, optional): Context lines after matches
include (string, optional): File pattern to include
exclude (string, optional): File/directory pattern to exclude
file_path (string, required): Absolute path to the file to be created
contents (string, required): Content to write into the new file
The server provides detailed error messages for common issues:
Path validation: Clear messages for relative paths and non-existent files
Content verification: Helpful guidance when line content doesn't match
File operations: Descriptive errors for read/write failures
Parameter validation: Specific guidance for invalid parameters
Fork the repository
Create a feature branch
Add tests for new functionality
Ensure all tests pass
Submit a pull request
This project is licensed under the MIT License. See LICENSE file for details.
v1.1.0 – Added create_file tool for creating files with automatic directory creation and safe‑overwrite protection.
The server is built with:
TypeScript for type safety and modern JavaScript features
FastMCP framework for MCP protocol implementation
Zod for schema validation
Vitest for comprehensive testing
fs-extra for enhanced file system operations
The architecture follows clean separation of concerns with:
Main server implementation in src/index.ts
Utility functions in src/utils.ts
Comprehensive test suite with proper MCP client integration
Modular tool implementations with consistent error handling
Delete content from a file between specified line numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file | |
| line_end | Yes | Ending line number (1-based) | |
| line_start | Yes | Starting line number (1-based) | |
| line_start_contents | Yes | Expected content of the starting line (used for verification) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without disclosing critical behavioral traits. It doesn't mention whether the deletion is permanent, requires file permissions, handles errors (e.g., invalid line numbers), or affects file structure. This leaves significant gaps for a destructive 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 a single, clear sentence that efficiently conveys the core functionality without unnecessary details. It is front-loaded and wastes no words, making it easy to understand at a glance.
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 complexity of a destructive file operation with no annotations and no output schema, the description is inadequate. It lacks information on outcomes (e.g., success/failure indicators), error handling, or safety considerations, leaving the agent under-informed for proper tool invocation.
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 parameters are well-documented in the schema. The description adds minimal value by implying line-based deletion but doesn't provide additional context beyond what the schema already covers, such as how 'line_start_contents' verification works or edge cases.
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 ('Delete content') and resource ('from a file'), specifying the scope ('between specified line numbers'). It distinguishes from siblings like 'replace_in_file' or 'insert_into_file' by focusing on deletion rather than modification or addition, though it doesn't explicitly name alternatives.
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?
No guidance is provided on when to use this tool versus alternatives like 'replace_in_file' or 'replace_lines_in_file' for similar line-based operations. The description implies usage for deleting content between lines but lacks context on prerequisites, exclusions, or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert content into a file at a specific line position.
| Name | Required | Description | Default |
|---|---|---|---|
| contents | Yes | Content to insert | |
| file_path | Yes | Absolute path to the file | |
| line_contents | Yes | Expected content of the target line (used for verification) | |
| line_number | Yes | Line number to insert at (1-based). Use 0 to append to end. | |
| where | Yes | Whether to insert before or after the target line |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose whether this is a destructive mutation, what permissions are needed, how errors are handled, or what happens if the file doesn't exist. For a file modification tool with zero annotation coverage, this is insufficient behavioral context.
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, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a tool with this level of complexity and gets straight to the point.
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 file mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens on success/failure, return values, error conditions, or how it differs from similar tools. The agent would need to guess too much about this tool's behavior.
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 all parameters are documented in the schema. The description adds no parameter-specific information beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 specific action ('Insert content'), target resource ('into a file'), and precise positioning ('at a specific line position'). It distinguishes from siblings like 'replace_in_file' or 'delete_from_file' by focusing on insertion rather than replacement or deletion.
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 provides no guidance on when to use this tool versus alternatives like 'replace_in_file' or 'replace_lines_in_file'. It doesn't mention prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files and subdirectories in a given directory.
| Name | Required | Description | Default |
|---|---|---|---|
| directory_path | Yes | Absolute path to the directory to list |
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 states the action but doesn't mention important behavioral aspects like whether it requires specific permissions, how it handles non-existent directories, what the return format looks like (e.g., list structure, pagination), or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality, making it easy for an agent to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., format, structure), error conditions, or behavioral constraints. Given the complexity of file system operations and the lack of structured data, more context is needed for an agent to use this tool effectively.
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?
The schema description coverage is 100%, with the single parameter 'directory_path' clearly documented as 'Absolute path to the directory to list'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage but doesn't add extra value.
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 verb ('List') and resource ('all files and subdirectories') with the scope ('in a given directory'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_directory' which might also list files but with filtering capabilities.
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 provides no guidance on when to use this tool versus alternatives like 'search_directory' or 'search_file'. It mentions the directory scope but doesn't indicate whether this is for unfiltered listing versus searching, or any prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file. You can read the entire file or specific line ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| end_line | No | Ending line number (1-based). Cannot be used with full=true | |
| file_path | Yes | Absolute path to the file to read | |
| full | No | Read the entire file. Cannot be used with start_line or end_line | |
| show_line_numbers | No | Whether to prefix each line with its line number | |
| start_line | No | Starting line number (1-based). Cannot be used with full=true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions reading capabilities but fails to disclose critical traits such as file size limits, encoding handling, error conditions (e.g., if the file doesn't exist or is unreadable), or performance implications. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 front-loaded with the core purpose in the first sentence and adds useful detail in the second sentence without redundancy. It is appropriately sized with zero waste, making it easy to scan and understand quickly.
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 complexity of file operations and lack of annotations and output schema, the description is incomplete. It does not address error handling, return format (e.g., whether output is raw text or structured), or limitations (e.g., large files), which are crucial for an AI agent to use the tool effectively in varied contexts.
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 thoroughly. The description adds minimal value by implying line-range functionality but does not provide additional semantics beyond what the schema specifies (e.g., it doesn't clarify format or constraints for 'file_path' or interactions between parameters). Baseline 3 is appropriate as the schema handles most parameter documentation.
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 verb ('Read') and resource ('contents of a file'), specifying the action and target. It distinguishes from siblings like 'delete_from_file', 'insert_into_file', and 'replace_in_file' by focusing on reading rather than modifying files, and from 'list_files' by reading file contents instead of listing 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 provides clear context for usage by mentioning 'entire file or specific line ranges', which helps understand when to use different parameter combinations. However, it does not explicitly state when to use this tool versus alternatives like 'search_file' for content searching or 'list_files' for file metadata, leaving some sibling differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace all occurrences of a regex pattern with a target string in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file | |
| multiple | No | Allow multiple replacements. If false, fails if multiple matches found. | |
| regex_source | Yes | Regular expression pattern to search for | |
| target | Yes | String to replace matches with |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose critical behavioral traits like whether the operation is atomic, what happens on failure, if backups are created, or permission requirements. The description doesn't contradict annotations, but provides minimal behavioral context.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point.
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 file modification tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, whether the operation is destructive, what permissions are needed, or what the return value might be. Given the complexity of file system operations, more context is needed.
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 fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema - it mentions 'regex pattern' and 'target string' which are already covered by schema descriptions for regex_source and target parameters.
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 specific action ('Replace all occurrences'), resource ('in a file'), and mechanism ('regex pattern with a target string'). It distinguishes from siblings like 'replace_lines_in_file' by focusing on pattern-based replacement rather than line-based operations.
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 for regex-based file modifications but doesn't explicitly state when to use this versus alternatives like 'replace_lines_in_file' or 'delete_from_file'. No guidance on prerequisites, file permissions, or error conditions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace content between specific line numbers in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| contents | Yes | New content to replace the lines with | |
| file_path | Yes | Absolute path to the file | |
| line_end | Yes | Ending line number (1-based) | |
| line_start | Yes | Starting line number (1-based) | |
| line_start_contents | Yes | Expected content of the starting line (used for verification) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the core action but omits critical details: whether the operation is destructive (likely yes, but not confirmed), what happens if line numbers are invalid, how 'line_start_contents' verification works, if changes are atomic or reversible, or what the tool returns. This is a significant gap for a file mutation tool.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and avoids redundancy, making it easy to parse quickly.
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 file operation with 5 parameters and no annotations or output schema, the description is inadequate. It lacks information about behavioral traits (safety, error handling), output format, and differentiation from sibling tools. The agent would struggle to use this correctly without trial and error.
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 parameters are fully documented in the schema. The description adds no additional semantic context beyond implying line-based replacement, which is already clear from parameter names. It doesn't explain interactions between parameters (e.g., how 'line_start_contents' relates to 'line_start') or provide usage examples.
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 ('Replace content') and target ('between specific line numbers in a file'), making the purpose understandable. It distinguishes from siblings like 'replace_in_file' (likely pattern-based) by specifying line-based replacement, but doesn't explicitly contrast with 'delete_from_file' or 'insert_into_file' which are also line-oriented operations.
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 provides no guidance on when to use this tool versus alternatives like 'replace_in_file', 'delete_from_file', or 'insert_into_file'. It doesn't mention prerequisites (e.g., file must exist), error conditions, or typical use cases, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for regex patterns across all files in a directory.
| Name | Required | Description | Default |
|---|---|---|---|
| directory_path | Yes | Absolute path to the directory to search | |
| exclude | No | Glob pattern for files/directories to exclude | |
| include | No | Glob pattern for files to include (e.g., "*.ts", "*.js") | |
| lines_after | No | Number of lines to show after each match | |
| lines_before | No | Number of lines to show before each match | |
| recursive | No | Search recursively in subdirectories | |
| regexp | Yes | Regular expression pattern to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'search' but doesn't clarify whether this is read-only (likely, given the verb), what happens with large directories (performance implications), whether results are paginated, or what the output format looks like. The description provides basic intent but lacks critical operational details needed for effective tool invocation.
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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information. Every word earns its place in this concise formulation.
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 7-parameter search tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., match locations, context lines, file paths), how results are structured, or any limitations (e.g., maximum directory size, performance considerations). The agent lacks sufficient context to understand the tool's behavior and output.
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 all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning 'regex patterns' and 'all files in a directory,' which aligns with 'regexp' and 'directory_path' parameters. However, it doesn't explain parameter interactions or provide additional context beyond what's already in the structured schema 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's purpose with a specific verb ('Search') and resource ('regex patterns across all files in a directory'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_file' (which likely searches within a single file) or 'list_files' (which lists files without pattern matching), leaving some ambiguity about when to choose this tool over those alternatives.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'search_file' (for single-file searches) and 'list_files' (for file listing without regex), the agent must infer usage context from tool names alone. No explicit when/when-not statements or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for regex patterns in a file and show matching lines with context.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file | |
| lines_after | No | Number of lines to show after each match | |
| lines_before | No | Number of lines to show before each match | |
| regexp | Yes | Regular expression pattern to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks important behavioral details. It doesn't disclose whether the tool requires file read permissions, how it handles large files, error conditions (e.g., missing files), or output format specifics beyond 'matching lines with context'. The description is minimal but doesn't contradict annotations.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential details about pattern type and output format. Every element earns its place.
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 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the output looks like (structure, format), error handling, performance considerations, or important constraints. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral 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 description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value by mentioning 'context' (which relates to lines_before/lines_after) but doesn't provide additional syntax, format, or usage details beyond what the schema specifies.
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 specific action ('search for regex patterns'), target resource ('in a file'), and outcome ('show matching lines with context'). It distinguishes from siblings like list_files (listing), read_file (full content), and search_directory (directory-level search) by focusing on pattern matching within a single file.
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 for regex-based file content searching, but doesn't explicitly state when to use this versus alternatives like search_directory (for directory-wide searches) or read_file (for full file content). No guidance on prerequisites or exclusions is provided.
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.0delete_from_fileinsert_into_filelist_filesread_filereplace_in_filereplace_lines_in_filesearch_directorysearch_fileEach tool has a clearly distinct purpose with no ambiguity. For example, 'delete_from_file' removes content between lines, 'insert_into_file' adds content at a line, 'replace_in_file' handles regex-based replacements, and 'replace_lines_in_file' targets specific line ranges, making them easily distinguishable. The search tools ('search_directory' vs. 'search_file') also serve different scopes without overlap.
All tool names follow a consistent verb_noun pattern with snake_case, such as 'delete_from_file', 'insert_into_file', and 'search_directory'. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions across the eight tools.
With 8 tools, the server is well-scoped for file editing operations, covering essential actions like reading, writing, deleting, inserting, replacing, and searching. Each tool earns its place by addressing specific needs in file manipulation, avoiding both bloat and insufficiency for the domain.
The tool set provides complete coverage for file editing, including CRUD-like operations (read, insert, delete, replace) and search functionalities at both file and directory levels. There are no obvious gaps, as all core workflows for editing and managing files are supported without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
Exactly 50 data transformation and live web verification tools for AI agents.
13 micro-tools for agents: read pages, verify email, convert, validate, diff, extract. AI-operated.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pwilkin/mcp-file-edit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server