Which integrations are available for this server?

Enables integration with LangChain workflows for generating A3 landscape comparison tables and A4 portrait specification documents from structured JSON data. Provides HTTP REST API integration for LangFlow workflows to generate Word documents (comparison tables and specifications) from structured JSON input via HTTP endpoints.

How do I use docx-comparison-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@docx-comparison-mcp generate a comparison table for the updated safety regulations document" 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.

en es ja ko ru zh

docx-comparison-mcp

by bailangcheng818

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

docx-comparison-mcp

A3 Landscape Old/New Comparison Table / A4 Portrait Specification Word Document Generation MCP Server

A local MCP server that can be called from any AI framework such as Dify, LangFlow, LangChain, or Claude Desktop.

Design Philosophy: GET schema → POST generate

It adopts the same "get schema first, then generate" pattern as excel-mcp.

However, there is a fundamental difference from excel-mcp:

	excel-mcp	docx-mcp
Schema Origin	Reads Excel file header row at runtime (dynamic)	Fixed output format at compile time (static)
"Write Destination"	Fixed Excel file (always the same path)	New generation every time (new document per PDF upload)
Append Concept	Yes (appends to existing rows)	No (1 PDF = 1 new docx)

Positioning in Dify workflows:

[HTTP ノード] GET /schema/comparison
     ↓ prompt_context（列定義の代わりに出力フォーマット定義）
[LLM ノード] アップロードされた PDF を Gemini が読む + schema context を注入
     ↓ { doc_title, sections: [...] } の JSON
[HTTP ノード] POST /generate  { spec: { ... } }
     ↓ download_url
[End]

The prompt_context field is formatted to be pasted directly into the system prompt of a Dify LLM node.

Features

A3 landscape, Old/New/Remarks 3-column format (Old/New Comparison Table)
A4 portrait, Cover page/Revision history table/Body (Specification)
Red text (changes/additions)
Blue underlined Word comment anchors
Multi-section support (cover page, revision history, individual clauses)
stdio mode (for Claude Desktop / Claude Code)
HTTP mode (for Dify / LangFlow)

Setup

# 1. 依存パッケージのインストール
npm install

# 2. テスト実行
npm test
# → test-output.docx が生成されます

# 3a. MCP (stdio) モード起動 — Claude Desktop / Claude Code 向け
npm start

# 3b. HTTP モード起動 — Dify / LangFlow / REST 向け
npm run start:http
# → http://localhost:3456 で起動

Registration to Claude Desktop

Add to ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "docx-comparison": {
      "command": "node",
      "args": ["/absolute/path/to/docx-mcp/src/index.js"],
      "env": {
        "OUTPUT_DIR": "/Users/yourname/Desktop/docx-output"
      }
    }
  }
}

List of Endpoints

Method	Path	Description
`GET`	`/health`	Server health check
`GET`	`/schema`	API documentation (static)
`GET`	`/schema/comparison`	Schema for LLM injection for Old/New Comparison Table
`GET`	`/schema/manual`	Schema for LLM injection for Specification
`POST`	`/generate`	Generate Old/New Comparison Table (local save)
`POST`	`/generate/download`	Generate Old/New Comparison Table (direct file stream)
`POST`	`/generate/manual`	Generate Specification (local save)
`POST`	`/generate/manual/download`	Generate Specification (direct file stream)

GET /schema/comparison — Old/New Comparison Table Schema

Returns the format definition to be injected into the LLM. Please paste the prompt_context field into the system prompt of the Dify LLM node.

Response Overview:

{
  "doc_type": "comparison",
  "description": "新旧比較表（A3横、旧/新/備考 3カラム）Word文書の生成スキーマ",
  "prompt_context": "## 新旧比較表 生成形式\n\nPOST /generate に渡す spec を...",
  "required_fields": ["doc_title", "sections"],
  "sections_schema": { ... },
  "paragraph_schema": { ... },
  "example": { ... }
}

GET /schema/manual — Specification Schema

{
  "doc_type": "manual",
  "description": "仕様書（A4縦、表紙・経歴表・本文）Word文書の生成スキーマ",
  "prompt_context": "## 仕様書 生成形式\n\nPOST /generate/manual に渡す spec を...",
  "required_fields": ["doc_title", "sections"],
  "sections_schema": { ... },
  "history_schema": { ... },
  "example": { ... }
}

Dify Workflow Integration Pattern

Old/New Comparison Table (PDF Comparison)

[ファイルアップロード] ユーザーが PDF をアップロード
     ↓
[HTTP ノード] GET /schema/comparison
     ↓ body.prompt_context を変数に格納
[LLM ノード]
  システムプロンプト: {{schema_prompt_context}}
  ユーザーメッセージ: {{uploaded_pdf_content}}
     ↓ spec JSON（新旧比較表形式）
[HTTP ノード] POST /generate  { "spec": {{llm_output}} }
     ↓ { "download_url": "http://...", "filename": "...", "sections": N }
[End]

Gemini reads the uploaded PDF multimodally. PDF parsing on the server side is not required.

Specification Generation

[HTTP ノード] GET /schema/manual
     ↓ prompt_context
[LLM ノード] 仕様書内容の構造化
[HTTP ノード] POST /generate/manual  { "spec": {...} }

JSON Specification (Old/New Comparison Table)

Paragraph Specs (elements of `old_paragraphs` / `new_paragraphs`)

{
  "text": "テキスト（シンプルな場合）",
  "segments": [
    { "text": "通常テキスト" },
    { "text": "赤い変更箇所", "color": "red", "underline": true },
    { "text": "続き" }
  ],
  "bold": false,
  "color": "black",
  "underline": false,
  "align": "justify",
  "indent": 0,
  "sz": 19
}

Use either text or segments. segments is used when multiple formats are mixed within a single paragraph.

Comment Anchors

{
  "anchor": "作業手順確認書類",
  "text": "名称変更：作業手順確認書類→作業安全確認表",
  "column": "old"
}

anchor: Text to attach the comment to (exact match)
text: Content displayed in the Word comment balloon
column: "old" | "new" | "both"

Usage Example in LangFlow / Python

import requests

# 1. スキーマ取得（Dify HTTP ノードの代替）
schema = requests.get("http://localhost:3456/schema/comparison").json()
print(schema["prompt_context"])  # → LLM に注入するテキスト

# 2. 新旧比較表生成
spec = {
  "doc_title": "通信関係請負工事共通仕様書　比較表",
  "sections": [
    {
      "id": "section19",
      "title": "【１９．施工方法】",
      "status": "changed",
      "old_paragraphs": [{"text": "１９．施工方法および工事工程", "bold": True}],
      "new_paragraphs": [{"text": "２０．施工方法および工事工程", "bold": True}],
      "notes": ["・名称変更に伴う見直し"],
      "comments": [{"anchor": "作業手順確認書類", "text": "名称変更", "column": "old"}],
    }
  ]
}

# ローカル保存 + パス返却
response = requests.post("http://localhost:3456/generate", json={
  "spec": spec,
  "output_filename": "比較表_第３回改正",
})
print(response.json())
# → {"success": true, "path": ".../比較表_第３回改正.docx", "download_url": "...", ...}

File Structure

docx-mcp/
├── src/
│   ├── index.js          # MCP stdio サーバー（Claude Desktop / Code）
│   ├── http-server.js    # HTTP REST サーバー（Dify / LangFlow）
│   ├── docx-generator.js # コア: JSON → 新旧比較表 .docx 変換エンジン
│   ├── manual-generator.js # コア: JSON → 仕様書 .docx 変換エンジン
│   ├── schema.js         # Zod バリデーション + LLM 注入用スキーマ定義
│   └── test.js           # テスト
├── docs/
│   └── dify-tool.yaml    # Dify Custom Tool / OpenAPI 定義
├── package.json
└── README.md

Environment Variables

Variable	Default	Description
`OUTPUT_DIR`	`~/Desktop/docx-output`	Save destination for generated files
`PORT`	`3456`	Port number for HTTP mode

Available Tools

3 tools

generate_comparison_docA

Generate a 新旧比較表 (before/after comparison) Word document (.docx). The document follows A3 landscape layout with 旧/新/備考 three-column format. Supports red text for new content, blue underline anchors, and Word comments. Returns base64-encoded docx and saves to local output directory.

ParametersJSON Schema

Name	Required	Description	Default
`spec`	Yes	Document specification. Use get_template_schema to see the full format.
`output_filename`	No	Output filename (without extension). Defaults to doc_title.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: document layout (A3 landscape), formatting features (red text, blue underline, Word comments), dual output behavior (returns base64 and saves locally), and file type (.docx). It doesn't mention error conditions, performance characteristics, or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in two sentences: first describes the document generation with formatting details, second explains the dual output behavior. Every element serves a purpose with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a document generation tool with no annotations and no output schema, the description provides substantial context: document purpose, layout, formatting features, and output behavior. It references get_template_schema for parameter details. The main gap is lack of explicit error handling or performance information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description doesn't add meaningful parameter semantics beyond what's in the schema, though it references get_template_schema for the full spec format, which provides some guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action (generate), resource (新旧比較表/before-after comparison Word document), and output format (.docx). It distinguishes from sibling tools by specifying document generation rather than schema retrieval or previewing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating comparison documents with specific formatting requirements, and references get_template_schema for parameter details. However, it doesn't explicitly state when to use this tool versus alternatives like preview_sections, or provide clear prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_template_schemaA

Returns the JSON schema and a complete example for the generate_comparison_doc tool. Call this first to understand how to structure the spec parameter. Pass doc_type="manual" to get the schema for generate_manual_doc instead.

ParametersJSON Schema

Name	Required	Description	Default
`doc_type`	No	Which schema to return. "comparison" (default) = 新旧比較表, "manual" = 仕様書.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by stating it returns a JSON schema and example, specifies a prerequisite action ('Call this first'), and mentions the default behavior for doc_type. However, it lacks details on error handling or response format, which could enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, uses two efficient sentences with zero waste, and each sentence earns its place by providing essential usage instructions and parameter context without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete, covering purpose, usage, and parameter semantics. However, it could be more complete by briefly mentioning the response structure or potential errors, though this is not critical for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the purpose of the doc_type parameter ('to get the schema for generate_manual_doc instead') and clarifying the default value ('comparison' for 新旧比較表), which goes beyond the schema's enum and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Returns', 'Call this first') and resources ('JSON schema and a complete example for the generate_comparison_doc tool'), distinguishing it from siblings like generate_comparison_doc and preview_sections by focusing on schema retrieval rather than document generation or previewing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance on when to use this tool ('Call this first to understand how to structure the spec parameter') and includes an alternative usage case ('Pass doc_type="manual" to get the schema for generate_manual_doc instead'), clearly differentiating it from other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

preview_sectionsA

Preview the text content of a document spec without generating a file. Useful for verifying the structure before calling generate_comparison_doc.

ParametersJSON Schema

Name	Required	Description	Default
`spec`	Yes	Document specification

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the tool doesn't generate a file, which is useful behavioral context. However, it doesn't disclose other important traits like whether this is a read-only operation, what permissions are needed, what the output format looks like (text content preview), or any rate limits. For a tool with no annotations, this leaves significant gaps in behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise and well-structured: two sentences that each earn their place. The first sentence states the core purpose with key constraint, and the second provides usage guidance. No wasted words, and the most important information (what it does) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations, no output schema, and a single but complex parameter (nested object 'spec'), the description is minimally adequate. It covers the purpose and basic usage context but lacks details about output format, error conditions, or what 'preview' actually returns. For a tool that presumably returns text content previews, more information about the return value would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage (the 'spec' parameter is documented as 'Document specification'), so the baseline is 3. The description doesn't add any parameter-specific information beyond what the schema provides—it doesn't explain what constitutes a valid 'document specification' or provide examples. The description's value is in tool purpose, not parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Preview the text content of a document spec without generating a file.' This specifies the verb ('preview'), resource ('text content of a document spec'), and key constraint ('without generating a file'). However, it doesn't explicitly differentiate from sibling tools like 'get_template_schema' beyond mentioning 'generate_comparison_doc' in usage context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Useful for verifying the structure before calling generate_comparison_doc.' This explicitly states when to use this tool (for verification before generation) and references an alternative sibling tool. However, it doesn't mention when NOT to use it or address other siblings like 'get_template_schema'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv1.0.0Apr 23, 2026
- First observedgenerate_comparison_doc
- First observedget_template_schema
- First observedpreview_sections

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: generate_comparison_doc creates the final document, get_template_schema provides metadata and examples, and preview_sections offers a validation step. The descriptions clearly differentiate their roles in the document generation workflow.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with descriptive verb_noun combinations (generate_comparison_doc, get_template_schema, preview_sections). The naming is uniform and predictable across the set.

Tool Count5/5

Three tools is well-scoped for a specialized document comparison server. Each tool serves a distinct, necessary function in the workflow (schema retrieval, preview, and generation), with no redundancy or obvious missing pieces for the stated purpose.

Completeness5/5

The toolset provides complete coverage for the document comparison domain: get_template_schema enables understanding the input format, preview_sections allows validation, and generate_comparison_doc handles final output. This creates a logical, end-to-end workflow with no gaps.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

docx-document-generator-proposal-contract-markdown
io.github.theluckystrike
Create real Word .docx files from your AI chat: proposals, quotes, contracts, statements of work.
Workplace & Productivity App Automation
1
mdmagic-mcp-server A
io.github.MDMagic-MCP
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
Workplace & Productivity Developer Tools
102
docmcp — Word & Excel files
io.github.Adirdavi
Real .docx and .xlsx files from structured data, with automatic Hebrew/Arabic RTL.
Workplace & Productivity File Systems
1
DocuQueue MCP B
io.github.dvcoolarun
Generate PDFs from templates via AI chat. Works with Claude, ChatGPT, Cursor, and any MCP client.
Workplace & Productivity Content Management Systems
1111

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bailangcheng818/docx-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

docx-comparison-mcp

Design Philosophy: GET schema → POST generate

Features

Setup

Registration to Claude Desktop

List of Endpoints

GET /schema/comparison — Old/New Comparison Table Schema

GET /schema/manual — Specification Schema

Dify Workflow Integration Pattern

Old/New Comparison Table (PDF Comparison)

Specification Generation

JSON Specification (Old/New Comparison Table)

Paragraph Specs (elements of old_paragraphs / new_paragraphs)

Comment Anchors

Usage Example in LangFlow / Python

File Structure

Environment Variables

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Resources

Looking for Admin?

Related MCP Connectors

Latest Blog Posts

MCP directory API

Paragraph Specs (elements of `old_paragraphs` / `new_paragraphs`)