docx.get_table_content

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

No annotations are available, so the description carries the full burden of behavioral disclosure. It does reveal part of the return contract ('all rows with text and empty status'), which hints at how missing text is handled, but it stops short of explaining failure modes for invalid tableIndex, performance characteristics, or whether anything is mutated. It's honest and non-contradictory, but noticeably terse for a tool with zero annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is economical, front-loading the action ('Get content of specific table') and following up with a dash-separated clarification of the return shape. Every phrase earns its place without an excess word; 'specific' is mildly redundant, but the overall structure is clean and scannable for an agent parsing it at a glance.

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

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

Given this is a simple getter with no annotations, no output schema, and only two string/number params, the description does a decent job communicating the return value format. However, it leaves gaps that would be valuable for an agent invoking it blind — most notably, there's no hint about where the tableIndex comes from, and the phrase 'empty status' could mean either the status of empty cells or whether the row itself is empty. These aren't fatal flaws, but they make the tool slightly under-explained for an agent that must call it correctly.

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

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

Schema coverage is 100% — both docId and tableIndex have descriptions in the input schema (e.g., 'Table index (0-based)'), which is the appropriate baseline for this dimension. The tool description adds nothing beyond the schema: it mentions 'specific table' without referencing the index parameter or providing example values or constraints. So 3 is correct, since the schema does the heavy lifting and the description neither helps nor hurts.

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

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

The description uses a specific verb and resource: 'Get content of specific table', and the dash clause explains the response shape ('all rows with text and empty status'). It is unambiguous about its scope, distinguishing itself from sibling table-related tools like docx.tables_list by focusing on per-row content retrieval. However, it doesn't explicitly compare itself to siblings such as docx.get_text or docx.find_empty_table_rows, even though the output hint provides some differentiation.

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

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

Usage is implied by the imperative 'Get content of specific table' — an agent can reasonably infer when to call it, and the output clarification suggests the kind of data to expect. Yet there is no explicit statement about when to prefer it over alternatives (e.g., docx.tables_list or docx.find_empty_table_rows) or any exclusions/prerequisites. This lands at 'implied usage' without crossing into actual guidance.

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