Skip to main content
Glama

styleset_import-dotx

Imports styles from a .dotx template into a .docx, adding new styles and replacing or skipping existing ones, with an optional dry run to preview changes.

Instructions

Install the styles of a .dotx template into the document: new styles are added, existing ones replaced (or skipped); dry_run previews.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docYesPath to the .docx.
pathYesThe .dotx to read.
expectNo
dry_runNoPreview only; write nothing.
on_conflictNoA style id already in the document (default replace).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, so the description usefully fills the gap: it discloses that new styles are added, existing ones are replaced or skipped, and that dry_run writes nothing. This is meaningful mutation-behavior context beyond the annotation. It stops short of stating prerequisites, side effects on references, or reversibility.

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?

A single tightly packed sentence: verb+resource first, then the effect on new/existing styles, then the dry_run qualifier. No filler, nothing repeated from the schema.

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

Completeness3/5

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

For a 5-parameter mutating tool with no output schema and a nested expect object, the description covers the main write semantics and dry_run but omits the sha256 integrity check, any return-value expectations, and any differentiation from styleset_install. Adequate but with visible gaps.

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

Parameters3/5

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

Schema description coverage is 80%, so the baseline is 3. The description does add meaning for on_conflict (its 'replaced (or skipped)' phrasing maps to the enum) and dry_run, but the expect/sha256 integrity parameter is untouched and doc/path are left to the schema.

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

Purpose4/5

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

The description states a specific verb and resource: installing .dotx template styles into a document, with concrete effect details (new styles added, existing replaced or skipped). It is clear what the tool does, but it never distinguishes itself from the sibling styleset_install, which an agent could easily confuse it with.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus styleset_install, styleset_export-dotx, or style_merge. The conflict-resolution and dry_run semantics are described, but those are behavior, not selection criteria, so the agent must infer when this tool is the right choice.

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