一个模型上下文协议 (MCP) 服务器，提供 AI 驱动的 Word 文档操作功能。该服务器实现了 MCP 协议，使 AI 应用程序能够通过自然语言交互来创建、编辑和管理 Word 文档。
完整的 MCP 协议实现
Word文档的创建和管理
富文本内容操作
表格创建和格式化
文档布局控制
文档元数据管理
实时文档状态监控
Related MCP server: Word Document MCP Server
Node.js 14 或更高版本
Microsoft Word（可选，用于高级功能）
npx @puchunjie/doc-tools-mcp或者全局安装：
npm install -g @puchunjie/doc-tools-mcp用作项目中的依赖项：
npm install @puchunjie/doc-tools-mcp启动 MCP 服务器：
npx @puchunjie/doc-tools-mcp服务器默认在 8765 端口启动
配置您的 AI 应用程序（例如 Cursor、VSCode）以使用 MCP 服务器：
http://localhost:8765该服务器提供以下MCP功能：
create_document创建一个新的Word文档
参数：filePath（必需）、title、author
open_document打开现有的Word文档
参数：filePath（必需）
add_paragraph - 向文档添加一个段落
参数：filePath（必需）、text（必需）、style、alignment
add_table向文档添加表格
参数：filePath（必需）、rows（必需）、cols（必需）、headers、data
search_and_replace - 查找并替换文档中的文本
参数：filePath（必需）、searchText（必需）、replaceText（必需）、matchCase
set_page_margins - 设置文档页边距
参数：filePath（必需）、top、right、bottom、left
get_document_info - 获取文档元数据
参数：filePath（必需）
打开 Cursor 配置文件~/.cursor/mcp.json
添加以下配置：
{
"mcpServers": {
"doc-tools-mcp": {
"command": "npx",
"args": [
"@puchunjie/doc-tools-mcp"
]
}
}
}
或者对于本地开发版本：
{
"mcpServers": {
"doc-tools-mcp": {
"command": "node",
"args": [
"/path/to/your/doc-tools-mcp/dist/mcp-server.js"
]
}
}
}配置完成后就可以使用自然语言来操作Word文档了：
"Create a new document named report.docx"
"Add a heading 'Monthly Report' to report.docx"
"Insert a 4x3 table with sales data"类似的集成步骤适用于其他支持 MCP 协议的工具。有关具体的 MCP 服务器配置步骤，请参阅您工具的文档。
要扩展或修改此 MCP 服务器：
克隆存储库：
git clone <repository-url>
cd doc-tools-mcp安装依赖项：
npm install以开发模式启动：
npm run start为生产而构建：
npm run build在src/services/DocumentService.ts中添加新方法
在src/mcp-server.ts中注册新函数
根据需要更新类型定义
默认端口：8765（可配置）
支持的文件类型：.docx
所有文件路径应为绝对路径或相对于当前工作目录的路径
麻省理工学院
如果您遇到任何问题或有改进建议，请在我们的 GitHub 存储库上提交问题。
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | ||
| text | Yes | ||
| style | No | ||
| alignment | No |
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 | ||
| rows | Yes | ||
| cols | Yes | ||
| headers | No | ||
| data | No |
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 | ||
| title | No | ||
| author | No |
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 |
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 |
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 | ||
| searchText | Yes | ||
| replaceText | Yes | ||
| matchCase | No |
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 | ||
| top | No | ||
| right | No | ||
| bottom | No | ||
| left | No |
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.
add_paragraphadd_tablecreate_documentget_document_infoopen_documentsearch_and_replaceset_page_marginsScored across 7 tools
The tools have clearly distinct purposes targeting different document operations: creating documents, opening them, adding content (paragraphs/tables), modifying content (search/replace), adjusting layout (margins), and retrieving metadata. There is minor potential overlap between 'create_document' and 'open_document' if 'open' implies creation, but they are generally distinct.
All tool names follow a consistent verb_noun pattern with snake_case throughout (e.g., add_paragraph, create_document, get_document_info). There are no deviations in naming conventions, making the set predictable and readable.
With 7 tools, this is a well-scoped set for a document management server. It covers core operations without being overly sparse or bloated, aligning with typical tool counts for focused domains like this.
The tools cover creation, opening, content addition, basic editing, layout adjustment, and info retrieval, but there are notable gaps. Missing operations include updating or deleting documents, managing document versions, or handling more complex formatting, which could limit agent workflows in a document management context.
Create and manage documents, spreadsheets, and presentations from your AI assistant.
Create real Word .docx files from your AI chat: proposals, quotes, contracts, statements of work.
Real Word and Excel for agents: open your .docx/.xlsm, read, propose, apply, get it back intact.
AI-powered PDF tools: fill forms via natural language
