MCP Verdict
Back to the registry

@agent-infra/mcp-server-filesystem

MCP serverVerified · Rung 3
F40

The filesystem MCP server from ByteDance's agent-infra / UI-TARS Agent ecosystem. Exposes 11 tools for standard read/write/search/directory operations. Supports stdio, SSE, and HTTP transports. Enforces a configurable directory allowlist via the --allowed-directories CLI flag (repeatable for multiple directories).

RepositoryHomepageExample data

Score breakdown

Functional100/100
Reliability94/100
Latency100/100
Security38/100
Confidencelow · 50%

Based on 1 evaluation. Confidence rises as more independent tests agree.

Method rung1.v1computed Jul 14, 2026How we score

The verdict

Part of ByteDance's UI-TARS desktop agent infrastructure. The allowlist is correctly enforced for direct path access: path traversal and /etc/passwd reads are blocked. However, re-verification reveals that read_file follows symlinks without resolving them against the allowed directories. A symlink inside the allowed directory pointing to /etc/passwd returns its full contents when read_file is called on the symlink path — confirmed: 'root:x:0:0:root:/root:/bin/bash...' returned. Any agent with write access to the allowed directory can create a symlink and use it to read any file the process can access, bypassing the allowlist entirely. One setup distinction from the official package: allowed directories are passed via --allowed-directories flags rather than as positional arguments. Misconfiguring this as a positional argument causes an explicit 'too many arguments' error rather than silently ignoring the constraint.

This is a published failing verdict. We send the maintainer the full evaluation and a window to fix it or correct us before it goes live. Read the disclosure policy.

Security findings

Flags from our evaluations, ordered by severity.

  • High

    SYMLINK_FOLLOW_ESCAPE

    read_file follows symlinks inside the allowed directory without resolving them against the allowlist. A symlink at /tmp/fs_reverify_ws/symlink_to_etc_passwd pointing to /etc/passwd was created inside the allowed directory. Calling read_file on the symlink path returned the full contents of /etc/passwd: 'root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin...'. Any agent with write access to the allowed directory can create a symlink to any file the process can read and exfiltrate its contents.

  • Info

    NONSTANDARD_CLI_INVOCATION

    Allowed directories are configured via --allowed-directories flag, not positional arguments as in the official @modelcontextprotocol/server-filesystem. Users copying invocation patterns from the official package or mark3labs binary will get an explicit error rather than the server silently running without restrictions. The error message is clear, but the difference is underdocumented in the README.

Test history

1 run

Every evaluation behind the score. This is the receipt.

  1. Passmanual
    Reliability

    94/100

    Latency

    3 ms

    Setup

    Easy

    Flags

    2

    11 tools verified via stdio NDJSON in a Node v22 sandbox (npm v1.2.29). Tools: read_file, read_multiple_files, write_file, edit_file, create_directory, list_directory, directory_tree, move_file, search_files, get_file_info, list_allowed_directories. All return correct results. Invocation requires --allowed-directories flag (positional arg produces explicit error).

    HighSYMLINK_FOLLOW_ESCAPEInfoNONSTANDARD_CLI_INVOCATION

Notify me if this grade changes

We re-test servers and grades move. Leave your email and we will tell you if this one does.