filesystem: clarify effective root state after initialization

[Josh-Shultis]

Summary

The filesystem server can start without command-line allowed directories and wait for the client to provide MCP Roots.

The startup message is accurate, but operators may benefit from a clearer final message identifying the effective access-control state and where the active roots originated.

Observed behavior

Startup output:

Started without allowed directories - waiting for client to provide roots via MCP protocol

After initialization, the client supplied one MCP root and the server reported:

Updated allowed directories from MCP roots: 1 valid directories

Access-control test

Tested using @modelcontextprotocol/server-filesystem package version 2026.8.31.

Results:

• list_allowed_directories returned only C:\MCP-Security-Test\Allowed.
• Reading a controlled file inside that directory succeeded.
• Reading a controlled file outside that directory was denied.
• Writing a controlled file outside that directory was denied.

The implementation therefore failed closed. I am not reporting an access-control bypass.

Suggestion

Consider logging a prominent summary after initialization showing:

1. The final effective allowed-directory list.
2. Whether it came from command-line arguments or client-provided MCP Roots.
3. Whether client Roots replaced command-line directories.
4. Whether the server currently has no usable roots.

This would help operators distinguish between an empty startup state, active command-line restrictions, and client-provided replacements.