Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona capacidades de manipulación de documentos de Word basadas en IA. Este servidor implementa el protocolo MCP para que las aplicaciones de IA puedan crear, editar y gestionar documentos de Word mediante interacciones de lenguaje natural.
Implementación completa del protocolo MCP
Creación y gestión de documentos de Word
Manipulación de contenido de texto enriquecido
Creación y formato de tablas
Control del diseño del documento
Gestión de metadatos de documentos
Monitoreo del estado de los documentos en tiempo real
Related MCP server: Word Document MCP Server
Node.js 14 o superior
Microsoft Word (opcional, para funciones avanzadas)
npx @puchunjie/doc-tools-mcpO instalar globalmente:
npm install -g @puchunjie/doc-tools-mcpPara utilizar como dependencia en su proyecto:
npm install @puchunjie/doc-tools-mcpInicie el servidor MCP:
npx @puchunjie/doc-tools-mcpEl servidor se iniciará en el puerto 8765 de forma predeterminada
Configure su aplicación de IA (por ejemplo, Cursor, VSCode) para usar el servidor MCP:
http://localhost:8765El servidor proporciona las siguientes funciones MCP:
create_document - Crea un nuevo documento de Word
Parámetros: filePath (obligatorio), título, autor
open_document - Abre un documento de Word existente
Parámetros: filePath (obligatorio)
add_paragraph - Agrega un párrafo al documento
Parámetros: filePath (obligatorio), texto (obligatorio), estilo, alineación
add_table - Agrega una tabla al documento
Parámetros: filePath (obligatorio), filas (obligatorio), columnas (obligatorio), encabezados, datos
search_and_replace - Buscar y reemplazar texto en el documento
Parámetros: filePath (obligatorio), searchText (obligatorio), replaceText (obligatorio), matchCase
set_page_margins - Establecer los márgenes de página del documento
Parámetros: filePath (obligatorio), arriba, derecha, abajo, izquierda
get_document_info - Obtener metadatos del documento
Parámetros: filePath (obligatorio)
Abra el archivo de configuración del cursor ~/.cursor/mcp.json
Agregue la siguiente configuración:
{
"mcpServers": {
"doc-tools-mcp": {
"command": "npx",
"args": [
"@puchunjie/doc-tools-mcp"
]
}
}
}
O para la versión de desarrollo local:
{
"mcpServers": {
"doc-tools-mcp": {
"command": "node",
"args": [
"/path/to/your/doc-tools-mcp/dist/mcp-server.js"
]
}
}
}Después de la configuración, puede utilizar lenguaje natural para manipular documentos de Word:
"Create a new document named report.docx"
"Add a heading 'Monthly Report' to report.docx"
"Insert a 4x3 table with sales data"Se aplican pasos de integración similares a otras herramientas compatibles con el protocolo MCP. Consulte la documentación de su herramienta para conocer los pasos específicos de configuración del servidor MCP.
Para ampliar o modificar este servidor MCP:
Clonar el repositorio:
git clone <repository-url>
cd doc-tools-mcpInstalar dependencias:
npm installIniciar en modo de desarrollo:
npm run startConstruir para producción:
npm run buildAgregar nuevos métodos en src/services/DocumentService.ts
Registrar nuevas funciones en src/mcp-server.ts
Actualice las definiciones de tipos según sea necesario
Puerto predeterminado: 8765 (configurable)
Tipos de archivos admitidos: .docx
Todas las rutas de archivos deben ser absolutas o relativas al directorio de trabajo actual
Instituto Tecnológico de Massachusetts (MIT)
Si encuentra algún problema o tiene sugerencias para mejorar, envíe un problema en nuestro repositorio de 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
