KitchenSink4Word

Overview Schema Source Related Servers Score Discussions Admin

get_document_view

Read a Word document as a compact markdown view with stable anchor IDs for each paragraph, enabling efficient orientation, section navigation, and bulk editing while reducing token usage.

Instructions

Read the document as an anchored markdown projection, the low-token alternative to get_text for orientation and bulk editing. One block per paragraph, prefixed [hex] with a stable anchor id (from w14:paraId, which survives edits elsewhere in the document); headings carry # prefixes, tables render as pipe tables under [t:hex] with cells addressed t:hex:rNcN (1-based). Anchors work in every location object ({"anchor": "hex"}) and in apply_edits ops. scope: {"outline": "3.2"} for one heading's section, or {"paragraphs": {"start": N, "end": M}} (end exclusive); omit for the whole document. detail: "structure" (headings and counts only), "text" (default), "full" (adds {++ins++}/{--del--} revision markers and [cN] comment refs with an author legend). include: {"tables": false} to skip tables, {"notes": "inline"} to append footnote/endnote text. Documents without paraIds get VOLATILE anchors (flagged in the header) that change with any edit; stamp_anchors=true writes real paraIds so anchors become durable. Stamping is the ONE mutation this tool can make and runs only when explicitly requested, with the normal backup and validated save; plain reads never modify the file. A document open in Word is read from its last saved state. To locate a string, use find_text; to enumerate collections, use list_elements.

Input Schema

TableJSON Schema

Name	Required	Default
`scope`	No
`detail`	No	text
`include`	No
`file_path`	Yes
`stamp_anchors`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Sep 4, 2026

TDQS

A5/5.0

Behavior5/5

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

Despite readOnlyHint=false in annotations, the description fully explains the sole mutation path: "Stamping is the ONE mutation this tool can make and runs only when explicitly requested." It also discloses volatile anchors, the Word open-document behavior, and that plain reads never modify the file, providing far more transparency than the annotations alone.

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?

The description is dense but every clause earns its place: it defines the output format, parameter values, mutation caveats, and sibling routing with no filler. It is front-loaded with the core purpose and structured so that usage, alternatives, and edge-case behavior follow logically.

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

Completeness5/5

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

For a tool with five parameters, no schema descriptions, and nuanced behaviors, the description covers everything: anchor stability, scope syntax, detail modes, include options, the stamp_anchors side effect, and open-document behavior. The presence of an output schema reduces the need to explain return values, so nothing necessary for correct invocation is missing.

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

Parameters5/5

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

With 0% schema description coverage, the description carries the entire burden, and it fully delivers: scope is defined with outline and paragraph ranges, detail is expanded with structure/text/full values, include is illustrated with tables and notes, and stamp_anchors is explained. This goes well beyond the schema's bare keys.

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 opening sentence states a specific action and resource: "Read the document as an anchored markdown projection," and immediately positions it as "the low-token alternative to get_text," differentiating it from a clear sibling. It further specifies the output format (paragraphs, headings, tables, anchors), so the purpose is unmistakable.

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

Usage Guidelines5/5

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

The description explicitly names when to use this tool versus alternatives: it is for orientation and bulk editing, and it closes with "To locate a string, use find_text; to enumerate collections, use list_elements." It also explains when stamp_anchors should be used, giving clear decision guidance.

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