Skip to main content
Glama

Word Media, Fields and Forms

word_media
Destructive

Insert, replace, export, and edit images, charts, equations, hyperlinks, fields, and form controls in Word .docx files while preserving backups and atomic saves.

Instructions

Embedded objects: images, charts, equations, text boxes, hyperlinks, fields, form fields and content controls. Plain text is word_edit and tables are word_structure. Every edit backs the file up first and saves atomically. These ops refuse a document open in Word. Ops, one per line, as name(required; opt optional): what it does. file_path, live and backup are not repeated; word_help shows them:

  • insert_image(image_path; opt location width_pt alignment wrap position z_order allow_overlap distance_pt wrap_text): Insert a PNG, JPEG, GIF, BMP or TIFF image at a location, inline by default or floating with wrap; aspect ratio is kept.

  • insert_field(field_code, location; opt placeholder): Insert a Word field (DATE, PAGE, NUMPAGES, SEQ, ...) at a location; codes outside the safe allowlist are refused.

  • set_image(image_id; opt source width_pt alt_text alt_title wrap position z_order allow_overlap distance_pt wrap_text force track author keep_width): Change one image (image_id from list_elements): swap the file (a tracked swap with track=true), resize, set alt text or wrapping; anything not named stays.

  • export_images(output_dir; opt prefix): Save every image in the document as files in output_dir; existing files are refused and the document is not changed.

  • insert_chart(chart_type, data; opt title width_pt height_pt location alignment legend colors): Insert a native, theme-following Word chart from data.

  • set_chart_data(chart_id, data; opt series_names): Replace a chart's data in place (chart_id from list_elements), keeping its formatting; the number of series must stay the same.

  • insert_equation(latex; opt display location at_text occurrence): Insert a LaTeX equation as NATIVE, editable Word math.

  • set_textbox_text(box_index, text): Replace the text of one text box (box_index from get_text(textbox=true)). More ops follow, in the same format, in the op parameter's description.

Input Schema

NameRequiredDescriptionDefault
opYesThe operation to run: an op listed in this tool's description, or one of these, in the same format: - insert_hyperlink(at_text, url; opt occurrence allow_local_file): Turn existing text (the occurrence-th match of at_text) into an external hyperlink; text already in a link is refused. - insert_content_control(tag, after_text; opt alias text occurrence): Insert a plain-text content control with a unique tag right after after_text; other control types are refused. - set_content_control(value; opt tag index): Set one content control's value, addressed by tag or by list_elements(type='content_controls') index (exactly one). - set_form_fields(values; opt missing): Set form-field values by name (legacy fields) or tag/alias (content controls): text fields take strings, checkboxes booleans, dropdowns only their options.
argsNoThe op's arguments as an object. Include file_path (the absolute .docx path) unless the op's line names other paths or the op reads no document; unknown keys are refused. word_help lists every argument.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well past the destructiveHint annotation: every edit "backs the file up first and saves atomically," ops "refuse a document open in Word," field codes outside a safe allowlist are refused, export_images refuses to overwrite existing files and does not modify the document, set_image leaves unnamed properties untouched, and set_chart_data requires the series count to stay the same. These are exactly the mutation-side effects an agent needs before committing.

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?

Front-loaded summary, then a consistent `name(required; opt optional): what it does` format that scans quickly despite its length. The meta-lines ("file_path, live and backup are not repeated; word_help shows them", "More ops follow... in the op parameter's description") add navigation cost but earn their place by not duplicating shared arguments.

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

Completeness4/5

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

For a 2-argument multiplexer over 12 heterogeneous operations with no output schema, coverage is strong: safety behavior, argument shapes, id sources ("image_id from list_elements", "box_index from get_text(textbox=true)") are all given. The remaining gap is return values — nothing says what insert_image or insert_chart yields, so the agent cannot chain ops within a session.

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%, but the schema's `args` object is a generic bag, so the description is doing the real work: it marks required vs optional per op and adds behavioral defaults ("inline by default," "aspect ratio is kept," "anything not named stays"). It covers 8 of 12 ops and defers the rest to the op enum's description, which is disclosed but splits the documentation an agent must read.

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?

Opens with a concrete resource enumeration ("images, charts, equations, text boxes, hyperlinks, fields, form fields and content controls") and each op line states a specific verb plus effect. It explicitly routes siblings: "Plain text is word_edit and tables are word_structure." An agent can place this tool against all nine siblings without opening a schema.

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

Usage Guidelines4/5

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

Sibling boundaries are stated for the two most likely confusions (word_edit for text, word_structure for tables), and each op line implies the situation it serves. There are no explicit when-not-to-use exclusions or prerequisites beyond the open-file refusal, so it falls short of a 5.

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