office_docs_mcp

Overview Schema Source Related Servers Discussions Admin

word_read_table

Read a table from a Word document to extract structured data. Specify the file path and optional table index, and get content as markdown or a raw 2D list.

Instructions

Read a table from a Word document (.docx).

Args:
    file_path: Path to the Word document.
    table_idx: 0-based index of the table (default 0).
    format: 'markdown' (default) or 'raw' (2D list of cell text).

Input Schema

TableJSON Schema

Name	Required	Default
`format`	No	markdown
`file_path`	Yes
`table_idx`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 27, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description partially takes on the burden: 'Read' signals a non-destructive operation, and the raw format is described as a 2D list of cell text. However, it does not disclose behavior for out-of-range table indices, empty documents, or errors, so transparency is only partial.

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 compact and front-loads the one-sentence purpose, followed by a tidy Args block. No words are wasted, and each parameter entry conveys its semantics and default.

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?

All three inputs are semantically complete, the .docx scope is stated, and an output schema exists to document the return shape. The main gap is the lack of selection guidance versus sibling tools, which is already penalized under usage guidelines but keeps this from being fully complete.

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?

Schema coverage is 0%, but the description compensates fully: file_path is tied to the Word document, table_idx is defined as 0-based with a default, and format is specified as 'markdown' (default) or 'raw' with the raw shape explained. This adds real meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and the resource ('a table from a Word document (.docx)'), making the tool's purpose obvious. It is distinguishable from siblings like word_read_paragraphs by the table resource, but it does not explicitly contrast itself with those alternatives.

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

Usage Guidelines2/5

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

The description provides no guidance on when to prefer this tool over siblings such as word_read_paragraphs or word_search, nor does it mention prerequisites or exclusions. The only context is the purpose statement, which leaves selection to inference.

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