Ein Model Context Protocol (MCP)-Server, der KI-gestützte Funktionen zur Bearbeitung von Word-Dokumenten bietet. Dieser Server implementiert das MCP-Protokoll, um KI-Anwendungen das Erstellen, Bearbeiten und Verwalten von Word-Dokumenten durch natürliche Sprachinteraktionen zu ermöglichen.
Vollständige MCP-Protokollimplementierung
Erstellen und Verwalten von Word-Dokumenten
Rich-Text-Inhaltsmanipulation
Tabellenerstellung und -formatierung
Dokumentlayoutsteuerung
Verwaltung von Dokumentmetadaten
Echtzeitüberwachung des Dokumentstatus
Related MCP server: Word Document MCP Server
Node.js 14 oder höher
Microsoft Word (optional, für erweiterte Funktionen)
npx @puchunjie/doc-tools-mcpOder global installieren:
npm install -g @puchunjie/doc-tools-mcpZur Verwendung als Abhängigkeit in Ihrem Projekt:
npm install @puchunjie/doc-tools-mcpStarten Sie den MCP-Server:
npx @puchunjie/doc-tools-mcpDer Server startet standardmäßig auf Port 8765
Konfigurieren Sie Ihre KI-Anwendung (z. B. Cursor, VSCode) für die Verwendung des MCP-Servers:
http://localhost:8765Der Server stellt die folgenden MCP-Funktionen bereit:
create_document - Neues Word-Dokument erstellen
Parameter: Dateipfad (erforderlich), Titel, Autor
open_document - Öffnen Sie ein vorhandenes Word-Dokument
Parameter: Dateipfad (erforderlich)
add_paragraph - Einen Absatz zum Dokument hinzufügen
Parameter: Dateipfad (erforderlich), Text (erforderlich), Stil, Ausrichtung
add_table - Fügt dem Dokument eine Tabelle hinzu
Parameter: Dateipfad (erforderlich), Zeilen (erforderlich), Spalten (erforderlich), Überschriften, Daten
search_and_replace - Suchen und Ersetzen von Text im Dokument
Parameter: Dateipfad (erforderlich), Suchtext (erforderlich), Ersetzungstext (erforderlich), Groß-/Kleinschreibung beachten
set_page_margins - Seitenränder des Dokuments festlegen
Parameter: Dateipfad (erforderlich), oben, rechts, unten, links
get_document_info - Dokumentmetadaten abrufen
Parameter: Dateipfad (erforderlich)
Öffnen Sie die Cursor-Konfigurationsdatei ~/.cursor/mcp.json
Fügen Sie die folgende Konfiguration hinzu:
{
"mcpServers": {
"doc-tools-mcp": {
"command": "npx",
"args": [
"@puchunjie/doc-tools-mcp"
]
}
}
}
Oder für die lokale Entwicklungsversion:
{
"mcpServers": {
"doc-tools-mcp": {
"command": "node",
"args": [
"/path/to/your/doc-tools-mcp/dist/mcp-server.js"
]
}
}
}Nach der Konfiguration können Sie Word-Dokumente mithilfe natürlicher Sprache bearbeiten:
"Create a new document named report.docx"
"Add a heading 'Monthly Report' to report.docx"
"Insert a 4x3 table with sales data"Ähnliche Integrationsschritte gelten für andere Tools, die das MCP-Protokoll unterstützen. Informationen zu den spezifischen Konfigurationsschritten für den MCP-Server finden Sie in der Dokumentation Ihres Tools.
So erweitern oder ändern Sie diesen MCP-Server:
Klonen Sie das Repository:
git clone <repository-url>
cd doc-tools-mcpInstallieren Sie Abhängigkeiten:
npm installStarten Sie im Entwicklungsmodus:
npm run startFür die Produktion erstellen:
npm run buildNeue Methoden in src/services/DocumentService.ts hinzufügen
Neue Funktionen in src/mcp-server.ts registrieren
Aktualisieren Sie die Typdefinitionen nach Bedarf
Standardport: 8765 (konfigurierbar)
Unterstützte Dateitypen: .docx
Alle Dateipfade sollten absolut oder relativ zum aktuellen Arbeitsverzeichnis sein
MIT
Wenn Sie auf Probleme stoßen oder Verbesserungsvorschläge haben, senden Sie bitte ein Problem in unserem GitHub-Repository.
| 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
