Click on "Install 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., "@filemanager-mcp-server create a new React project structure"
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.
一个功能强大的文件管理 MCP 服务器，提供完整的文件和目录操作功能。
npm install -g filemanager-mcp-servernpm install filemanager-mcp-server在 Trae IDE 的 MCP 配置中添加：
{
"mcpServers": {
"filemanager": {
"command": "npx",
"args": [
"-y",
"filemanager-mcp-server"
]
}
}
}克隆仓库
git clone https://github.com/yourusername/filemanager-mcp-server.git进入项目目录
cd filemanager-mcp-server安装依赖
npm install{
"mcpServers": {
"filemanager": {
"command": "node",
"args": ["node_modules/filemanager-mcp-server/index.js"]
}
}
}配置完成后，您可以在 Trae IDE 中使用自然语言进行文件管理：
"创建一个新的配置文件 config.json"
"复制 README.md 到 docs 文件夹"
"搜索所有的 JavaScript 文件"
"批量删除所有临时文件"
"使用 Node.js 模板创建一个新的应用文件"
"在文件末尾追加日志信息，并创建备份"
"创建一个完整的 React 项目结构"
"只读取文件的第 10-20 行内容"
"使用自定义变量从 HTML 模板创建页面"
"以 append 模式编辑配置文件，不覆盖现有内容"
Related MCP server: filesystem-ops
create_file - 创建新文件
read_file - 读取文件内容
write_file - 写入文件内容
delete_file - 删除文件或文件夹
copy_file - 复制文件或文件夹
move_file - 移动或重命名文件
get_file_info - 获取文件详细信息
edit_file_advanced - 高级文件编辑（支持多种编辑模式、自动备份、编码选择）
read_file_advanced - 高级文件读取（支持按行读取、按字节读取、编码选择）
create_from_template - 从模板创建文件（支持变量替换）
create_project_structure - 创建项目目录结构（支持预定义和自定义结构）
list_directory - 列出目录内容
create_directory - 创建新目录
search_files - 搜索文件（支持通配符）
batch_read_files - 批量读取多个文件
batch_copy_files - 批量复制文件
batch_move_files - 批量移动文件
batch_delete_files - 批量删除文件
batch_create_files - 批量创建文件
{
"name": "create_file",
"arguments": {
"path": "config.json",
"content": "{\"name\": \"example\"}"
}
}{
"name": "read_file",
"arguments": {
"path": "config.json"
}
}{
"name": "search_files",
"arguments": {
"directory": "./src",
"pattern": "*.js",
"recursive": true
}
}{
"name": "batch_create_files",
"arguments": {
"files": [
{"path": "file1.txt", "content": "Content 1"},
{"path": "file2.txt", "content": "Content 2"}
]
}
}{
"name": "batch_copy_files",
"arguments": {
"sources": ["src/file1.js", "src/file2.js"],
"destination": "./backup",
"preserve_structure": false
}
}{
"name": "edit_file_advanced",
"arguments": {
"path": "config.json",
"content": "新的配置内容",
"encoding": "utf8",
"backup": true,
"mode": "overwrite"
}
}支持的编辑模式：
overwrite - 覆盖整个文件
append - 追加到文件末尾
prepend - 插入到文件开头
insert - 在指定位置插入（需要 position 参数）
{
"name": "create_from_template",
"arguments": {
"template": "nodejs",
"path": "./my-app.js",
"variables": {
"AUTHOR": "Your Name",
"PROJECT_NAME": "My Project",
"VERSION": "1.0.0"
}
}
}可用模板：
html5 - HTML5 页面模板
nodejs - Node.js 应用模板
python - Python 脚本模板
react-component - React 组件模板
styles - CSS 样式模板
readme - README 文档模板
{
"name": "create_project_structure",
"arguments": {
"basePath": "./my-project",
"template": "react"
}
}预定义项目结构：
nodejs - Node.js 项目结构
react - React 应用结构
python - Python 项目结构
express - Express.js 应用结构
{
"name": "read_file_advanced",
"arguments": {
"path": "large-file.txt",
"encoding": "utf8",
"lines": {
"start": 10,
"end": 20
}
}
}运行功能测试：
node example-usage.jsNode.js - 运行时环境
@modelcontextprotocol/sdk - MCP SDK
fs-extra - 文件系统操作
path - 路径处理
所有路径会被解析为绝对路径
创建文件时会自动创建必要的父目录
删除操作不可逆，请谨慎使用
支持 UTF-8 编码的文本文件
搜索功能支持通配符模式（* 匹配任意字符）
GitHub: filemanager-mcp-server
批量复制文件到目标目录
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes | 源文件路径列表 | |
| destination | Yes | 目标目录路径 | |
| preserve_structure | No | 是否保持原有目录结构 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It only states the basic action and omits crucial behaviors such as overwrite policy, error handling, or effects of the preserve_structure parameter.
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 a single short sentence, making it concise. However, it could be structured to include more details without losing conciseness.
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?
Given the absence of an output schema and annotations, the description is incomplete. It does not clarify return values, error cases, or behavioral nuances that a batch tool typically requires.
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?
All three parameters are described in the input schema (100% coverage). The description adds no additional meaning beyond the schema, which is the baseline for high 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 action (batch copy), resource (files), and destination (target directory). It differentiates from single-file copy (copy_file) and batch move (batch_move_files) by using 'copy' and 'batch'. However, it does not explicitly distinguish from similar batch tools.
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 usage guidance is provided. There is no indication of when to use this tool over alternatives like batch_move_files or copy_file, nor any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量创建文件
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | 要创建的文件列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description entirely fails to disclose behavioral traits like atomicity, overwrite behavior, or error handling beyond stating the operation.
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?
It is overly terse to the point of being uninformative, sacrificing clarity for brevity.
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?
Given no output schema and complex sibling tools, the description lacks details on return values, behavior, and context, making it insufficient.
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?
Schema coverage is 100% with parameter descriptions in the schema. The description adds no value beyond the schema, meeting the baseline.
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?
Description '批量创建文件' is a direct translation of the tool name 'batch_create_files', offering no additional information. It fails to distinguish from siblings like 'create_file' or 'batch_copy_files'.
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 guidance is provided on when to use this tool versus alternatives such as single creation or other batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量删除文件或文件夹
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | 要删除的文件或文件夹路径列表 | |
| force | No | 是否强制删除（忽略错误） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It merely states the function without mentioning important behaviors such as: whether deletion is permanent, if folders are deleted recursively, what happens on error, or how the 'force' parameter affects execution. This is insufficient transparency for a destructive operation.
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—just six Chinese characters. While brevity is positive, it sacrifices essential details. A minimally adequate description should include more context, such as the effect of the 'force' parameter or a note about recursive deletion. The structure is a single sentence, which is acceptable but lacks front-loading of critical information.
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?
Given the tool's complexity (batch deletion with optional force) and the absence of an output schema, the description is incomplete. It does not explain return values, error handling, or side effects like permanent data loss. A more complete description would cover these aspects to properly inform the agent.
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 input schema has 100% description coverage for both parameters ('paths' and 'force'), so the schema already explains their meaning. The tool description adds no additional context beyond the schema. The baseline score is 3, as the description does not detract but also does not enhance understanding of parameters.
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 purpose: batch deletion of files or folders. It distinguishes this from sibling operations like batch_copy_files, batch_create_files, and batch_move_files by specifying deletion. The verb 'delete' and resource 'files or folders' are specific and unambiguous.
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 over alternatives (e.g., delete_file for single files, or other batch operations). It does not mention prerequisites, conditions, or when not to use it. This leaves the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量移动文件到目标目录
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes | 源文件路径列表 | |
| destination | Yes | 目标目录路径 | |
| preserve_structure | No | 是否保持原有目录结构 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as whether files are overwritten, error handling, or atomicity. For a mutation tool, this is insufficient.
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?
A single sentence that is efficient and front-loaded. However, it could include more context without becoming verbose.
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?
Given the complexity of a batch move operation and no output schema, the description omits critical details like behavior on existing files, partial success scenarios, and error handling.
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?
Input schema covers all three parameters with descriptions (100% coverage). The tool description adds no extra meaning beyond the schema, so baseline score applies.
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 it moves files in batch to a target directory. However, it does not differentiate from sibling tools like batch_copy_files or move_file, relying on the tool name to convey the batch aspect.
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 guidance on when to use this tool versus alternatives like batch_copy_files or move_file. With 19 siblings, explicit guidance is critical but missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量读取多个文件的内容
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | 要读取的文件路径列表 | |
| encoding | No | 文件编码 | utf8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. It only states 'reads content' with no details on concurrency, error handling, permissions, or return format. This is insufficient for a batch operation.
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 a single, concise sentence that directly states the tool's purpose. No wasted words, appropriately sized for a simple parameter set.
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?
With two parameters and no output schema, the description barely covers the tool's purpose. It lacks details on return behavior, failure handling, or operational scope, making it minimally adequate.
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?
Schema coverage is 100% with descriptions for both parameters (paths, encoding). The description adds no extra meaning beyond the schema, meeting the baseline expectation.
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 '批量读取多个文件的内容' specifies the action (batch read) and resource (multiple files), which is clear. However, it does not differentiate from sibling tools like 'read_file' or 'read_file_advanced', which serve single-file reads, missing explicit sibling distinction.
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 guidance on when to use this tool versus alternatives (e.g., single-file reads). Missing context on appropriate scenarios, prerequisites, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
复制文件或文件夹
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 源文件或文件夹路径 | |
| destination | Yes | 目标路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description gives no behavioral details such as whether overwriting occurs, metadata preservation, or symlink handling. For a copy tool, these are critical unmentioned aspects.
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 short (one phrase), which is concise but lacks structure. It front-loads the core action but omits necessary details, making it borderline between efficient and under-specified.
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?
Given the tool's complexity (copy operation with two string parameters and no output schema), the description is severely incomplete. It fails to address key aspects like overwrite behavior, recursion, or interaction with sibling tools.
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?
Schema description coverage is 100% with basic descriptions for source and destination. The tool description adds no further meaning beyond what the schema already provides, meeting the baseline for high 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 it copies files or folders, specifying the verb (copy) and resource (file or folder). It distinguishes from siblings like batch_copy_files (batch) and move_file (move).
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 guidance is provided on when to use this tool versus alternatives like batch_copy_files or move_file. The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建目录
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 目录路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether parent directories are created, what happens if the directory already exists, or required permissions. This is a significant gap for a mutation tool.
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 (two characters) but lacks structure and does not front-load key information. It is underspecified, not efficiently informative.
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 tool with one parameter and no output schema, the description should at least mention behavior on success, failure, or conflicts. The current description is incomplete, leaving the agent without critical 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 input schema has 100% description coverage for the single parameter 'path' (described as '目录路径'). However, the tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 '创建目录' is a direct translation of the tool name 'create_directory', providing no additional information. It is a tautology that restates the name without explaining the action or distinguishing it from sibling tools like 'create_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 guidance is given on when to use this tool versus alternatives such as 'create_file' or 'batch_create_files'. The description lacks context for usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建新文件
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件路径 | |
| content | No | 文件内容（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention whether the tool overwrites existing files, creates intermediate directories, or is idempotent. The single phrase provides no behavioral context.
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 short but at the expense of necessary detail. It does not effectively earn its place as it lacks operational context. Overly minimal for a tool with multiple siblings.
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?
Given no output schema and no annotations, the description should compensate for behavioral and usage information. It fails to cover essential aspects like overwrite behavior, path handling, or content defaults, leaving the agent underinformed.
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?
Schema description coverage is 100% for both parameters (path and content), so schema already provides meaning. The description adds no additional explanation beyond what is in the schema, meeting the baseline of 3.
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?
Description '创建新文件' translates to 'Create new file', clearly stating verb and resource. However, it lacks differentiation from sibling tools like batch_create_files or write_file, and does not specify that it creates a single file with optional content.
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 guidance on when to use this tool versus alternatives (e.g., batch_create_files for multiple files, create_from_template for templates). The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从模板创建文件
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | 模板名称或模板文件路径 | |
| path | Yes | 目标文件路径 | |
| variables | No | 模板变量（键值对） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose critical behaviors like overwrite policies, supported file types, or template source location. For a mutation tool, this is insufficient transparency.
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 but lacks structure and substance. While brief, it sacrifices essential information, making it merely adequate for a simple tool.
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?
Given the complexity of nested variables and lack of output schema, the description is incomplete. It fails to explain template behavior, variable substitution, or expected outcomes, which are necessary for correct usage.
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?
Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 'Create file from template' conveys the basic action but lacks specificity. It does not detail what a template is or how it differs from creating a file directly, which is ambiguous given sibling tools like create_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 guidance is provided on when to use this tool versus alternatives such as create_file, batch_create_files, or copy_file. The absence of context for template-based creation limits effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建项目目录结构
| Name | Required | Description | Default |
|---|---|---|---|
| basePath | Yes | 项目根目录路径 | |
| structure | No | 目录结构定义（嵌套对象，文件用字符串表示内容，目录用对象表示） | |
| template | No | 预定义的项目模板类型 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether existing files are overwritten, permissions required, or side effects. The description is too brief to cover these aspects.
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 a single short sentence, very concise. However, it could include more useful information without becoming verbose.
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?
Given the complexity of the tool (nested structure parameter, template enum) and lack of output schema, the description is too minimal. It does not explain how structure or template work together, nor the return value.
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?
Schema coverage is 100%, so the description adds no additional meaning beyond what the schema already provides. The baseline score of 3 is appropriate.
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 (创建/creates) and resource (project directory structure). It distinguishes from sibling tools like create_directory and create_file which target individual items, but lacks explicit differentiation.
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 guidance is provided on when to use this tool versus alternatives like create_from_template or batch_create_files. The agent must infer usage from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除文件或文件夹
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 要删除的文件或文件夹路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but offers minimal behavioral info. It does not disclose whether deletion is permanent, reversible, or requires permissions, nor any side effects. This is a critical gap for a destructive operation.
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 a single short sentence, which is under-specified. It lacks necessary details for a destructive tool, making it inefficient rather than concise.
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?
Given the lack of annotations and output schema, the description is incomplete. It fails to cover behavioral expectations, return values, or usage context, which are essential for a delete operation.
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?
Schema coverage is 100% and the parameter description '要删除的文件或文件夹路径' is sufficient. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 'delete' and resource 'file or folder', making the tool's purpose unambiguous. However, it does not explicitly differentiate from the sibling tool 'batch_delete_files', though the singular form implies single file deletion.
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 guidance is provided on when to use this tool versus alternatives like 'batch_delete_files' or 'move_file'. The description lacks any context about selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
高级文件编辑功能（支持部分编辑、多编码、备份等）
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件路径 | |
| content | Yes | 要写入的内容 | |
| encoding | No | 文件编码 | utf8 |
| backup | No | 是否创建备份文件 | |
| mode | No | 编辑模式 | overwrite |
| position | No | 插入位置（仅在insert模式下使用） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions backup support but does not disclose that the default mode is 'overwrite' which can destroy existing content without warning. The tool's potential destructive behavior is not transparent.
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 a single, well-structured sentence that front-loads the purpose and appends key features in parentheses. No unnecessary words.
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?
Given the tool's complexity (6 parameters, multiple modes, encoding options, backup), the description is minimal but the schema covers details. It does not explain the behavior of different modes or provide warnings, but for a tool with a rich schema, it is adequate.
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?
Schema coverage is 100%, so the description adds little extra meaning. The term 'partial editing' relates to the mode parameter but does not elaborate on the modes or provide usage details beyond the schema. Baseline 3 applies.
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 identifies it as an advanced file editing tool with features like partial editing, multiple encodings, and backup. It distinguishes from basic write_file by labeling it 'advanced', but could be more specific about the exact capabilities.
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 implies this tool should be used when advanced editing features are needed, but it does not explicitly state when to use it over alternatives like write_file or read_file_advanced. No exclusion criteria or specific context guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取文件或文件夹属性信息
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件或文件夹路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It only states 'get attribute info' without disclosing what attributes are returned, permission requirements, or behavior for different file types (e.g., symlinks, directories).
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?
Single sentence clearly conveys purpose with no extraneous information. 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?
Given the tool retrieves file properties, description is too minimal. Lacks details on return values (e.g., size, type, permissions) and does not compensate for missing output schema. Sibling tool context is not leveraged.
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?
Schema has 100% coverage with one parameter 'path' described as '文件或文件夹路径'. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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?
Description clearly states '获取文件或文件夹属性信息' (get file or folder attribute information), which specifies the verb and resource. It distinguishes from sibling tools that perform copy, create, delete, read content, or write operations.
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 guidance on when to use this tool versus alternatives. It does not mention any prerequisites, limitations, or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出目录内容
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 目录路径 | |
| detailed | No | 是否显示详细信息（大小、修改时间等） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It does not disclose behaviors like recursion depth, handling of hidden files, sorting, or permissions. Only basic purpose is stated.
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?
Description is a single sentence, concise and front-loaded. However, it omits useful information that could fit in the same length, slightly reducing effectiveness.
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?
No output schema exists, yet description fails to explain return format (e.g., list of names or details). Missing behavioral details like recursion or hidden files. Incomplete for a directory listing tool.
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?
Schema description coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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?
Description '列出目录内容' clearly states the tool lists directory contents. However, it does not differentiate from sibling tools like 'get_file_info' or 'search_files', which have distinct purposes.
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 guidance provided on when to use this tool versus alternatives such as 'read_file' or 'search_files'. Absence of usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
移动或重命名文件/文件夹（剪切功能）
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 源文件或文件夹路径 | |
| destination | Yes | 目标路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive 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?
单句描述，前置核心功能，无冗余。
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?
缺少返回值、错误条件、确认信息等，对于无输出schema的工具，描述不够完整。
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?
参数描述来自schema，描述未额外补充含义，Schema覆盖率100%基线为3。
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?
明确说明移动或重命名文件/文件夹（剪切功能），动词+资源，与复制和批量操作区分。
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?
未说明何时使用此工具而非其他工具（如batch_move_files），无排除条件。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取文件内容
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states it reads files but does not disclose read-only behavior, required permissions, potential side effects, or limitations (e.g., file size, encoding).
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 short (four characters), but it is front-loaded and efficient. However, it sacrifices detail for brevity, failing to earn its place with substantive information.
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 read tool with one parameter and no output schema, the description omits critical details like return format (e.g., string, binary), error behavior, and file encoding. It is inadequately complete for an agent to reliably use.
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?
Schema description coverage is 100% (one parameter 'path' with description '文件路径'). The description adds no meaning beyond the schema. Baseline is 3, and no additional value is provided.
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 '读取文件内容' translates to 'read file content', which clearly states the verb and resource, but lacks differentiation from sibling tools like 'read_file_advanced' or 'batch_read_files'. It does not specify scope (e.g., text or binary, size limits).
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 guidance on when to use this tool vs alternatives. No mention of prerequisites, file type restrictions, or scenarios where other tools (e.g., read_file_advanced) would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
高级文件读取功能（支持多编码、部分读取等）
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件路径 | |
| encoding | No | 文件编码 | utf8 |
| start | No | 开始位置（字节） | |
| length | No | 读取长度（字节） | |
| lines | No | 按行读取范围 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value by mentioning multi-encoding and partial reading support beyond the schema, but it does not disclose error behavior, permissions needed, or potential side effects. With no annotations, the burden on description is higher, yet it remains minimal.
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 a single, short sentence that conveys the core purpose and key differentiators. No unnecessary words; every part 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?
Given 5 parameters and no output schema or annotations, the description is somewhat lacking. It does not explain return format, error cases, or constraints on parameter combinations. It captures the essence but is not fully complete.
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?
Schema coverage is 100%, so the description does not need to add much. It summarizes parameters (multiple encodings, partial reading) but adds no further semantic meaning beyond what the schema provides.
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 is an advanced file reading function supporting multiple encodings and partial reading. It uses a specific verb and resource, and effectively distinguishes itself from the simpler sibling '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?
The context of sibling tools implies this is for advanced scenarios, but no explicit when-to-use or when-not-to-use guidance is provided. It is clear but lacks exclusions or alternatives direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索文件
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | 搜索目录 | |
| pattern | Yes | 搜索模式（文件名模式） | |
| recursive | No | 是否递归搜索子目录 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'search files' without disclosing any behavioral traits, such as whether it is read-only, if it modifies anything, performance implications, or authentication requirements. The tool is likely read-only, but this is not explicitly stated.
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 at 4 characters, but it is under-specified. It does not include any additional information beyond the tool name's translation, making it insufficient for an agent to fully understand the tool's purpose. Conciseness should not come at the cost of completeness.
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?
Given the tool has 3 parameters and no output schema, the description is incomplete. It does not explain what the tool returns, how results are formatted, or any side effects. The agent would lack critical context for using the tool effectively.
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?
Schema description coverage is 100%, with all three parameters having descriptions in the schema. The tool description adds no extra meaning beyond what the schema already provides. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 '搜索文件' translates to 'search files', which clearly states the action and resource. However, it is essentially a translation of the tool name and does not provide additional specificity or distinguish it from sibling tools like 'list_directory' or 'read_file'. It is not a tautology per se but lacks the detail expected for a clear purpose.
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 are no usage guidelines provided. The description does not indicate when to use this tool over alternatives, nor does it mention prerequisites, limitations, or when not to use it. This leaves the agent without guidance on appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
写入或编辑文件内容
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件路径 | |
| content | 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 does not disclose whether the tool overwrites existing files, creates missing directories, or supports append. The phrase '写入或编辑' implies full content replacement, but this is not explicit.
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?
Extremely short (one sentence), which is concise but at the cost of missing crucial details. The description is front-loaded with the primary action but lacks structure (no sections or examples).
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?
Given the complexity (write operation, many sibling tools) and lack of output schema, the description is insufficient. It does not explain return values, error handling, or how it differs from similar tools like 'create_file' or 'copy_file'.
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?
Schema coverage is 100% with descriptions for both parameters. The description adds no further detail beyond the schema (e.g., encoding, behavior for large content). Baseline 3 is appropriate as the schema already documents the parameters.
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 writes or edits file content, which is a specific verb-resource pair. It distinguishes from siblings like 'create_file' (which likely creates empty files) and 'edit_file_advanced' (which may offer more granular editing), but lacks explicit differentiation. The Chinese language may reduce clarity for English-only agents.
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 guidance on when to use this tool vs. siblings (e.g., create_file, edit_file_advanced). No mention of prerequisites, alternatives, or contexts where this tool is inappropriate.
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. Dates show when Glama detected each change.
v1.1.0batch_copy_filesbatch_create_filesbatch_delete_filesbatch_move_filesbatch_read_filescopy_filecreate_directorycreate_filecreate_from_templatecreate_project_structuredelete_fileedit_file_advancedget_file_infolist_directorymove_fileread_fileread_file_advancedsearch_fileswrite_fileTools are mostly distinct with clear purposes. Minor overlap exists between write_file and edit_file_advanced, but descriptions effectively differentiate them.
All tools follow a consistent verb_noun pattern in snake_case, with some verb_phrase variations that remain predictable.
19 tools cover a wide range of file operations without being excessive, well-scoped for a file manager server.
Core CRUD operations are covered with batch and advanced variants. Minor gaps like file compression or overwrite options are absent but not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browse and manage files in your Moxt AI workspace from any MCP client.
MCP server for generating rough-draft project plans from natural-language prompts.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server for OFAC screening, EDD memos, exposure forecasts, queues, and reports.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/leemwood/filemanager-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
