The DOCX MCP Server is a Node.js-based Model Context Protocol (MCP) server that enables comprehensive creation, manipulation, and saving of DOCX documents using a structured JSON schema.
Core Capabilities:
Document Lifecycle: Create new DOCX documents from JSON, open existing .docx files, save in-memory documents to disk, and export JSON models
Content Management: Insert, replace, and remove content blocks by index with support for headings (6 levels), paragraphs, lists (nested ordered/unordered), tables, code blocks (180+ languages with syntax highlighting), images, page breaks, blockquotes, and text boxes
Rich Formatting: Apply comprehensive text styling including bold, italic, underline, colors, fonts, alignment, spacing, and indentation
Metadata Handling: Manage document properties like title, creator, subject, keywords, and dates
Page Layout Control: Configure page size (A4, Letter), orientation, margins, and headers/footers with dynamic elements like page numbers and dates
Image Support: Embed images from URLs, local files, or base64 data in PNG, JPEG formats
Document Registry: Maintain in-memory document management with unique IDs and querying capabilities
Schema Validation: Ensure valid document structure through JSON schema validation
Provides a Node.js-based MCP server for creating, editing, and managing DOCX documents with rich formatting, tables, images, code blocks, and headers/footers
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 MCP Server create a meeting agenda with headings and bullet points"
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 Node.js MCP server that lets clients create, query, edit, and save DOCX documents using a JSON schema, powered by the docx library.
Complete DOCX operations: Create, edit, and save Word documents via Model Context Protocol (MCP)
JSON Schema validation: Structured document definition with comprehensive validation
Rich content blocks:
Text & Headings: 6 heading levels with advanced formatting
Lists: Ordered/unordered lists with multiple numbering styles and nesting
Code Blocks: Syntax highlighting for 180+ languages with themes and line numbers
Tables: Full table support with styling and cell formatting
Images: URL downloads with fallback, local files, and base64 embedding
Page Control: Page breaks and section breaks
Advanced text formatting:
Basic: Bold, italic, underline, strikethrough, colors
Enhanced: Superscript, subscript, font families, highlights, small caps
Spacing: Character spacing, paragraph alignment, indentation
Document management: In-memory registry with unique IDs
Metadata support: Complete document properties and custom metadata
File operations: Open existing DOCX files and save to disk
Error handling: Graceful fallbacks and comprehensive validation
Related MCP server: docx-mcp
See src/schema.ts for the full schema. Key concepts:
meta: Document metadata (title, subject, creator, etc.)
pageSettings: Page size, orientation, margins, header/footer margins (NEW in v0.3.0)
headers: Page header configuration with default/first/even page support (NEW in v0.4.0)
footers: Page footer configuration with default/first/even page support (NEW in v0.4.0)
content: Array of blocks: heading, paragraph, table, image, codeBlock, list, pageBreak, horizontalRule, blockquote, infoBox, textBox
Enhanced blocks:
CodeBlock: { type: "codeBlock", language: "javascript", code: "...", showLineNumbers: true }
List: { type: "list", ordered: true, items: [...] } with nesting support
Table: Enhanced with backgroundColor, borders, verticalAlign, cell margins (NEW in v0.3.0)
HorizontalRule: { type: "horizontalRule", style: "single", color: "#666" } (NEW in v0.3.0)
Blockquote: { type: "blockquote", children: [...], borderColor: "#ccc" } (NEW in v0.3.0)
InfoBox: { type: "infoBox", boxType: "info", title: "Note", children: [...] } (NEW in v0.3.0)
TextBox: { type: "textBox", children: [...] } with border styling (NEW in v0.3.0)
Enhanced TextRun: Supports fontFamily, superScript, subScript, highlight, etc.
Each paragraph/heading uses inline runs (text, hyperlink) with rich formatting options
{
"headers": {
"default": {
"alignment": "center",
"children": [
{
"type": "documentTitle",
"bold": true,
"size": 14,
"color": "#1f4788"
}
]
},
"first": {
"alignment": "right",
"children": [
{
"type": "text",
"text": "Confidential Document",
"bold": true,
"color": "#cc0000"
}
]
}
},
"footers": {
"default": {
"alignment": "center",
"children": [
{
"type": "text",
"text": "Page "
},
{
"type": "pageNumber",
"format": "decimal"
},
{
"type": "text",
"text": " of "
},
{
"type": "pageNumber",
"format": "totalPages"
}
]
}
}
}Supported header/footer elements:
text: Static text with styling options
pageNumber: Auto page numbering (decimal, upperRoman, lowerRoman, upperLetter, lowerLetter)
currentDate: Auto-updating date with custom format strings
documentTitle: References document meta.title
image: Images in headers/footers (base64, path, url)
✅ Headers & Footers System: Comprehensive page header and footer support
Default, first page, and even page headers/footers
Rich content: text, page numbers, dates, document title, images
Flexible alignment: left, center, right
Advanced styling: fonts, colors, sizes, bold/italic
✅ Dynamic Content Elements:
pageNumber: Automatic page numbering with multiple formats (decimal, roman, letters)
currentDate: Auto-updating dates with custom formats
documentTitle: Reference document metadata
text: Static text with full styling options
image: Headers/footers images support
✅ Professional Layout Control:
Different headers/footers for first page vs. rest of document
Odd/even page variations for book-style layouts
Precise margin control for headers and footers
Integration with existing page settings system
✅ Page Settings: Page size (A4, Letter, etc.), orientation, margins control
✅ Enhanced Tables: Background colors, border styles, vertical alignment, table templates
✅ New Block Types: Horizontal rules, blockquotes, info boxes, text boxes
✅ Advanced Styling: More comprehensive table and cell formatting options
✅ Code Blocks: Syntax highlighting for 180+ programming languages
✅ Lists: Ordered and unordered lists with multiple styles and nesting
✅ Page Breaks: Control document pagination
✅ Enhanced Text: Superscript, subscript, font families, highlights
✅ Improved Schema: More comprehensive validation and type safety
Install deps
npm installDev mode
npm run devBuild and start
npm run build
npm startdocx-getSchema { } // Get JSON schema - call this first!
docx-create { json }
docx-open { id?, path } // open .docx file from disk
docx-queryMeta { id }
docx-queryObjects { id }
docx-editMeta { id, patch }
docx-editContent { id, index, block }
docx-insertContent { id, index, block }
docx-removeContent { id, index }
docx-save { id, path }
docx-exportJson { id }
{
"meta": { "title": "Demo", "creator": "DOCX MCP v0.2.0" },
"content": [
{ "type": "heading", "level": 1, "children": [ { "type": "text", "text": "Title" } ] },
{ "type": "paragraph", "children": [
{ "type": "text", "text": "Hello ", "bold": true },
{ "type": "text", "text": "world", "color": "FF0000" }
]},
{
"type": "codeBlock",
"language": "javascript",
"showLineNumbers": true,
"code": "console.log('Hello, World!');"
},
{
"type": "list",
"ordered": false,
"items": [
{ "children": [{ "type": "text", "text": "First item" }] },
{ "children": [{ "type": "text", "text": "Second item" }] }
]
},
{ "type": "image", "url": "https://picsum.photos/300/200", "width": 300, "height": 200 },
{ "type": "pageBreak" },
{ "type": "table", "rows": [ { "cells": [
{ "children": [ { "type": "paragraph", "children": [ { "type": "text", "text": "A" } ] } ] },
{ "children": [ { "type": "paragraph", "children": [ { "type": "text", "text": "B" } ] } ] }
] } ] }
]
}Images can be included in three ways:
URL: { "type": "image", "url": "https://example.com/image.png", "width": 300, "height": 200 }
Local file path: { "type": "image", "path": "/path/to/image.png", "width": 300, "height": 200 }
Base64 data: { "type": "image", "data": "base64string", "format": "png", "width": 150, "height": 100 }
URL Image Features:
Automatic download from HTTP/HTTPS URLs
Fallback to generated placeholder image if download fails
Placeholder shows original URL and dimensions
Support for common image formats (PNG, JPEG, JPG)
Note: Fontconfig warnings on Windows are harmless and can be ignored
Supported formats: PNG, JPEG, JPG
Hyperlinks are rendered visually as underlined blue text. Full hyperlink relationships can be added later.
Images support URL downloads, local file paths, and base64 data.
This server runs over stdio to be compatible with MCP hosts.
Create a new docx from JSON, returns an id. Use docx-getSchema first to understand the required JSON structure. Supports images via 'data' (base64), 'path' (local file), or 'url' (remote image with fallback).
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions the tool returns an id. It does not disclose side effects, permissions, or limitations such as whether it overwrites existing files or where the document is stored.
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: first states purpose and output, second gives prerequisite and a key detail. No unnecessary words, efficient for an AI agent.
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 complexity of the input schema and lack of output schema/annotations, the description is minimal. It relies heavily on docx-getSchema for full details, which is acceptable but leaves many aspects uncovered.
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 single parameter 'json' is complex with no schema description (0% coverage). The description adds value by mentioning image support via data/path/url and directing to docx-getSchema, but it does not explain the rest of the JSON structure.
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?
Description clearly states it creates a new docx from JSON and returns an id, which distinguishes it from sibling tools like docx-editContent or docx-insertContent.
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?
Explicitly advises using docx-getSchema first to understand the JSON structure, providing a clear prerequisite. However, it lacks guidance on when not to use this tool versus siblings for editing or querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace a block at index. Use docx-queryObjects first to see available blocks, and docx-getSchema to understand block structure.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| index | Yes | ||
| block | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must stand alone. It states 'Replace' implying mutation, but it does not disclose side effects (e.g., changes to block indices), error conditions, required permissions, or whether the replacement is in-place. The behavioral impact on the document is underdescribed.
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 primary action is front-loaded in the first sentence, and the second sentence provides essential prerequisites. It achieves maximum clarity with minimal length.
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 mutation tool with 3 required parameters and no output schema, the description provides basic direction and references supplementary tools. However, it lacks details on expected return value, error handling, and behavioral guarantees, which are important for safe automated use. It is functional but not fully self-contained.
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 input schema has 0% description coverage, so the description carries full responsibility. It mentions 'block' and references docx-getSchema for block structure, but does not explain the 'id' or 'index' parameters. The agent must infer that 'id' identifies the document and 'index' specifies the block position, which is not explicitly stated.
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 'Replace a block at index,' which is a specific verb and resource. It provides context by referencing prerequisite tools (docx-queryObjects, docx-getSchema), but it does not explicitly differentiate from sibling tools like docx-insertContent or docx-removeContent, leaving the agent to infer when replacement is preferred.
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 advises using docx-queryObjects and docx-getSchema first, which provides useful sequential guidance. However, it does not specify when to use this tool versus alternatives (e.g., insert or remove), nor does it give contraindications or examples of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch metadata of a docx by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| patch | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'patch', implying partial update, but does not mention whether updates are idempotent, what happens on failure, or authentication requirements. Minimal transparency.
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 a single sentence, which is concise but lacks structure. It could be expanded to include purpose, usage, and parameter details without becoming overly long.
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 complexity of a patch operation with a nested parameter and no output schema, the description is insufficient. It does not explain the behavior of the patch (e.g., merge vs replace), return values, or error conditions.
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 0%, so the description must compensate. It mentions 'id' and 'patch' but does not explain that 'id' is the document identifier and 'patch' is a partial metadata object with nested fields. The nested properties are entirely undocumented.
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 ('Patch metadata of a docx') and the required identifier ('by id'). It distinguishes from sibling tools like docx-editContent and docx-queryMeta, but could be more specific about the scope of metadata.
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 on when to use this tool over alternatives (e.g., docx-editContent for content changes, docx-queryMeta for reading metadata). The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current JSON model for a given id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool 'returns' the model, implying a read operation, but does not disclose any side effects, authorization needs, or how the 'current' model is determined.
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 a single, succinct sentence with no redundant information. It is well-structured and front-loaded.
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 simple input schema and lack of output schema, the description is too brief. It does not explain the returned JSON model's structure or content, nor how it relates to sibling tools. The tool's role within the server is unclear.
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 0%, so the description must explain the parameter. It only mentions 'for a given id', adding minimal value beyond the schema. No details on id format, validity, or behavior when id is invalid.
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 ('return') and resource ('JSON model'), and identifies the required parameter 'id'. It is specific enough to understand the tool's basic function, though it does not explicitly differentiate from the sibling tool 'docx-getSchema' which might return a schema instead of the model.
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 no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent is left to infer the appropriate context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the JSON schema for DOCX document structure. IMPORTANT: Always call this first to understand the document format before using other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation returning a schema, which is accurate and sufficient given no annotations. Could explicitly state no side effects, but clear enough.
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 redundant information, front-loaded with purpose and important usage note. 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?
Explains the tool's output (schema for DOCX structure) but could provide more detail on the schema's scope or format. Still adequate for 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?
No parameters exist, so no additional meaning needed. The description focuses on the output, which 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 it retrieves the JSON schema for DOCX documents and positions it as a necessary first step, distinguishing it from sibling tools that operate on the 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?
Explicitly instructs the agent to 'always call this first' before using other tools, providing clear guidance on prerequisite usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a block at index. Use docx-queryObjects first to see current structure, and docx-getSchema to understand block structure.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| index | Yes | ||
| block | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Insert a block at index' without disclosing side effects (e.g., mutation), error handling, or return behavior. This minimal disclosure leaves significant behavioral gaps.
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 consists of two concise sentences: the first states the purpose, the second provides usage guidance. No extraneous information; every sentence serves a clear 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?
Given 3 parameters, no output schema, and no annotations, the description provides the core purpose and prerequisite steps but lacks detail on parameter semantics and behavioral outcomes. It is adequate for understanding scope but leaves gaps for an agent to infer required information.
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 0% (no parameter descriptions in schema). The description references docx-getSchema for block structure but does not explain the 'id' or 'index' parameters. It adds little meaning beyond the schema's type definitions, failing to compensate for the lack of schema descriptions.
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 'Insert a block at index', specifying the verb (insert) and resource (block at index). It distinguishes from sibling tools like docx-create (creates new document) and docx-removeContent (removes content) by implying insertion of new content into an existing structure.
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 advises to use docx-queryObjects first to see current structure and docx-getSchema to understand block structure, providing clear context for when to use this tool. However, it does not include explicit exclusions or alternatives beyond referencing other tools as prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a .docx file from disk into memory and return id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states the basic action without addressing file existence requirements, permission needs, or memory implications. The description is insufficient for understanding side effects or preconditions.
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 a single concise sentence that front-loads the core purpose. Every word contributes value with no redundancy.
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 simple tool with two parameters and no output schema, the description is not complete. It lacks critical details like expected path format, optional parameter role, and return value structure. An agent cannot reliably invoke this tool without additional information.
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 description does not explain the parameters 'id' and 'path'. Schema coverage is 0%, so the description should compensate, but it only mentions 'path' implicitly. The 'id' parameter is completely undocumented, leaving its purpose unclear.
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 'Open' and the resource '.docx file', specifying the action of loading from disk into memory and returning an id. However, it does not differentiate from the sibling tool 'docx-openFile', which might have a similar purpose, leaving potential ambiguity.
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 like docx-create or docx-openFile. The description lacks any contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a .docx file from disk into memory and return id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the file is loaded into memory and an id is returned, but no details about side effects (e.g., file locking, memory management), error conditions, or whether the operation is read-only. Insufficient 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 a single sentence, which is concise but lacks critical details. It earns its place but fails to provide necessary information, making it under-specified rather than optimally 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?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain file handling, supported formats, concurrency behavior, or error handling. A more descriptive explanation is needed for an agent to use it correctly.
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 input schema has two parameters with 0% description coverage. The description mentions 'return id' but id is also an input parameter, causing ambiguity. No explanation of what the id parameter represents or how it relates to the return value. This confuses rather than clarifies.
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 opens a .docx file from disk into memory and returns an id. It uses specific verb 'Open' and resource '.docx file', and distinguishes from siblings like docx-create. However, it doesn't explicitly differentiate from the similar sibling docx-open, which could cause confusion.
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 on when to use this tool versus alternatives. No prerequisites or conditions mentioned (e.g., file must exist, supported file paths). Agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get docx metadata by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states 'Get' implying read-only, but does not disclose idempotency, error behavior (e.g., missing id), authorization needs, or response characteristics.
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 very brief (one sentence), which is concise but underspecified. It lacks essential details without being verbose. It earns a middle score for efficiency but insufficient content.
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 (1 param, no output schema, no annotations), the description should provide enough context. It only mentions 'get metadata by id', omitting return format, field names, and error handling. Incomplete for reliable use.
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 0%, and the description adds no meaning beyond the schema. The 'id' parameter is documented only as a string with no format, source, or required encoding explained.
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 uses a specific verb ('Get') and resource ('docx metadata by id'), clearly indicating the action and object. It distinguishes from sibling tools like docx-editMeta (edit) and docx-queryObjects (query objects), but lacks specificity on what metadata entails.
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 such as docx-queryObjects or docx-getSchema. The description does not mention prerequisites, context, or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List top-level object info by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must describe behavioral traits. It only indicates a read operation via 'List' but does not disclose any other behaviors such as side effects, authorization needs, error conditions, or output structure. The description is insufficient for an agent to know what happens when invoked.
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 at 4 words, which is front-loaded and efficient. However, it sacrifices necessary detail, making it under-specified for a tool that likely requires more context about its behavior and output.
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?
The tool is simple with one parameter and no output schema, but the description fails to specify what 'object info' includes or what the return value looks like. Given the lack of annotations and schema coverage, the description is not complete enough for an agent to reliably use the tool without additional knowledge.
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?
With 0% schema description coverage and no parameter descriptions, the description must explain the 'id' parameter. However, it only mentions 'by id' in the description without clarifying the expected format, type constraints, or what the id represents. The agent gets no additional meaning beyond the schema's bare 'string' type.
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 uses a specific verb 'List' and identifies the resource 'top-level object info' with a key parameter 'by id'. It clearly states the tool's function, but lacks detail on what constitutes 'top-level object info', which could be clearer. It differentiates from siblings like 'docx-queryMeta' and 'docx-getSchema' by focusing on objects rather than metadata or schema.
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 no guidance on when to use this tool versus the numerous sibling tools. There is no mention of prerequisites, context, or alternatives. The agent receives no help in deciding between, e.g., 'docx-queryObjects' and 'docx-queryMeta'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a block at index.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| index | Yes |
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 states 'Remove' indicating mutation, but fails to disclose whether the operation is destructive, whether indices shift after removal, if undo is supported, or any error conditions. This is insufficient for an agent to assess 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?
The description is extremely short (one sentence) but omits critical information. It achieves conciseness at the cost of clarity and completeness, leaving the agent underinformed. A better balance is needed.
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 two required parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain return values, error handling, expected behavior if index is out of bounds, or any operational context (e.g., document loaded). The agent cannot use this tool reliably.
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?
With 0% schema description coverage, the description adds no meaning beyond the schema. It does not explain what 'id' refers to (e.g., document ID) or what 'index' means (e.g., 0-based position, valid range). The agent has no clue how to populate these parameters correctly.
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 states the verb 'Remove' and the resource 'a block', with a qualifier 'at index', making the basic purpose clear. However, it does not specify what a 'block' refers to (e.g., a paragraph, table, or other element), which could cause ambiguity in a docx context. It is distinct from sibling tools like docx-insertContent or docx-editContent, but the lack of specificity prevents a perfect score.
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, prerequisites (e.g., document must be open), or conditions (e.g., index must exist). The agent receives no context about expected usage, making it unclear how to integrate this tool into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist the docx to disk path by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only says 'persist', implying a write operation, but lacks details on overwrite behavior, directory creation, or validation. This is insufficient for safe usage.
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 a single sentence, which is concise but omits critical details. It is front-loaded but incomplete, undermining its effectiveness.
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 complexity of docx manipulation and the presence of many sibling tools, this description fails to provide enough context. No output schema, no parameter descriptions, and no behavioral details leave the agent guessing.
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 0%, so the description must compensate. It adds minimal meaning: 'id' identifies the docx, 'path' is the disk location. However, it does not specify formats or constraints, leaving the agent to infer.
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 persists a docx to disk using an id and path, which distinguishes it from creation and editing tools. However, it does not explain what 'id' refers to, leaving some ambiguity.
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 like docx-open or docx-create. The description does not mention prerequisites, context, or scenarios.
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. Dates show when Glama detected each change.
v1.0.0docx-create31 fields changedInput schema / properties / json / $defs / Block / oneOfPrevious value: -[
- {
- "$ref": "#/$defs/Paragraph"
- },
- {
- "$ref": "#/$defs/Table"
- },
- {
- "$ref": "#/$defs/Image"
- },
- {
- "$ref": "#/$defs/Heading"
- },
- {
- "$ref": "#/$defs/CodeBlock"
- },
- {
- "$ref": "#/$defs/List"
- },
- {
- "$ref": "#/$defs/PageBreak"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Paragraph"
+ },
+ {
+ "$ref": "#/$defs/Table"
+ },
+ {
+ "$ref": "#/$defs/Image"
+ },
+ {
+ "$ref": "#/$defs/Heading"
+ },
+ {
+ "$ref": "#/$defs/CodeBlock"
+ },
+ {
+ "$ref": "#/$defs/List"
+ },
+ {
+ "$ref": "#/$defs/PageBreak"
+ },
+ {
+ "$ref": "#/$defs/HorizontalRule"
+ },
+ {
+ "$ref": "#/$defs/Blockquote"
+ },
+ {
+ "$ref": "#/$defs/InfoBox"
+ },
+ {
+ "$ref": "#/$defs/TextBox"
+ }
+]Input schema / properties / json / $defs / BlockquoteAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "backgroundColor": {
+ "type": "string"
+ },
+ "borderColor": {
+ "default": "#cccccc",
+ "type": "string"
+ },
+ "children": {
+ "items": {
+ "$ref": "#/$defs/Block"
+ },
+ "type": "array"
+ },
+ "leftIndent": {
+ "default": 720,
+ "type": "number"
+ },
+ "style": {
+ "default": "default",
+ "enum": [
+ "default",
+ "emphasized",
+ "minimal"
+ ],
+ "type": "string"
+ },
+ "type": {
+ "const": "blockquote"
+ }
+ },
+ "required": [
+ "type",
+ "children"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / CurrentDateAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bold": {
+ "default": false,
+ "type": "boolean"
+ },
+ "color": {
+ "default": "#000000",
+ "type": "string"
+ },
+ "format": {
+ "default": "MM/dd/yyyy",
+ "description": "Date format string",
+ "type": "string"
+ },
+ "italics": {
+ "default": false,
+ "type": "boolean"
+ },
+ "size": {
+ "default": 12,
+ "type": "number"
+ },
+ "type": {
+ "const": "currentDate"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / DocumentTitleAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bold": {
+ "default": false,
+ "type": "boolean"
+ },
+ "color": {
+ "default": "#000000",
+ "type": "string"
+ },
+ "italics": {
+ "default": false,
+ "type": "boolean"
+ },
+ "size": {
+ "default": 12,
+ "type": "number"
+ },
+ "type": {
+ "const": "documentTitle"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / FootnoteReferenceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "customMark": {
+ "description": "Custom reference mark (overrides numberFormat)",
+ "type": "string"
+ },
+ "footnoteId": {
+ "type": "string"
+ },
+ "numberFormat": {
+ "default": "decimal",
+ "enum": [
+ "decimal",
+ "upperRoman",
+ "lowerRoman",
+ "upperLetter",
+ "lowerLetter",
+ "symbol"
+ ]
+ },
+ "type": {
+ "const": "footnoteReference"
+ }
+ },
+ "required": [
+ "type",
+ "footnoteId"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / HeaderFooterContentAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "alignment": {
+ "default": "left",
+ "enum": [
+ "left",
+ "center",
+ "right"
+ ]
+ },
+ "children": {
+ "items": {
+ "$ref": "#/$defs/HeaderFooterElement"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / json / $defs / HeaderFooterElementAdded value: +{
+ "oneOf": [
+ {
+ "$ref": "#/$defs/HeaderFooterText"
+ },
+ {
+ "$ref": "#/$defs/PageNumber"
+ },
+ {
+ "$ref": "#/$defs/HeaderFooterImage"
+ },
+ {
+ "$ref": "#/$defs/CurrentDate"
+ },
+ {
+ "$ref": "#/$defs/DocumentTitle"
+ }
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / HeaderFooterImageAdded value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "required": [
+ "data",
+ "format"
+ ]
+ },
+ {
+ "required": [
+ "path"
+ ]
+ },
+ {
+ "required": [
+ "url"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {
+ "description": "base64-encoded image data",
+ "type": "string"
+ },
+ "format": {
+ "enum": [
+ "png",
+ "jpeg",
+ "jpg"
+ ]
+ },
+ "height": {
+ "type": "number"
+ },
+ "path": {
+ "description": "local file path to image",
+ "type": "string"
+ },
+ "type": {
+ "const": "image"
+ },
+ "url": {
+ "description": "URL to download image from",
+ "type": "string"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / HeaderFooterTextAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bold": {
+ "default": false,
+ "type": "boolean"
+ },
+ "color": {
+ "default": "#000000",
+ "type": "string"
+ },
+ "fontFamily": {
+ "default": "Arial",
+ "type": "string"
+ },
+ "italics": {
+ "default": false,
+ "type": "boolean"
+ },
+ "size": {
+ "default": 12,
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "const": "text"
+ },
+ "underline": {
+ "default": false,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / HorizontalRuleAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "alignment": {
+ "default": "center",
+ "enum": [
+ "left",
+ "center",
+ "right"
+ ],
+ "type": "string"
+ },
+ "color": {
+ "default": "#000000",
+ "type": "string"
+ },
+ "size": {
+ "default": 1,
+ "type": "number"
+ },
+ "style": {
+ "default": "single",
+ "enum": [
+ "single",
+ "double",
+ "thick",
+ "thin",
+ "dotted",
+ "dashed"
+ ],
+ "type": "string"
+ },
+ "type": {
+ "const": "horizontalRule"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / InfoBoxAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "boxType": {
+ "default": "info",
+ "enum": [
+ "info",
+ "warning",
+ "error",
+ "success",
+ "note"
+ ],
+ "type": "string"
+ },
+ "children": {
+ "items": {
+ "$ref": "#/$defs/Block"
+ },
+ "type": "array"
+ },
+ "customColors": {
+ "additionalProperties": false,
+ "properties": {
+ "backgroundColor": {
+ "type": "string"
+ },
+ "borderColor": {
+ "type": "string"
+ },
+ "textColor": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "icon": {
+ "default": true,
+ "type": "boolean"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "const": "infoBox"
+ }
+ },
+ "required": [
+ "type",
+ "boxType",
+ "children"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / Inline / oneOfPrevious value: -[
- {
- "$ref": "#/$defs/TextRun"
- },
- {
- "$ref": "#/$defs/Hyperlink"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/TextRun"
+ },
+ {
+ "$ref": "#/$defs/Hyperlink"
+ },
+ {
+ "$ref": "#/$defs/FootnoteReference"
+ }
+]Input schema / properties / json / $defs / NoteContentAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "children": {
+ "items": {
+ "$ref": "#/$defs/Block"
+ },
+ "type": "array"
+ },
+ "separator": {
+ "default": "line",
+ "description": "Separator style before the note",
+ "enum": [
+ "line",
+ "none",
+ "continuation"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "children"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / PageNumberAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bold": {
+ "default": false,
+ "type": "boolean"
+ },
+ "color": {
+ "default": "#000000",
+ "type": "string"
+ },
+ "format": {
+ "default": "decimal",
+ "enum": [
+ "decimal",
+ "upperRoman",
+ "lowerRoman",
+ "upperLetter",
+ "lowerLetter"
+ ]
+ },
+ "italics": {
+ "default": false,
+ "type": "boolean"
+ },
+ "size": {
+ "default": 12,
+ "type": "number"
+ },
+ "start": {
+ "default": 1,
+ "type": "number"
+ },
+ "type": {
+ "const": "pageNumber"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / json / $defs / Table / properties / alignmentAdded value: +{
+ "default": "left",
+ "enum": [
+ "left",
+ "center",
+ "right"
+ ],
+ "type": "string"
+}Input schema / properties / json / $defs / Table / properties / borderColorAdded value: +{
+ "default": "#000000",
+ "type": "string"
+}Input schema / properties / json / $defs / Table / properties / borderSizeAdded value: +{
+ "default": 1,
+ "type": "number"
+}Input schema / properties / json / $defs / Table / properties / borderStyleAdded value: +{
+ "default": "single",
+ "enum": [
+ "single",
+ "double",
+ "thick",
+ "thin",
+ "dotted",
+ "dashed"
+ ],
+ "type": "string"
+}Input schema / properties / json / $defs / Table / properties / styleAdded value: +{
+ "default": "none",
+ "enum": [
+ "none",
+ "table-grid",
+ "table-list",
+ "table-colorful"
+ ],
+ "type": "string"
+}Input schema / properties / json / $defs / TableCell / properties / backgroundColorAdded value: +{
+ "type": "string"
+}Input schema / properties / json / $defs / TableCell / properties / bordersAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bottom": {
+ "default": true,
+ "type": "boolean"
+ },
+ "left": {
+ "default": true,
+ "type": "boolean"
+ },
+ "right": {
+ "default": true,
+ "type": "boolean"
+ },
+ "top": {
+ "default": true,
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / json / $defs / TableCell / properties / marginsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bottom": {
+ "default": 0,
+ "type": "number"
+ },
+ "left": {
+ "default": 108,
+ "type": "number"
+ },
+ "right": {
+ "default": 108,
+ "type": "number"
+ },
+ "top": {
+ "default": 0,
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / json / $defs / TableCell / properties / verticalAlignAdded value: +{
+ "default": "top",
+ "enum": [
+ "top",
+ "center",
+ "bottom"
+ ],
+ "type": "string"
+}Input schema / properties / json / $defs / TableRow / properties / cantSplitAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / json / $defs / TableRow / properties / heightAdded value: +{
+ "type": "number"
+}Input schema / properties / json / $defs / TableRow / properties / isHeaderAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / json / $defs / TextBoxAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "borders": {
+ "additionalProperties": false,
+ "properties": {
+ "color": {
+ "default": "#000000",
+ "type": "string"
+ },
+ "size": {
+ "default": 1,
+ "type": "number"
+ },
+ "style": {
+ "default": "single",
+ "enum": [
+ "single",
+ "double",
+ "thick",
+ "thin",
+ "dotted",
+ "dashed",
+ "none"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "children": {
+ "items": {
+ "$ref": "#/$defs/Block"
+ },
+ "type": "array"
+ },
+ "fill": {
+ "additionalProperties": false,
+ "properties": {
+ "color": {
+ "type": "string"
+ },
+ "transparency": {
+ "default": 0,
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "height": {
+ "type": "number"
+ },
+ "position": {
+ "additionalProperties": false,
+ "properties": {
+ "anchor": {
+ "default": "paragraph",
+ "enum": [
+ "page",
+ "margin",
+ "paragraph"
+ ],
+ "type": "string"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": {
+ "const": "textBox"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "type",
+ "children"
+ ],
+ "type": "object"
+}Input schema / properties / json / properties / footersAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "default": {
+ "$ref": "#/$defs/HeaderFooterContent"
+ },
+ "even": {
+ "$ref": "#/$defs/HeaderFooterContent"
+ },
+ "first": {
+ "$ref": "#/$defs/HeaderFooterContent"
+ }
+ },
+ "type": "object"
+}Input schema / properties / json / properties / footnotesAdded value: +{
+ "additionalProperties": false,
+ "patternProperties": {
+ "^[a-zA-Z0-9_-]+$": {
+ "$ref": "#/$defs/NoteContent"
+ }
+ },
+ "type": "object"
+}Input schema / properties / json / properties / headersAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "default": {
+ "$ref": "#/$defs/HeaderFooterContent"
+ },
+ "even": {
+ "$ref": "#/$defs/HeaderFooterContent"
+ },
+ "first": {
+ "$ref": "#/$defs/HeaderFooterContent"
+ }
+ },
+ "type": "object"
+}Input schema / properties / json / properties / pageSettingsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "footerMargin": {
+ "default": 720,
+ "type": "number"
+ },
+ "headerMargin": {
+ "default": 720,
+ "type": "number"
+ },
+ "margins": {
+ "additionalProperties": false,
+ "properties": {
+ "bottom": {
+ "default": 1440,
+ "type": "number"
+ },
+ "left": {
+ "default": 1440,
+ "type": "number"
+ },
+ "right": {
+ "default": 1440,
+ "type": "number"
+ },
+ "top": {
+ "default": 1440,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "orientation": {
+ "default": "portrait",
+ "enum": [
+ "portrait",
+ "landscape"
+ ],
+ "type": "string"
+ },
+ "pageSize": {
+ "default": "A4",
+ "enum": [
+ "A4",
+ "A3",
+ "A5",
+ "Letter",
+ "Legal",
+ "Tabloid",
+ "Executive"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}docx-createdocx-editContentdocx-editMetadocx-exportJsondocx-getSchemadocx-insertContentdocx-opendocx-openFiledocx-queryMetadocx-queryObjectsdocx-removeContentdocx-saveTwo tools (docx-open and docx-openFile) have identical descriptions, making them indistinguishable. This creates confusion for agents.
All tools follow a consistent docx-<verb><Noun> pattern with camelCase verbs. No naming convention violations.
12 tools cover the core DOCX operations reasonably well without being excessive or insufficient.
Basic CRUD is present but missing a delete/close operation for documents. Also lacks a way to create an empty document directly.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate PDF/DOCX/XLSX/PPTX from templates+JSON. Convert Office/HTML/MD to PDF. Universal templating
Composable APIs for document extraction, image transformation, and document & sheet generation.
Real .docx and .xlsx files from structured data, with automatic Hebrew/Arabic RTL.
Create real Word .docx files from your AI chat: proposals, quotes, contracts, statements of work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lihongjie0209/docx-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
