doc-control

Overview Schema Source Related Servers Discussions Admin

styleset_export_dotx

Export a Word document's style definitions to a new .dotx template that users can attach or base documents on. The source document stays unchanged.

Instructions

Write the document's style definitions (all, the styles named, or custom_only) to a new .dotx Word template at out (must not exist), for Word users to attach or base documents on. The document itself is never changed. styleset.import_dotx brings a template's styles into a document; styleset.export gives a JSON style set instead. Returns the path, style count and size.

Input Schema

TableJSON Schema

Name	Required	Description
`doc`	Yes	Path to the .docx.
`out`	Yes	New .dotx to create.
`name`	No	Set name.
`styles`	No	Only these styles (ids or names).
`custom_only`	No	Only user-defined styles.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Always true on success.
`op`	Yes	The operation that ran.
`api`	Yes	API version (1.0).
`doc`	No	The document read or written: path, sha256 and paragraph count.
`next`	Yes	Cursor for the next page (pass as cursor), or null.
`result`	Yes	What the operation returns.
`warnings`	Yes	Things to know about the result.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.2Oct 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "api": {
+      "description": "API version (1.0).",
+      "type": "string"
+    },
+    "doc": {
+      "description": "The document read or written: path, sha256 and paragraph count.",
+      "properties": {
+        "characters": {
+          "description": "text.normalize of a text string: its length.",
+          "type": "integer"
+        },
+        "paragraphs": {
+          "description": "Body paragraphs.",
+          "type": "integer"
+        },
+        "path": {
+          "description": "Path of the document.",
+          "type": "string"
+        },
+        "sha256": {
+          "description": "sha256 of the file (pass as expect.sha256 to a write).",
+          "type": "string"
+        },
+        "source": {
+          "description": "A .txt/.md/.odt source's format, encoding and split mode; \"text\" for a text string (text.normalize).",
+          "type": [
+            "object",
+            "string"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "next": {
+      "description": "Cursor for the next page (pass as cursor), or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ok": {
+      "description": "Always true on success.",
+      "type": "boolean"
+    },
+    "op": {
+      "description": "The operation that ran.",
+      "type": "string"
+    },
+    "result": {
+      "description": "What the operation returns.",
+      "properties": {
+        "bytes": {
+          "description": "Its size.",
+          "type": "integer"
+        },
+        "count": {
+          "description": "Styles in it.",
+          "type": "integer"
+        },
+        "path": {
+          "description": "The template written.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "path",
+        "count",
+        "bytes"
+      ],
+      "type": "object"
+    },
+    "warnings": {
+      "description": "Things to know about the result.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "api",
+    "ok",
+    "op",
+    "result",
+    "warnings",
+    "next"
+  ],
+  "type": "object"
+}

Addedv0.1.3Oct 15, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false; the description reconciles this by stating 'The document itself is never changed', so the agent knows the write targets a new file rather than mutating the source. It also adds a constraint annotations do not carry ('out must not exist') and reports the return payload. It stops short of anything like failure/overwrite behavior, so not a full 5.

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

Conciseness5/5

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

Three short sentences: action and output first, the non-mutation guarantee second, sibling routing third. Every clause earns its place, no filler or restated field labels.

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

Completeness5/5

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

An output schema exists, yet the description still summarizes the return (path, style count, size) at no cost. Combined with the mode selection, the out-file precondition, and sibling disambiguation, an agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds the 'must not exist' precondition on `out` and frames the three selection modes (all / `styles` named / custom_only) that the schema only lists flatly. That is meaningful semantics beyond the field descriptions.

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

Purpose5/5

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

States a specific verb (write) and resource (the document's style definitions) plus the output artifact (.dotx at `out`). It explicitly names the two closest siblings (styleset.import_dotx and styleset.export) and how they differ, so an agent can disambiguate without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit routing: use this when you want a template, styleset.export when you want a JSON style set, styleset.import_dotx when pulling a template's styles into a document. The 'for Word users to attach or base documents on' clause names the situation that selects this tool.

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

Deploy Server