Skip to main content
Glama
Sign In
DOCX MCP Server

DOCX MCP Server

by Mavline
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

docx.styles_set

Sets the formatting of a document by applying the provided XML to styles for a given document ID, enabling custom look and feel.

Instructions

Set document styles

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "docId": "<docId>",
      "xml": "<xml>"
    },
    "name": "docx.styles_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
xmlYesXML content
docIdYesDocument ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

D1.5/5.0
Behavior1/5

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

With no annotations, the description must disclose behavior, but it only says 'Set document styles.' It doesn't state whether existing styles are overwritten, merged, validated, or what errors might occur. The effect on the document and the response format are completely unaddressed.

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

Conciseness2/5

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

The description is very brief and structurally clean, but it's so short that it omits essential information. While conciseness is good, here it sacrifices clarity, making it less useful than a slightly longer but more informative description.

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

Completeness1/5

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

There is no output schema, and the description does not mention return values, side effects, or preconditions. Given that the tool modifies a document, the lack of any context about the resulting state or potential errors makes it incomplete.

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

Parameters2/5

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

The schema describes both parameters ('Document ID' and 'XML content'), but these are generic and insufficient. The description adds no clarification about what the XML should contain (e.g., a styles.xml fragment, full style definitions) or how the docId is used. The description fails to enrich the parameter meaning beyond the basic schema.

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

Purpose2/5

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

The description 'Set document styles' is a verb+resource but lacks specificity. It doesn't clarify which styles or in what format, and it doesn't distinguish from the sibling 'docx.styles_get' beyond the action. A clear purpose would mention the XML structure or the scope of styles affected.

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

Usage Guidelines1/5

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. There is no mention of scenarios where setting styles is appropriate, nor any comparison with the get counterpart. The description leaves the user to infer usage entirely.

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

Deploy Server

Other Tools