Skip to main content
Glama
blazar-source

r7-office

by blazar-source
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

r7_docx_header_footer

Read, create, or update DOCX headers and footers while preserving existing fields such as PAGE, NUMPAGES, and DATE. Add page numbers safely without overwriting field runs.

Instructions

Read, create or re-text DOCX headers and footers. A text change rewrites only the non-field runs of the paragraph and keeps every field (PAGE, NUMPAGES, DATE…) exactly where it was, so a page number is never destroyed. Page-number fields are added with the fldSimple form R7 and Word both understand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoWhich part (default header).
textNoNew text for the part.
typeNoWhich of the three header/footer kinds (default default).
actionNolist (default) reports every header/footer part; read returns one part; setText changes its text; create makes it when missing; addPageNumber adds a PAGE field; remove deletes the part.
filePathYesPath to the DOCX file.
positionNoWhere to put the field inside the paragraph (default end).
alignmentNoAlignment for a newly created part.
separatorNoLiteral text placed before the field, e.g. "Page ".
outputPathNoWrite to a copy instead of editing in place.
pageNumberNoAdd a page-number field: true for PAGE, or a field instruction such as "NUMPAGES" or "PAGE of NUMPAGES".
sectionIndexNoSection that owns the part (0-based, default 0).
paragraphIndexNoWhich paragraph of the part to re-text (default 0).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well for the highest-risk operation: it explains that setText rewrites only non-field runs and preserves PAGE/NUMPAGES/DATE fields, and that page-number fields are emitted in the fldSimple form both R7 and Word understand. It still omits in-place-vs-copy default behaviour and read/list return shape, keeping it short of a 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 sentences, zero waste, front-loaded with purpose and then the two behavioural facts an agent most needs. Nothing is repeated from the schema or title.

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 12-parameter mutating tool with no output schema and no annotations, the description covers the critical risk (destroying existing page-number fields) and the field encoding used. Gaps remain around the default in-place edit versus outputPath copy, and what list/read return, but these are largely stated in the schema.

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 100%, so the schema already defines all 12 parameters including enums and defaults; the baseline is 3. The description adds field-form context relevant to pageNumber, but does not add per-parameter meaning beyond what the schema states.

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?

The first sentence states a specific verb set (read, create, re-text) and an unambiguous resource (DOCX headers and footers), which no sibling tool (r7_docx_sections, r7_docx_formatting, r7_docx_image) covers. An agent can route here without opening the schema.

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

Usage Guidelines3/5

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

Usage is only implied by the resource scope; there is no explicit when-to-use, when-not, or named alternative against the neighbouring docx tools. The action enum itself is documented in the schema, not the description, so routing between list/read/setText/remove is left to the schema.

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