KitchenSink4Word

Overview Schema Source Related Servers Discussions Admin

List Elements

list_elements

Read-only

Enumerate any Word document element type (tables, images, charts, equations, etc.) in one call, returning counts and item IDs for use with edit/delete/manage tools.

Instructions

Enumerate any collection in one call. type: tables | images | charts | equations | bookmarks | sources | sections | section_blocks | footnotes | endnotes | fields | reference_fields | form_fields | content_controls | template_placeholders | index_entries | lists | toc. Returns {type, count, items}; the ids or indices returned are the handles the matching set_/delete_/manage_ tools take (list then act). Highlights per type: tables reports dimensions and the table_index other table tools take; images reports display size and the media target; charts reports series; equations reads math content; bookmarks excludes internal TOC bookmarks; fields covers complex and simple fields with cached results; reference_fields inventories Zotero, EndNote, and Mendeley fields and flags broken pairs; form_fields and content_controls cover legacy fields and SDTs; template_placeholders lists {{name}} and MERGEFIELD keys for fill_template and mail_merge (assembly pack); lists groups list paragraphs by numbering instance; toc returns TOC-family fields with cached entries (refresh via com_refresh_fields, com-live pack, then re-read). filter={"range": {start, end}, "name": "substring"} applies where meaningful; inapplicable filters refuse loudly. Read-only, file mode; close documents open in Word first. Tools for these elements live in packs; enable_tools lists them. To locate a string, find_text.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`type`	Yes
`filter`	No
`file_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Sep 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description aligns with them while adding substantial behavior: return shape {type, count, items}, handle semantics for later tools, per-type highlights, filter behavior including loud rejection, cached results, and refresh guidance. No contradiction exists.

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 long but structured and front-loaded with purpose and return shape. Per-type details add real value rather than padding, though a few could be condensed. For a multi-collection tool with 15+ types, the length is justified.

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?

Given the tool's complexity and the absence of schema descriptions, the description covers purpose, accepted types, return value, parameter semantics, prerequisites, error behavior, and related tools. The output schema exists, and the description still clarifies the return envelope. Nothing critical is missing.

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 0%, so the description carries the burden. It fully enumerates type values and documents the filter object's range and name substring shape. file_path is left implicit, but 'file mode' and the requirement to close Word documents provide enough context for a conventional file-path parameter.

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 states a precise action ('Enumerate any collection in one call') and identifies the resource with an exhaustive set of element types. It clearly distinguishes itself from sibling tools like find_text and get_table by framing list_elements as the read-only enumeration step before set_/delete_/manage_ actions.

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?

The description gives strong context: read-only, file mode, close open documents first, and list-then-act workflow. It explicitly routes string search to find_text and points to enable_tools for element-specific packs, but it does not systematically enumerate when-not-to-use cases for every sibling tool.

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