Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP File Manager list files in the current directory"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local file management MCP server built with Python and the official mcp library (FastMCP).
List Files: List contents of directories.
Read Files: Read content of text files.
File Info: Get metadata (size, modification time) of files.
Search: Recursively search for files by name.
Related MCP server: Local Files MCP Server
Python 3.10+
uv (recommended) or pip
Install dependencies:
uv syncRun the server:
uv run main.pyAdd the following to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"file-manager": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/MCP-file-managment",
"run",
"main.py"
]
}
}
}Note: Replace /ABSOLUTE/PATH/TO/MCP-file-managment with the actual absolute path to the directory where you cloned this repository.
list_files(directory): List files and directories in the specified path (defaults to current directory).
read_file(file_path): Read the content of a text file.
file_info(file_path): Get file size, type, and modification time.
search_files(keyword): Recursively search for filenames containing a keyword in the current working directory.
Get metadata about a file.
Args:
file_path: Relative path to the file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, how errors are handled (e.g., missing file), or any side effects. The description only states the purpose, omitting behavioral traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence for the purpose and a single line for the parameter. There is no fluff, and the 'Args:' structure is clear and front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema present, the description covers the basic purpose and param. However, it lacks usage guidelines and any note on what metadata is returned or potential errors. It is minimally viable but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'file_path' with no description, so schema coverage is 0%. The description adds meaning by specifying 'Relative path to the file', which clarifies that the path is relative (not absolute) and is a file, not a directory. This is valuable semantic information that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get metadata about a file' which is a specific verb+resource. It distinguishes this tool from siblings like list_files, read_file, and search_files, as it focuses on metadata rather than listing, reading content, or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer file_info over list_files or read_file, nor does it give exclusions. This leaves the agent without explicit context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in the specified path within the workspace.
Args:
directory: Relative path to the directory (default is root of workspace).
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what it lists, but does not mention recursion behavior, hidden files, or error conditions. This leaves ambiguity about the tool's exact behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with an Args list, efficient and directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description covers the essential purpose and parameter, though it lacks some behavioral details that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that the 'directory' parameter is a 'Relative path' and that the default is 'root of workspace', which is more specific than the schema's default '.' and compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'files and directories' within a specified path in the workspace. It distinguishes from siblings like read_file (reads content) and search_files (searches), making it clear this is for enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives. It implies usage for listing directory contents but lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a text file.
Args:
file_path: Relative path to the file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and the file type (text), but does not disclose encoding, error handling, file size limits, or behavior for non-text files. No side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, composed of only two sentences with a brief Args block. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description covers the core action. However, it lacks context on edge cases, error behavior, and alternatives. For a simple read tool, it is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'Relative path' to the parameter, which is more specific than the schema's 'File Path'. However, it does not elaborate on path constraints, existence requirements, or accepted formats. With schema coverage at 0%, this is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read the contents of a text file' uses a specific verb and resource, clearly distinguishing it from siblings like list_files, file_info, and search_files. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, exclusions, or reference the sibling tools. The only hint is the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recursively search for files whose names contain the keyword.
Searches from the current working directory.
Args:
keyword: String to search for in filenames.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the search is recursive and starts from the current working directory, but omits important behavioral details such as whether hidden files are included, case sensitivity, or any side effects. While a search is intuitively read-only, the description does not explicitly confirm safety or resource implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with two sentences and an Args block that defines the only parameter. No unnecessary words or repetition; it efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and an output schema, the description covers the fundamental operation and parameter semantics. However, it lacks details about return value structure or filtering behaviors, and does not position the tool relative to siblings. The context signal indicates an output schema exists, so return format may be documented elsewhere, but the description itself is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a clear explanation for the 'keyword' parameter: 'String to search for in filenames.' This goes beyond the bare schema definition, which only specifies the type as string. The phrase 'contain the keyword' clarifies that it is a substring match, though it does not specify case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Recursively search for files whose names contain the keyword.' It specifies the target (files), the criterion (name contains keyword), and scope (recursive from current working directory). This distinguishes it from sibling tools like list_files or read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description does not mention sibling tools or preconditions for usage, and only states the operational context of searching from the current directory. It does not explain scenarios where this tool is preferred over list_files or read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0file_infolist_filesread_filesearch_filesScored across 4 tools
Each tool targets a distinct file operation: listing directory contents, reading file content, fetching metadata, and searching filenames. There is no overlap, so an agent can easily choose the right tool.
Three tools use the verb_noun pattern (list_files, read_file, search_files), but file_info is a noun phrase rather than a verb action. The naming is mostly consistent but has a minor deviation.
Four tools is a well-scoped number for a focused file management server. Each tool serves a clear purpose without unnecessary bloat.
The server only provides read-only operations (list, read, info, search). There are no tools for creating, editing, or deleting files, which are essential for a true file manager, leaving significant gaps.
Browse and manage files in your Moxt AI workspace from any MCP client.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Host your MCP tool over streamable HTTP in one command.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
