Back to catalog
A

Official Vendor Server

Anthropic✦ Lab Verified

Filesystem

Secure file operations with configurable access controls. Read, write, and manage files and directories on the local filesystem.

9.5/10

Score

8ms

Latency

Local

Uptime

14

Tools

stdio

Auth

Officialvendor-verifiedsecurity-scanneddeveloper-tools

Ecosystem

Anthropic MCP Servers

4 specialized servers, 23 tools tested independently. Each link leads to a full review with tool-level evidence.

ServerScoreSecurity
SQLite95/10010/10
Memory / Knowledge Graph95/10010/10
Puppeteer95/10010/10
Sequential Thinking94/10010/10
14 discovered14 executed14 success
Median latency: 8ms

Quick Verdict

Use this for local file operations. Avoid it if you need remote file access. Best area: read operations with 8ms median latency. Biggest failure: none in current tests.

Lab Review

What We Found

What works: The filesystem server handles local file operations without hiccups. All 14 tools from basic reads (read_file, read_text_file) to batch operations (read_multiple_files) and directory management (create_directory, move_file) completed successfully. Response times stayed under 24ms. You get straightforward JSON responses for file content, directory listings and metadata queries. Where it breaks: Our tests ran in a controlled sandbox with clean file paths and standard permissions. Real filesystem chaos - network drives that timeout, permission denied errors on system directories, or files locked by other processes - wasn't part of this testing environment. The server's error handling for these common filesystem gotchas remains untested. Without write operations that could trigger permission failures or concurrent access issues, we lack evidence of how it responds to typical filesystem conflicts. What this means for your workflow: Basic file reading and directory operations are solid for development environments with predictable access patterns. The core functionality performed reliably in current tests, but you need fallback logic for permission errors and file locks that production filesystems throw regularly. For straightforward file processing scripts, this server delivers. For file management systems dealing with complex permissions or network storage, test your error scenarios first.

Lab Observations

What actually happened during testing

During testing, our scanner interacted with Filesystem. 14 tools succeeded.

ToolStatus
list_allowed_directories success
read_file success
read_text_file success
read_media_file success
read_multiple_files success
list_directory success
list_directory_with_sizes success
directory_tree success
get_file_info success
search_files success
write_file success
edit_file success
create_directory success
move_file success

Reliability

10/10

Full runtime test completed. Score based on transport stability and schema completeness.

Score Breakdown

10/10

Reliability

14 of 14 executed tools succeeded.

10/10

Security

Score based on schema analysis and dependency audit.

9/10

Setup

Local stdio server. Install via npx or binary, no auth required.

8.9/10

Docs

14 tools with descriptions and input schemas.

10/10

Compatibility

Standard MCP protocol. Transport: stdio.

7.8/10

Maintenance

Based on commit frequency, releases, and contributor activity.

Tools

14 available tools

read_file

Read the complete contents of a file as text. DEPRECATED: Use read_text_file instead.

read_text_file

Read the complete contents of a file from the file system as text. Handles various text encodings and provides detailed error messages if the file cannot be read. Use this tool when you need to examine the contents of a single file. Use the 'head' parameter to read only the first N lines of a file, or the 'tail' parameter to read only the last N lines of a file. Operates on the file as text regardless of extension. Only works within allowed directories.

read_media_file

Read an image or audio file. Returns the base64 encoded data and MIME type. Only works within allowed directories.

read_multiple_files

Read the contents of multiple files simultaneously. This is more efficient than reading files one by one when you need to analyze or compare multiple files. Each file's content is returned with its path as a reference. Failed reads for individual files won't stop the entire operation. Only works within allowed directories.

write_file

Create a new file or completely overwrite an existing file with new content. Use with caution as it will overwrite existing files without warning. Handles text content with proper encoding. Only works within allowed directories.

Show all 14 tools →
edit_file

Make line-based edits to a text file. Each edit replaces exact line sequences with new content. Returns a git-style diff showing the changes made. Only works within allowed directories.

create_directory

Create a new directory or ensure a directory exists. Can create multiple nested directories in one operation. If the directory already exists, this operation will succeed silently. Perfect for setting up directory structures for projects or ensuring required paths exist. Only works within allowed directories.

list_directory

Get a detailed listing of all files and directories in a specified path. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is essential for understanding directory structure and finding specific files within a directory. Only works within allowed directories.

list_directory_with_sizes

Get a detailed listing of all files and directories in a specified path, including sizes. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is useful for understanding directory structure and finding specific files within a directory. Only works within allowed directories.

directory_tree

Get a recursive tree view of files and directories as a JSON structure. Each entry includes 'name', 'type' (file/directory), and 'children' for directories. Files have no children array, while directories always have a children array (which may be empty). The output is formatted with 2-space indentation for readability. Only works within allowed directories.

move_file

Move or rename files and directories. Can move files between directories and rename them in a single operation. If the destination exists, the operation will fail. Works across different directories and can be used for simple renaming within the same directory. Both source and destination must be within allowed directories.

search_files

Recursively search for files and directories matching a pattern. The patterns should be glob-style patterns that match paths relative to the working directory. Use pattern like '*.ext' to match files in current directory, and '**/*.ext' to match files in all subdirectories. Returns full paths to all matching items. Great for finding files when you don't know their exact location. Only searches within allowed directories.

get_file_info

Retrieve detailed metadata about a file or directory. Returns comprehensive information including size, creation time, last modified time, permissions, and type. This tool is perfect for understanding file characteristics without reading the actual content. Only works within allowed directories.

list_allowed_directories

Returns the list of directories that this server is allowed to access. Subdirectories within these allowed directories are also accessible. Use this to understand which directories and their nested paths are available before trying to access files.

FAQ

Frequently asked questions about Filesystem

What's the performance difference between basic and metadata-heavy operations?+

Basic operations like read_text_file and directory_tree completed in 4-6ms, while metadata operations took slightly longer. list_directory_with_sizes required 24ms to gather comprehensive file size data for entire directories. File modification operations like write_file and edit_file executed in just 3-5ms. All operations completed with excellent response times for filesystem access.

Can the server handle both individual and batch file operations?+

We executed both single-file operations like read_file (12ms) and batch operations like read_multiple_files (9ms). The batch operation actually completed faster per file than individual reads. Both get_file_info for single files and list_directory for multiple entries executed successfully with sub-15ms response times.

Which file types can be accessed through the media reading tool?+

The read_media_file tool executed successfully in 11ms during testing. However, our test environment used standard file fixtures, so we cannot specify which exact media formats (images, audio, video) are supported. The tool completed without errors when called, indicating basic media file access functionality is present.

How does the search functionality perform across directory structures?+

The search_files tool completed in 8ms during our testing. This operation searched through the sandbox directory structure and returned results efficiently. We cannot specify the exact search criteria or pattern matching capabilities tested, but the response time indicates fast traversal and filtering of filesystem contents.

Are there any gotchas with the allowed directories restriction?+

list_allowed_directories completed in 14ms and returned the accessible path list. This represents a security boundary - the server restricts access to predefined directories only. Developers need to check this list first to understand their access scope, as operations outside these directories would presumably fail with permission errors.

What's the latency range for write operations versus read operations?+

Write operations performed exceptionally well, with write_file at 5ms, create_directory at 3ms, and move_file at 3ms. Read operations ranged from 4-24ms depending on complexity. Interestingly, file modification operations were among the fastest, while directory listing with size metadata took the longest at 24ms due to additional filesystem queries.

Does the edit functionality require reading the entire file first?+

The edit_file operation completed in just 5ms, matching the performance of write_file. We cannot determine from our testing whether this represents in-place editing or full file rewrite operations. The fast execution time suggests efficient file handling, but the specific editing mechanism (patch-based vs full replacement) was not observable from our test results.

Related

Explore more

Testing History

1 runlive_runtimeApr 7, 2026
protocol10/10reliability10/10

Community

Community Reviews

No community reviews yet. Be the first to share your experience!

Write a Review

Overall
Ease of Setup
Documentation
Reliability

0 / 5000