[FileSystem] directory_tree base implementation

[lamemind]

Description

Add directory_tree function to filesystem server to provide hierarchical visualization of directory structures. This provides a clear, formatted tree view with ASCII characters for structure and distinguishes between files and directories with [F] and [D] prefixes.

Server Details

• Server: filesystem
• Changes to: tools (added directory_tree function)

Motivation and Context

The existing list_directory function only shows contents of a single directory level. When analyzing project structures or complex directory hierarchies, users need a recursive view of the entire directory tree. This addition allows LLMs to quickly understand and reason about complete directory structures in a single query.

Breaking Changes

No breaking changes. Adds new functionality while maintaining existing behavior.

Types of changes

• Bug fix
• New feature
• Breaking change
• Documentation update

Checklist

• I have read the MCP Protocol Documentation (not read)
• My changes follows MCP security best practices (not checked the best practices)
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

Implementation follows similar pattern to list_directory:

• Uses same path validation mechanism
• Maintains consistent error handling
• Returns same response format
• Uses standardized ASCII characters (│ ├ └ ─) for tree structure
• Prefixes entries with [F] for files and [D] for directories

Example output:

├── [D] src
│   ├── [D] main
│   │   └── [F] index.ts
│   └── [D] test
│       └── [F] test.ts
└── [F] package.json

[jspahrsummers]

Tool results are meant for consumption by the model, rather than the end user. I'm not sure this visualization will help the model, compared to more structured forms of information (e.g., JSON or XML).

Can you share more about the use case you have in mind?

[lamemind]

Tool results are meant for consumption by the model, rather than the end user. I'm not sure this visualization will help the model, compared to more structured forms of information (e.g., JSON or XML).

Can you share more about the use case you have in mind?

Hello @jspahrsummers ,

I didn't focus on the use cases.
I adhered to the format of the list_directory function, which returns text decorated with [FILE] and [DIR] depending on the entry. Claude was OK with this format.

Anyway, I can change the implementation as you prefer.

Thanks

[jspahrsummers]

I think the list_directory case is a bit different, in that it's just adding tags describing each entry, which the model can easily interpret. However, using ASCII art basically relies on the model's visual understanding of text, which can vary a lot depending on model—and in any case, almost certainly won't be as strong as one of these alternatives:

1. A JSON or XML representation of the same information
2. An actual image

Arguably, even a bulleted list with nesting would probably work better. Can you update to one of those, and we can get this merged?

[lamemind]

@jspahrsummers it's done.
I preferred to use an output in JSON format
sorry for the noise in the diff view

Thanks

[jspahrsummers]

Great, thank you!