模型上下文协议 (MCP) 服务器实现通过标准化接口提供文件系统操作。
MCP 文件服务器使 AI 模型能够通过标准化 API 在本地文件系统上执行文件操作。它使用模型上下文协议SDK 构建，并提供用于读取、创建和列出文件的工具。
Related MCP server: filesystem-mcp-server
创建文件：创建具有指定内容的新文件
读取文件：读取现有文件的内容
列出目录内容：列出文件和目录的详细信息
性能监控：内置 Sentry 集成，用于错误跟踪和性能监控
npm install启动 MCP 文件服务器：
node src/index.js服务器使用 MCP 协议通过 stdin/stdout 进行通信。
使用提供的内容在指定路径创建一个新文件。
参数：
filePath ：应创建文件的路径
content ：写入文件的内容
返回：
包含文件路径和大小信息的成功消息
读取指定路径下的文件内容。
参数：
filePath ：要读取的文件的路径
返回：
文件内容
列出指定路径下的文件和目录。
参数：
path ：列出内容的目录路径
返回：
包含文件名、大小和类型的 Markdown 表
SENTRY_DSN ：用于错误跟踪的 Sentry 数据源名称（可选）
@modelcontextprotocol/sdk ：MCP SDK 包
zod ：模式验证
@sentry/node ：错误跟踪和性能监控
通过 MCP 协议调用这些工具的示例：
{
"name": "createfile",
"params": {
"filePath": "example/test.txt",
"content": "Hello, world!"
}
}{
"name": "readfile",
"params": {
"filePath": "example/test.txt"
}
}{
"name": "listfiles",
"params": {
"path": "example"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content to write to the file | |
| filePath | Yes | Path where the file should be created |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| filePath | Yes | Path to the file to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0createfilelistfilesreadfileScored across 3 tools
The three tools have clearly distinct purposes: createfile for creating files, listfiles for listing files, and readfile for reading files. There is no overlap or ambiguity between these operations, making it easy for an agent to select the right tool for each task.
All tool names follow a consistent verb_noun pattern (createfile, listfiles, readfile) with no deviations. The naming is uniform and predictable, using lowercase letters and clear action-object combinations throughout.
With only three tools, the server feels thin for a file management domain, as it lacks essential operations like update, delete, or write to files. While the count is minimal, it covers basic CRUD aspects but leaves notable gaps in functionality.
The tool set is significantly incomplete for file management, missing critical operations such as updatefile, deletefile, and writefile. This creates dead ends for agents trying to perform common file workflows, leading to potential failures in tasks requiring modification or deletion.
Securely search and manage workspace context files for AI agents and teams.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Browse and manage files in your Moxt AI workspace from any MCP client.
