AI 기반 Word 문서 조작 기능을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 MCP 프로토콜을 구현하여 AI 애플리케이션이 자연어 상호작용을 통해 Word 문서를 생성, 편집 및 관리할 수 있도록 지원합니다.
전체 MCP 프로토콜 구현
Word 문서 생성 및 관리
서식 있는 텍스트 콘텐츠 조작
표 생성 및 서식 지정
문서 레이아웃 제어
문서 메타데이터 관리
실시간 문서 상태 모니터링
Related MCP server: Word Document MCP Server
Node.js 14 이상
Microsoft Word(선택 사항, 고급 기능용)
지엑스피1
또는 전역적으로 설치:
npm install -g @puchunjie/doc-tools-mcp프로젝트의 종속성으로 사용하려면 다음을 수행하세요.
npm install @puchunjie/doc-tools-mcpMCP 서버를 시작합니다.
npx @puchunjie/doc-tools-mcp서버는 기본적으로 포트 8765에서 시작됩니다.
MCP 서버를 사용하도록 AI 애플리케이션(예: Cursor, VSCode)을 구성합니다.
http://localhost:8765서버는 다음과 같은 MCP 기능을 제공합니다.
create_document - 새 Word 문서 만들기
매개변수: filePath(필수), 제목, 작성자
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/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 buildsrc/services/DocumentService.ts 에 새로운 메서드를 추가합니다.
src/mcp-server.ts 에 새로운 함수를 등록합니다.
필요에 따라 유형 정의를 업데이트합니다.
기본 포트: 8765(구성 가능)
지원되는 파일 형식: .docx
모든 파일 경로는 현재 작업 디렉토리를 기준으로 절대 경로이거나 상대 경로여야 합니다.
MIT
문제가 발생하거나 개선에 대한 제안 사항이 있는 경우 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
