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., "@Local Files MCP Server show me the contents of ~/projects/notes.txt"
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 for managing local files. Provides tools for reading, writing, analyzing, searching, and organizing files with built-in safety protections.
📖 Read/Write files - UTF-8 and base64 support
📂 Directory operations - List, organize, search
🔍 Content search - Regex pattern matching
🔎 Find duplicates - MD5 hash comparison
📊 File analysis - Size, MIME type, line counts
🛡️ Safety protections - Configurable allowed/protected paths
🖥️ Cross-platform - macOS, Linux, Windows
Related MCP server: filezop
Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"local-files": {
"command": "npx",
"args": ["-y", "fsorg"]
}
}
}That's it! Claude Desktop will automatically download and run the MCP server via npx.
git clone https://github.com/argtobias/fsorg.git
cd fsorg
pnpm install
pnpm buildThen configure Claude Desktop:
{
"mcpServers": {
"local-files": {
"command": "node",
"args": ["/path/to/fsorg/dist/index.js"]
}
}
}Create a config file at:
-- macOS/Linux: ~/.config/localfiles-org/config.json
-- Windows: %LOCALAPPDATA%\localfiles-org\config.json
{
"allowedPaths": [
"~/projects",
"~/Development",
"~/workspace",
"/tmp"
],
"additionalProtectedPaths": [
"~/my-important-folder"
],
"additionalProtectedPatterns": [
"^backup",
"\\.bak$"
]
}Option | Description | Default |
| Paths where delete operations are permitted |
|
| Extra paths to protect from deletion |
|
| Regex patterns for protected file names |
|
System paths: /, /etc, /usr, /bin, /System, etc.
User paths: ~, ~/Documents, ~/Desktop, ~/Downloads, ~/.ssh
Patterns: .git, .env, .ssh, credentials, secrets
Tool | Description |
| Read file contents (UTF-8 or base64) |
| Write content to file (UTF-8 or base64) |
| Safely delete a file with protection checks |
| Move file with optional empty directory cleanup |
| Get file stats (size, MIME, lines, words) |
Tool | Description |
| List files with optional recursion and glob patterns |
| Safely delete directory (requires confirmation for recursive) |
| Organize files into folders by extension/date/size |
Tool | Description |
| Search for regex patterns in file contents |
| Find duplicate files by MD5 hash |
| Sort lines in a file |
Tool | Description |
| Batch rename files using regex patterns |
{
"tool": "read_file",
"arguments": {
"path": "~/projects/myfile.txt"
}
}{
"tool": "find_duplicates",
"arguments": {
"path": "~/projects/images",
"recursive": true
}
}{
"tool": "delete_file",
"arguments": {
"path": "~/projects/temp/old-file.txt",
"preview": true
}
}{
"tool": "organize_by_type",
# Local Files MCP Server
Simple MCP server for safe local file operations: read, write, search, organize and protected delete.
## Quick install
Run via npx (recommended for Claude Desktop):
```json
{
"mcpServers": {
"local-files": {
"command": "npx",
"args": ["-y", "fsorg"]
}
}
}From source:
git clone https://github.com/argtobias/fsorg.git
cd fsorg
pnpm install
pnpm buildCreate user config at:
macOS/Linux: ~/.config/localfiles-org/config.json
Windows: %LOCALAPPDATA%\\localfiles-org\\config.json
Minimal config example:
{
"allowedPaths": ["~/projects", "~/Development"],
"additionalProtectedPaths": [],
"additionalProtectedPatterns": []
}Only operations inside allowedPaths can delete files.
System and user-critical paths are always protected.
Pattern-based protection (e.g. .git, .env) is enforced.
Read a file:
{ "tool": "read_file", "arguments": { "path": "~/projects/myfile.txt" } }Find duplicates:
{ "tool": "find_duplicates", "arguments": { "path": "~/projects/images", "recursive": true } }Delete with preview (safe):
{ "tool": "delete_file", "arguments": { "path": "~/projects/temp/old.txt", "preview": true } }pnpm install
pnpm build
pnpm devISC
Analyze a file and return statistics: size, MIME type, line/word/character counts, and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether the tool is read-only, any side effects, or performance implications for large files. The behavior is implied as analysis but not explicitly stated.
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?
Single sentence, no waste. Front-loads the action and lists statistics efficiently. Could be slightly improved with better structure.
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 simplicity (1 param, no output schema), the description covers purpose and output types. However, it lacks details on file size limits, encoding handling, or error scenarios, leaving gaps for an agent.
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 a single 'path' parameter. The description adds no additional meaning beyond the schema, merely listing the output statistics. 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 clearly states the verb 'analyze' and resource 'file', and lists specific statistics returned. However, it does not differentiate from sibling tools like 'read_file' or 'list_directory', which could also inspect 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?
No guidance on when to use this tool versus alternatives (e.g., 'read_file' for content, 'list_directory' for listing). No mention of limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safely delete a directory with protection checks. Only works within allowed paths. Recursive deletion requires confirmRecursive=true. Use preview=true to see what will be deleted first.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the directory to delete | |
| preview | No | Preview what will be deleted without actually deleting | |
| recursive | No | Delete directory and all its contents recursively (REQUIRES CONFIRMATION) | |
| confirmRecursive | No | Explicit confirmation required when recursive=true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses safety features, allowed path restriction, and recursive confirmation requirement. Does not mention potential error conditions (e.g., deleting non-empty directory without recursive), permissions, or side effects beyond deletion.
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 providing distinct value. Front-loaded with purpose and safety, followed by key usage instructions. No redundant or unnecessary content.
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 absence of output schema, the description adequately explains the tool's core behavior and safety features. However, it omits what the return value indicates (e.g., success feedback) and does not cover edge cases like invalid paths or permission errors.
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?
Input schema covers all 4 parameters with descriptions (100% coverage), so baseline is 3. The description adds limited extra meaning, e.g., 'Use preview=true to see what will be deleted first' adds context but does not significantly deepen understanding 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?
Clearly specifies the verb 'delete' and resource 'directory'. Distinguishes from sibling 'delete_file' by focusing on directories, and adds safety context like 'protection checks' and 'allowed paths'.
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 clear guidance on when to use preview and require recursive confirmation. However, it does not explicitly state when to use this tool versus alternatives like 'delete_file' or 'list_directory' for assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safely delete a file with protection checks. Only works within allowed paths. Use preview=true to see what will be deleted first.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to delete | |
| preview | No | Preview what will be deleted without actually deleting | |
| cleanupEmpty | No | Remove empty parent directories after deleting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description mentions safety checks and allowed path constraints, adding behavioral context beyond the schema. However, it does not disclose whether deletion is permanent or reversible.
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 sentences, front-loaded with the core action and safety, 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?
No output schema, and the description does not explain return behavior (e.g., success/error). Adequate but incomplete for a delete 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 coverage is 100%, so the description adds minimal value—only emphasizing preview usage. 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 clearly states it deletes files with protection checks and path restrictions, distinguishing it from siblings like 'delete_directory' and 'move_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?
It advises using preview=true to preview deletion, but does not explicitly compare to alternatives like delete_directory or move_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find duplicate files by comparing MD5 hashes. Returns groups of identical files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path to search for duplicates | |
| recursive | No | Search recursively |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It discloses the hashing method and return format (groups of identical files), but omits potential performance impact, permission requirements, or error handling for missing paths.
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 sentences, no redundancy. Front-loaded with the core action and method, efficiently conveying purpose.
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?
Description covers the main functionality for a simple tool. Missing a note that working with large directories may be resource-intensive. Otherwise complete given no output schema.
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 already describes both parameters (path and recursive) with clear descriptions. The description adds the context of MD5 hashing but no additional parameter-specific details. With 100% schema coverage, baseline is 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?
Description clearly states verb 'find', resource 'duplicate files', and method 'comparing MD5 hashes'. It distinguishes from siblings like list_directory, search_content, and analyze_file, which have different purposes.
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 on when to use this tool versus alternatives. For example, it doesn't mention that find_duplicates is ideal for locating redundant files across a directory tree, while list_directory or search_content would be used for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a path. Supports recursive listing and glob pattern filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path to list | |
| recursive | No | List recursively | |
| pattern | No | Glob pattern to filter files |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description lacks behavioral details beyond the schema. It does not disclose permissions needed, limits, response format, or edge cases (e.g., broken symlinks). The tool's behavior is minimally described.
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 concise at one sentence, front-loading the core purpose with no unnecessary words. It is well-structured and 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?
Given the lack of an output schema, the description fails to explain the return format (e.g., full paths, metadata). It also does not address how to navigate the output, which is important for a list operation. The tool's role among many siblings is unclear.
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 no new meaning beyond the schema’s own parameter descriptions. It merely rephrases the schema (e.g., 'glob pattern filtering' vs. 'Glob pattern to filter files').
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 lists files and directories in a path, which is distinct from siblings like analyze_file or delete_directory. It uses a specific verb and resource, making its purpose immediately clear.
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 its siblings (e.g., search_content, find_duplicates). There is no mention of alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a file from source to destination. Creates parent directories if needed. Optionally cleans up empty parent directories.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source file path | |
| destination | Yes | Destination file path | |
| cleanupEmpty | No | Remove empty parent directories after moving |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: parent directories are created if needed, and optionally empty parent directories are removed. It does not mention overwrite behavior or error handling, but adds significant context beyond the schema.
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 two sentences, front-loaded with the main action, and contains no unnecessary words. Every sentence adds value.
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 and 3 fully documented parameters, the description explains core functionality and two behavioral details. However, it omits whether overwriting occurs if destination exists, which is a common concern. Still, it is mostly complete for a simple file move.
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 meaning for the 'destination' parameter by explaining that parent directories are created if needed. For 'cleanupEmpty', it largely repeats the schema definition, but overall the description enriches understanding of parameter effects.
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 'Move', the resource 'file', and distinguishes it from siblings like delete_file or rename_files by specifying the core action and side effects (creating parent directories, optional cleanup).
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 moving files but does not explicitly state when to use this over alternatives like rename_files or copy operations. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Organize files into subdirectories by extension, date, or size category. Automatically cleans up empty source directory.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source directory | |
| destination | Yes | Destination directory | |
| criteria | Yes | Criteria for organizing files | |
| cleanupEmpty | No | Remove source directory if empty after organizing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses automatic cleanup of empty source directory but omits details about side effects, permissions requirements, or what happens (e.g., overriding existing files). With no annotations, the description carries the full burden.
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 concise sentence with a second sentence about cleanup, but could be slightly more structured to immediately clarify use cases.
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 and four parameters, the description lacks information about return values, error conditions, and confirmation that files are moved (not copied). 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%, and the description adds no additional meaning beyond the schema's parameter descriptions and enum values.
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 organizes files into subdirectories by extension, date, or size category, which distinguishes it from siblings like move_file or rename_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 implies usage for batch organization but does not explicitly state when to use it versus alternatives like move_file for single files or rename_files for renaming.
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. Can read as UTF-8 text or base64 encoded. Optionally read only the first N lines.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to read | |
| encoding | No | Encoding to use when reading the file | utf8 |
| lines | No | Read only the first N lines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the core behavior but omits details like output format, error handling, or file size limitations, leaving the agent with minimal behavioral context beyond the obvious.
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 with no extraneous words. Key information is front-loaded, making it easy for an agent to quickly understand the tool's purpose.
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 read operation with no output schema, the description should at least hint at what is returned (file contents) or mention potential errors (e.g., file not found). It lacks these details, making it only partially complete.
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%, meaning the schema already documents all three parameters. The description adds no new semantic information beyond what the schema provides, so it meets the baseline without 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 action ('Read'), the resource ('file'), and distinguishes from sibling tools by specifying encoding options and line count feature.
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?
While it implies usage for reading files, it provides no explicit guidance on when to use this tool versus siblings like analyze_file or search_content, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch rename files in a directory using regex pattern matching. Supports preview mode.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path containing files to rename | |
| pattern | Yes | Pattern to search for (regex) | |
| replacement | Yes | Replacement string | |
| preview | No | Preview changes without applying |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. While it mentions 'preview mode', it does not explain what that implies (e.g., no changes applied) or other behaviors like overwriting, reversibility, or error handling.
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 sentences, no fluff. The main action and key feature are front-loaded. Every word is meaningful.
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 batch operation with 4 parameters and no output schema, the description lacks important context such as what the tool returns (e.g., renamed file list), error behavior, and whether it operates recursively. This is insufficient for a destructive tool.
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 4 parameters. The description adds minimal value beyond the schema, only summarizing the regex and preview aspects. Baseline score of 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 clearly states the tool does batch renaming using regex pattern matching, which is a specific action on files. It distinguishes from siblings by focusing solely on renaming, but could be more explicit about the batch aspect.
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 on when to use this tool versus alternatives like move_file or organize_by_type. There is no mention of preconditions or exclusions, leaving the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a pattern (regex) in file contents. Returns matches with line numbers and context.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File or directory path to search | |
| pattern | Yes | Pattern to search for (regex) | |
| recursive | No | Search recursively in directories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses return format (matches with line numbers and context) but lacks details on performance, binary file handling, or limits.
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 sentences, no redundant words. Front-loaded with action and result.
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?
Basic purpose clear but lacks detail on output format (e.g., what constitutes 'context') and edge cases. No output schema to compensate.
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 clear parameter descriptions. The description adds no extra meaning beyond the schema (e.g., 'regex' already in pattern 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?
Clear verb 'search' and resource 'file contents' with specifics: regex pattern, returns matches with line numbers and context. Distinguishes from sibling tools like list_directory or read_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?
Implied usage from description (searching content) but no explicit when to use vs alternatives 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.
Sort the lines of a file. Supports ascending/descending, numeric sorting, and duplicate removal.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to sort | |
| order | No | Sort order | asc |
| numeric | No | Sort numerically instead of alphabetically | |
| unique | No | Remove duplicate lines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose whether sorting modifies the file in-place or returns sorted content, nor any side effects or permissions needed.
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?
Single sentence that efficiently conveys core functionality and features with 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?
Adequate for a simple tool with full schema coverage, but lacks clarity on whether the operation is destructive (overwrites file) or produces output. No output schema to fill the gap.
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 provides full parameter coverage (100%). Description adds helpful summary of key features (ascending/descending, numeric, duplicate removal) beyond 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?
Description clearly states it sorts file lines and lists supported features (ordering, numeric, duplicates), but does not explicitly differentiate from sibling file manipulation tools.
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 on when to use this tool versus alternatives like analyze_file or search_content. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file. Supports UTF-8 or base64 encoding. Can overwrite or append. Creates parent directories if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to write | |
| content | Yes | Content to write to the file | |
| encoding | No | Encoding of the content: utf8 (default) or base64 | utf8 |
| mode | No | Write mode: overwrite or append | overwrite |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors (encoding options, modes, directory creation) but omits details like default mode, permissions, or error handling. Adequate but not exhaustive.
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 sentences, zero waste. Front-loaded with the primary purpose, then details. Every sentence adds value without redundancy.
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's simplicity and lack of output schema or annotations, the description covers the essential aspects: purpose, encoding, mode, and directory creation. It misses only minor details like return value or error scenarios, which is acceptable for a straightforward write 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?
The input schema covers all four parameters with 100% coverage, so the description's value is supplementary. It adds context about parent directory creation and summarizes encodings/modes, providing meaningful clarification beyond the schema definitions.
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 'Write content to a file', enumerates supported encodings (UTF-8, base64), modes (overwrite, append), and an additional behavior (creates parent directories). This distinguishes it from sibling tools like read_file or delete_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 writing files but does not explicitly state when to use this tool over alternatives or when not to use it. No guidance on prerequisites or comparisons with siblings.
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.0analyze_filedelete_directorydelete_filefind_duplicateslist_directorymove_fileorganize_by_typeread_filerename_filessearch_contentsort_file_contentwrite_fileEach tool has a clearly distinct purpose: reading, writing, deleting, moving, listing, analyzing, searching, sorting, renaming, finding duplicates, and organizing files or directories. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern (e.g., read_file, delete_directory, search_content), making it easy for an agent to predict tool names and purposes.
With 12 tools, the server provides a well-scoped set of file and directory operations. The number is appropriate for the domain, covering essential actions without being overwhelming.
The tool set covers most common file operations: CRUD, listing, searching, analysis, organization, and batch operations. A minor gap is the lack of a copy_file tool, but move_file can serve a similar role in many cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browse and manage files in your Moxt AI workspace from any MCP client.
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
Project management MCP for AI agents with safe task reads and writes.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TobiasArg/LocalFilesOrganizer-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
