Provides the runtime environment for the MCP server, required as a prerequisite (version 14 or higher)
Click on "Deploy 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., "@doc-tools-mcp create a new document named quarterly_report.docx with title 'Q3 Results'"
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.
A Model Context Protocol (MCP) server that provides AI-powered Word document manipulation capabilities. This server implements the MCP protocol to enable AI applications to create, edit, and manage Word documents through natural language interactions.
Full MCP protocol implementation
Word document creation and management
Rich text content manipulation
Table creation and formatting
Document layout control
Document metadata management
Real-time document state monitoring
Related MCP server: Word Document MCP Server
Node.js 14 or higher
Microsoft Word (optional, for advanced features)
npx @puchunjie/doc-tools-mcpOr install globally:
npm install -g @puchunjie/doc-tools-mcpFor use as a dependency in your project:
npm install @puchunjie/doc-tools-mcpStart the MCP server:
npx @puchunjie/doc-tools-mcpThe server will start on port 8765 by default
Configure your AI application (e.g., Cursor, VSCode) to use the MCP server:
http://localhost:8765The server provides the following MCP functions:
create_document - Create a new Word document
Parameters: filePath (required), title, author
open_document - Open an existing Word document
Parameters: filePath (required)
add_paragraph - Add a paragraph to the document
Parameters: filePath (required), text (required), style, alignment
add_table - Add a table to the document
Parameters: filePath (required), rows (required), cols (required), headers, data
search_and_replace - Find and replace text in the document
Parameters: filePath (required), searchText (required), replaceText (required), matchCase
set_page_margins - Set document page margins
Parameters: filePath (required), top, right, bottom, left
get_document_info - Get document metadata
Parameters: filePath (required)
Open the Cursor configuration file ~/.cursor/mcp.json
Add the following configuration:
{
"mcpServers": {
"doc-tools-mcp": {
"command": "npx",
"args": [
"@puchunjie/doc-tools-mcp"
]
}
}
}
Or for local development version:
{
"mcpServers": {
"doc-tools-mcp": {
"command": "node",
"args": [
"/path/to/your/doc-tools-mcp/dist/mcp-server.js"
]
}
}
}After configuration, you can use natural language to manipulate Word documents:
"Create a new document named report.docx"
"Add a heading 'Monthly Report' to report.docx"
"Insert a 4x3 table with sales data"Similar integration steps apply to other tools that support the MCP protocol. Consult your tool's documentation for specific MCP server configuration steps.
To extend or modify this MCP server:
Clone the repository:
git clone <repository-url>
cd doc-tools-mcpInstall dependencies:
npm installStart in development mode:
npm run startBuild for production:
npm run buildAdd new methods in src/services/DocumentService.ts
Register new functions in src/mcp-server.ts
Update type definitions as needed
Default port: 8765 (configurable)
Supported file types: .docx
All file paths should be absolute or relative to the current working directory
MIT
If you encounter any issues or have suggestions for improvements, please submit an issue on our 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.
AI-powered PDF tools: fill forms via natural language
Collaborative word processor you can use with your agent.
