Proposal: Restore file-path tools via allowlisted roots (filesystem-style)

[iqdoctor]

Hi Eugene!

I saw in the README that tools requiring direct file path access were removed because of limitations in the current MCP environment around handling file attachments and local file system paths:

• send_file, download_media, set_profile_photo, edit_chat_photo, send_voice, send_sticker, upload_file

Proposal

Restore these tools using the same security model as the official MCP Filesystem server:

• MCP Filesystem reference: https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem

Allowed directories / roots

Support allowlisted directories in two ways:

1. Command-line arguments (static allowlist)

• Example: telegram-mcp /path/to/dir1 /path/to/dir2

2. MCP Roots (recommended)

• For MCP clients that support Roots, allow them to dynamically update allowed directories.
• When Roots are provided by the client, they should replace any server-side allowed directories (same semantics as filesystem server).

Path security rules (suggested)

• Accept relative paths resolved against the first allowed root
• Reject path traversal and glob-like patterns (.., *, ?, ~, slashes in “file name only” inputs, etc.)
• Resolve symlinks (realpath) and ensure the final path stays within an allowed root
• Enforce read/write permissions depending on the tool
• Optional: file-size limits and extension allowlists per tool (.jpg/.png/.webp/.ogg/.opus, etc.)

Tool behavior (suggested)

• For “write” tools (e.g. download_media), default to a safe subfolder (e.g. <root>/downloads/) when no file path is provided and return the final saved path.
• For “read” tools (e.g. send_file), require the file to exist under allowed roots.

Questions for maintainers

1. Would you accept a PR that restores these tools behind a config flag (default off), or enables them when allowed roots are set?
2. Is there a preferred approach for Roots support in this server (any existing pattern you want followed)?
3. Any constraints you want on outputs (e.g. always save downloads under a dedicated folder)?

If you're open to it, I can prepare a PR that ports the filesystem-server style path validation and reintroduces these tools with safe defaults.

[iqdoctor]

@chigwell

Are you agree with this feat design?

[chigwell]

@iqdoctor

1. Would you accept a PR that restores these tools behind a config flag (default off)...

Yes - thank you, PR welcome. The safest default is disabled unless allowed roots are explicitly configured (via CLI allowlist and/or client-provided Roots).

2. Is there a preferred approach for Roots support in this server (any existing pattern you want followed)?

Please mirror the official MCP filesystem server semantics:

• support a server-side allowlist (CLI args) as a fallback
• if the client provides Roots, they replace the server allowlist
• enforce realpath + "must stay within an allowed root" checks (including symlink resolution), and reject traversal / glob-like patterns

3. Any constraints you want on outputs (e.g. always save downloads under a dedicated folder)?

Yes:

• for "write" tools, default to a dedicated folder under the first root (e.g. <root>/downloads/) when no path is provided, and return the final resolved path
• extension allowlists and size limits per tool are encouraged