Skip to main content
Glama
bagushd1
by bagushd1

set_table_style_docx

Apply a built-in Word table style to a selected table in a .docx file using its index and style name, such as 'Table Grid' or 'Light Shading'.

Instructions

Mengubah template style bawaan Word untuk tabel (misalnya 'Table Grid', 'Light Shading', 'Normal Table')

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYes
style_nameYes
table_indexYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden, and it is silent on behavioral traits: whether the style is overwritten, whether a missing style errors or is ignored, permission requirements, or that the file must already exist. 'Mengubah' implies mutation but nothing else is disclosed.

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

Conciseness4/5

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

A single front-loaded sentence with zero padding; the resource comes first and the examples follow. It earns its length, though it is arguably too terse for a 3-parameter mutation tool.

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

Completeness2/5

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

A mutation tool with no annotations, three fully required undocumented parameters, and 0% schema coverage needs considerably more than one sentence. An output schema exists, so return values need not be explained, but input semantics and the effect of the style change are missing.

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?

Schema description coverage is 0% across three required parameters. The examples partially compensate for style_name by naming valid built-in values, but file_path and table_index are entirely unexplained in both schema and description, leaving an agent to guess indexing conventions.

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?

States a specific verb (Mengubah/mengubah) and resource (template style bawaan Word untuk tabel), and the parenthetical examples ('Table Grid', 'Light Shading', 'Normal Table') pin down exactly what a 'style' is. It is distinguishable from siblings like set_cell_shading_docx or set_table_borders_docx, though it never names them. Clear, but no explicit sibling differentiation.

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 when-to-use, when-not-to-use, or alternative guidance. It never says to prefer this over set_table_borders_docx or set_cell_shading_docx when an agent wants a different look, nor does it state any prerequisite (e.g., that the table must already exist).

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