Skip to main content
Glama
KitchenSink4AI

KitchenSink4Word

by KitchenSink4AI
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

get_outline

Read-only

Identify all headings in a Word document with paragraph index and level, detecting both Heading styles and outline-level overrides for accurate TOC generation and heading edits.

Instructions

List every heading with its paragraph index and level. Detects Heading styles AND w:outlineLvl overrides (direct or style-inherited); detected_via names which. detect_formatted=True adds a heuristic scan for direct-formatted headings (short bold/centered paragraphs). When nothing is detected, returns a note plus flat structure counts, not an empty list. The indices feed the location object's paragraph and outline selectors. Open documents are read live. Read-only. TOC generation and heading surgery: academic pack.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
liveNoauto
file_pathYes
detect_formattedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • addedInput schema / properties / detect_formatted
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  2. Changed4 schema fields changedv1.6.1
    • addedInput schema / properties / live
      Added value: +{
+  "default": "auto",
+  "type": "string"
+}
    • addedOutput schema / properties / result / anyOf
      Added value: +[
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  }
+]
    • removedOutput schema / properties / result / items
      Removed value: -{}
    • removedOutput schema / properties / result / type
      Removed value: -"array"
  3. First observedv1.2.1

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses several behavioral details: it detects both style-based and w:outlineLvl overrides, explains the detect_formatted heuristic, and explicitly states the empty-result behavior ('returns a note plus flat structure counts, not an empty list'). It also notes that open documents are read live. These details meaningfully extend what the annotation alone provides.

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?

The description is compact and front-loaded with the core purpose; the first sentence gives the essential function. A few phrases are cryptic, notably 'detected_via names which' and 'academic pack,' which slightly reduce clarity, but the overall length is appropriate and no redundant filler is present.

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?

Given the output schema exists and readOnlyHint is present, the description covers detection variants, fallback behavior, and how indices are consumed. The main gap is the 'live' parameter's semantics, which remains ambiguous. Still, the description is sufficient for an agent to call the tool correctly in most cases.

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 property descriptions are at 0% coverage, so the description must carry parameter meaning. It clearly explains detect_formatted ('adds a heuristic scan for direct-formatted headings') and makes file_path's role obvious, but it does not explain the 'live' parameter or its possible values beyond the statement 'Open documents are read live.' This leaves one parameter underspecified.

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 description opens with a specific verb-resource pair: 'List every heading with its paragraph index and level.' It further clarifies what is detected (Heading styles and w:outlineLvl overrides) and names the mechanism ('detected_via'), making the tool's purpose distinct from text-fetching or element-listing siblings. The phrase 'TOC generation and heading surgery' additionally frames the intended use without ambiguity.

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?

The description implies usage for outline-aware operations by mentioning 'TOC generation and heading surgery' and states that indices feed paragraph/outline selectors. However, it does not explicitly say when to choose this tool over alternatives such as get_text, list_elements, or get_document_view, nor does it state any exclusions or fallback conditions.

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

Install Server

Other Tools