Click on "Install 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., "@docx-forge-mcp Create a contract from a template and export to PDF."
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.
MCP server for Word document (.docx) creation and manipulation — the production-grade document automation tool for AI agents.
Generate contracts, reports, proposals, and compliance documents directly from agent workflows. No Word installation required.
Word documents are the default format for contracts, compliance reports, legal agreements, and business proposals — especially in enterprise and government workflows. This MCP server gives AI agents the ability to produce and manipulate .docx files programmatically, without any Office installation, UI automation, or file format guesswork.
Only 1 competitor exists for Word document manipulation via MCP as of 2026. This server fills that gap with a production-quality, fully-tested implementation.
Related MCP server: MCP-OPENAPI-DOCX
Tool | Description |
| Create a new |
| Extract text, headings, paragraphs, and metadata from a |
| Append a new section (heading + body) to an existing |
| Find and replace text — ideal for template variable substitution |
| Insert a formatted table with bold headers into a |
| Combine multiple |
| Convert |
| Get word count, page estimate, section count, table count |
Add to your claude_desktop_config.json:
{
"mcpServers": {
"docx-forge": {
"command": "npx",
"args": ["docx-forge-mcp"]
}
}
}Add to your .cursor/mcp.json:
{
"mcpServers": {
"docx-forge": {
"command": "npx",
"args": ["docx-forge-mcp"]
}
}
}npm install -g docx-forge-mcp
docx-forge-mcpcreate_document(
title="Service Agreement",
content="# Parties\n\n**Client:** {{CLIENT_NAME}}\n**Provider:** Acme Corp\n\n## Scope of Work\n\n{{SCOPE}}\n\n## Payment\n\n{{PAYMENT_TERMS}}",
outputPath="/tmp/contract.docx"
)
replace_text(filePath="/tmp/contract.docx", find="{{CLIENT_NAME}}", replace="TechCorp Ltd")
replace_text(filePath="/tmp/contract.docx", find="{{SCOPE}}", replace="Software development and consulting services.")
replace_text(filePath="/tmp/contract.docx", find="{{PAYMENT_TERMS}}", replace="Net 30 days. $15,000/month.")
export_to_pdf(filePath="/tmp/contract.docx", outputPath="/tmp/contract.pdf")create_document(
title="Q1 2026 Performance Report",
content="## Executive Summary\n\nRevenue grew 34% YoY.",
outputPath="/tmp/report.docx"
)
add_section(
filePath="/tmp/report.docx",
heading="Revenue Breakdown",
content="Product A: $450K\nProduct B: $320K\nServices: $180K",
headingLevel=2
)
add_table(
filePath="/tmp/report.docx",
headers=["Product", "Q1 Revenue", "Growth"],
rows=[["Product A", "$450K", "+41%"], ["Product B", "$320K", "+28%"], ["Services", "$180K", "+19%"]]
)
get_document_stats(filePath="/tmp/report.docx")read_document(filePath="/path/to/existing.docx")
# Returns: { text, paragraphs[], headings[], metadata: { wordCount, fileSizeBytes, ... } }merge_documents(
filePaths=["/docs/ch1.docx", "/docs/ch2.docx", "/docs/ch3.docx"],
outputPath="/docs/complete-manual.docx"
)create_document and add_section both accept markdown content:
Markdown | Result |
| H1 heading |
| H2 heading |
| Bold text |
| Italic text |
| Bullet list item |
| Numbered list item |
| Horizontal divider |
Blank line | Paragraph break |
export_to_pdf requires a system-level converter. It tries in order:
LibreOffice (best fidelity) — sudo apt-get install libreoffice
pandoc — sudo apt-get install pandoc
If neither is available, the tool returns success: false with installation instructions. The source .docx file is always preserved.
URI | Description |
| Step-by-step guide with workflow examples |
docx — .docx creation (no Office required)
mammoth — .docx reading and text extraction
@modelcontextprotocol/sdk — MCP protocol
zod — Input validation
Node.js >= 18.0.0
No Microsoft Word or Office installation required
PDF export requires LibreOffice or pandoc (optional)
git clone https://github.com/mdfifty50-boop/docx-forge-mcp
cd docx-forge-mcp
npm install
npm test # Run test suite
npm start # Start MCP server (stdio)MIT — see LICENSE
agentic-observability-mcp — Trace, cost-track, and monitor agent actions
agent-guard-mcp — Loop detection and circuit breakers
compliance-shield-mcp — EU AI Act audit trails
Append a new section (heading + body content) to the end of an existing .docx document. The document is updated in place.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the existing .docx file | |
| heading | Yes | Section heading text | |
| content | Yes | Section body content (markdown supported) | |
| headingLevel | No | Heading level: 1 = H1 (largest) through 6 = H6 (smallest). Default: 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the document is 'updated in place', indicating a mutation, but does not disclose further behavioral traits such as permissions required, whether existing content is preserved, or any side effects.
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?
Two concise sentences with no wasted words. The action and resource are front-loaded, and every sentence contributes to understanding.
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?
For a simple append operation with 4 parameters and no output schema, the description is mostly complete. It covers the core behavior (append, in-place update) and required parameters. Minor gap: no mention of return value, but as a void operation this is acceptable.
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?
Schema coverage is 100%, so baseline is 3. The description mentions 'heading + body content' which maps to heading and content parameters, but adds no additional meaning beyond the schema definitions. No extra context for filePath or headingLevel.
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?
The description clearly states the action ('Append') and resource ('existing .docx document'), specifying it adds a section with heading and body content. It distinguishes itself from siblings like create_document (which creates new files) and add_table (which adds tables not sections).
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?
The description implies usage for adding a section to an existing document but does not explicitly state when not to use this tool or mention alternatives like add_table. It does specify 'to the end', providing some context, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a formatted table into an existing .docx document. The table is appended at the end of the document with bold header row and standard cell borders.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the existing .docx file | |
| headers | Yes | Column header labels (e.g., ["Name", "Role", "Department"]) | |
| rows | Yes | 2D array of table data. Each inner array is one row and must match the number of headers. Example: [["Alice", "Engineer", "Tech"], ["Bob", "Designer", "UX"]] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: table is appended, header row is bold, standard borders. It does not cover error handling or prerequisites, but the main behavior is well communicated.
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?
Two sentences with no wasted words. First sentence states the core purpose, second adds specific formatting details. Highly efficient.
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?
For a simple mutation tool with no output schema, the description covers essential behavior (append, formatting) and parameter semantics. It lacks error or return information but is largely complete given the tool's simplicity.
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?
Schema coverage is 100% and descriptions are present for all parameters. The tool description adds context about formatting (bold header, borders) that is not in the schema, adding value beyond the baseline of 3.
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?
The description clearly states the verb 'Insert' and resource 'formatted table into an existing .docx document'. It specifies the behavior (appended at end, bold header, standard borders) and distinguishes from siblings like add_section and create_document.
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?
The description implies usage for adding tables to existing .docx files but does not explicitly state when not to use it or provide alternatives. It is adequate but lacks explicit guidance compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new .docx Word document from markdown or plain text content. Supports headings (#, ##, ###), bold (text), italic (text), bullet lists (- item), numbered lists (1. item), and blank lines between paragraphs.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Document title — appears as the document heading | |
| content | Yes | Document body content as markdown. Supports headings (#, ##, ###), bold (**text**), italic (*text*), bullet lists (- item), and numbered lists (1. item). | |
| author | No | Author name stored in document metadata | |
| outputPath | Yes | Absolute or relative path where the .docx file will be saved (e.g., /tmp/report.docx) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes input format but omits details about file overwrite behavior, error handling, authorization needs, or return value. This leaves significant gaps for safe invocation.
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?
The description is two sentences with no wasted words. The main action is front-loaded, followed by a focused list of supported markdown features. Perfectly concise.
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?
For a tool creating files, the description lacks details on file overwrite behavior, error messages, and output confirmation. It covers the essential purpose but leaves practical usage gaps. Adequate but not complete.
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?
Schema coverage is 100% with descriptions for each parameter. The tool description adds marginal value by noting that 'title' appears as the document heading, but it largely repeats schema info. Baseline 3 is appropriate.
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?
The description clearly states the tool creates a new .docx document from markdown/plain text, with specific supported formatting features. It distinguishes from siblings like add_section (modifying existing documents) or merge_documents (combining documents).
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?
The description implies this tool is for initial document creation but provides no explicit guidance on when to use it vs. alternatives like add_section or read_document. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a .docx file to PDF. Attempts conversion via LibreOffice (best fidelity) then pandoc. Returns success status and the method used. Requires LibreOffice or pandoc to be installed on the system.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the source .docx file | |
| outputPath | Yes | Path where the output .pdf file will be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: sequential conversion attempts, return of success status and method used, plus system dependencies.
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?
Two sentences, front-loaded with main action. Every sentence adds value; no fluff.
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?
Covers purpose, method, return value, and prerequisites. Lacks explicit error handling details, but sufficient for a conversion tool.
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?
Schema coverage is 100% with descriptions. Description adds conversion context but does not significantly extend parameter meaning beyond schema.
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?
Clearly states 'Convert a .docx file to PDF' with specific verb and resource. No sibling tool does PDF conversion, so it is distinct.
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?
Provides context on conversion method (LibreOffice first, then pandoc) and system prerequisites. Lacks explicit 'when not to use' but otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics for a .docx document: word count, character count, estimated page count (at 250 words/page), number of sections (headings), and number of tables.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the .docx file to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists return values but does not disclose whether the operation is read-only, performance implications, error conditions (e.g., file not found, unsupported format), or any side effects.
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?
A single, well-structured sentence that front-loads the verb and resource, and lists the specific statistics concisely with no wasted words.
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?
Given only one parameter and no output schema, the description provides a fairly complete list of return values for a stats tool. However, it could mention edge cases (e.g., file not found, unsupported .docx variants) or performance notes for large documents.
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?
Schema coverage is 100% and the parameter description ('Path to the .docx file to analyze') is clear. The description adds value by explicitly stating the file type (.docx) and implying the file must exist, going beyond the schema's generic 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?
The description clearly states the verb ('Get') and resource ('statistics for a .docx document'), and lists specific metrics (word count, character count, page count, sections, tables), making the purpose unambiguous and distinguishing it from sibling tools like 'read_document' or 'merge_documents'.
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?
The description implies usage for obtaining document statistics but does not explicitly state when to use this tool versus alternatives, nor does it provide any when-not-to-use guidance or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns server health, uptime, version, and call stats
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it returns health, uptime, version, and call stats. Implies read-only operation with no side effects. Minor gap: no mention of failure modes or rate limits, but acceptable for a health check.
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?
Single sentence, no unnecessary words. Every element provides value. Front-loaded with the core function.
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?
With zero parameters and no output schema, the description is fully sufficient. Provides clear expectation of return data. No missing information for this simple tool.
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?
Zero parameters, schema coverage 100%. Description adds value by specifying what the tool returns beyond the empty schema. Baseline for 0 params is 4, and description meets it.
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?
Clearly states the tool returns server health, uptime, version, and call stats. Uses specific verb 'returns' and defines distinct resource. Siblings are all document-related, so this tool is uniquely identified.
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?
No explicit when-to-use or when-not-to-use guidance. Context from siblings implies use for monitoring server status, but description does not provide alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combine multiple .docx files into a single document. Each source document is separated by a horizontal divider. Useful for assembling reports, consolidating contracts, or combining chapter files.
| Name | Required | Description | Default |
|---|---|---|---|
| filePaths | Yes | Array of paths to .docx files to merge (minimum 2). Files are merged in the order given. | |
| outputPath | Yes | Path where the merged .docx file will be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses that each source is separated by a horizontal divider and that files are merged in order. However, it does not mention error handling, overwrite behavior, or any side effects, leaving gaps for a read-only operation that could be destructive.
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?
Two sentences that front-load the action and result, followed by use cases. No superfluous words; every sentence adds value. Ideal conciseness.
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?
For a simple 2-parameter tool with no output schema, the description adequately covers purpose, output behavior, and use cases. It could be more complete by mentioning file format restrictions or performance considerations, but it is sufficient for an AI agent to understand the tool.
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?
Schema description coverage is 100%, with both parameters already well-documented. The description adds little new parameter-specific information beyond what is in the schema (e.g., order given is repeated). Thus, it meets the baseline but does not exceed it.
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?
The description clearly states the action ('Combine multiple .docx files into a single document') and the resource/format, distinguishing it from siblings like 'create_document' (which creates a new file) and 'add_section' (which modifies an existing file).
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?
The description provides usage context ('assembling reports, consolidating contracts, or combining chapter files'), implicitly indicating when to use it. However, it does not explicitly state when not to use it or mention alternatives (e.g., merging PDFs would require a different tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all text, paragraph list, headings, and file metadata from an existing .docx file. Returns structured data suitable for further processing or display.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the .docx file to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states what is extracted and that it returns structured data, but with no annotations present, it does not disclose side effects (though likely read-only), error conditions (e.g., file not found), or permission requirements. It provides a basic overview but lacks depth.
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?
The description is extremely concise with two sentences that immediately convey purpose and output. Every word adds value, no filler. It is front-loaded with the action and resource.
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?
Given the tool's simplicity (single parameter, no output schema), the description covers the main purpose and gives a high-level idea of return data. It lacks details on error handling or exact output structure, but for a read tool, it is reasonably complete.
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?
The schema already describes the single parameter filePath with high coverage (100%). The description adds the word 'existing' which implies the file must exist, adding marginal value. Given the high schema coverage, the baseline is 3 and the description does not significantly improve understanding.
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?
The description clearly states the tool extracts text, paragraph list, headings, and metadata from a .docx file. The verb 'Extract' and resource 'existing .docx file' are specific, and the tool is easily distinguished from sibling tools like create_document or add_section which perform different operations.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_document_stats for statistics, or replace_text for editing). There is no mention of when not to use it or any prerequisites. The description implies usage for reading a .docx file but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and replace text in an existing .docx document. Useful for template substitution — e.g., replacing {{CLIENT_NAME}} with an actual name, or updating dates and contract values.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the .docx file to modify | |
| find | Yes | Text string to search for | |
| replace | Yes | Replacement text (can be empty string to delete the found text) | |
| replaceAll | No | If true (default), replace every occurrence. If false, replace only the first occurrence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains the basic behavior (find and replace, with replaceAll option), but omits details such as whether the file is overwritten, formatting preservation, or side effects. This is adequate but not comprehensive.
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?
Two sentences, no wasted words. The purpose is front-loaded, and the example adds value without verbosity.
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?
For a simple tool with full schema coverage and no output schema, the description is nearly complete. It covers the main use case and behavior. Minor gaps on output/confirmation, but overall sufficient.
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?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already documents for each parameter. It reinforces the template substitution use case but no parameter-specific guidance.
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?
The description clearly states the action ('Find and replace text'), the target resource ('.docx document'), and provides a concrete use case ('template substitution'). This effectively distinguishes it from siblings like add_section or add_table.
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?
The description explicitly gives a use case ('template substitution') and examples (replacing {{CLIENT_NAME}}), which helps the agent decide when to use this tool. However, it does not mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation on docx files: create, read, update text, add sections/tables, merge, export, stats, and health. No two tools overlap in purpose.
All tools follow a clear verb_noun pattern (e.g., create_document, read_document, add_table). The naming is predictable and consistent, with only health_check as a minor noun_noun exception but still clear.
9 tools cover a well-scoped set of functionality for docx manipulation without being sparse or overwhelming. Each tool earns its place.
The surface covers core CRUD (create, read, update via replace_text and appending sections/tables) plus merge and export. Missing delete/remove operations and the ability to insert at arbitrary positions, but these are minor gaps for typical template workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
MCP server for Api2Pdf — generate PDFs & images from HTML, URLs or office files; merge, barcodes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mdfifty50-boop/docx-forge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
